# #30 On-Stack or Side-by-Side Two places to run an abap2UI5 app, and — this is the part people usually get backwards — the choice is about lifecycles rather than about code. The class is the same class either way. **On-stack** means the app runs inside the SAP system. It reads the data directly, there is no remote call and no second system to operate, and deployment is the transport you already use. Built on released APIs it runs unchanged on S/4HANA Public Cloud, Private Cloud and on-premise. What it inherits is that system's lifecycle: its release, its upgrade window, its maintenance slots, its change freeze in December. { width=90% } **Side-by-side** means the app runs on the SAP BTP ABAP Environment and calls the S/4 system remotely — released OData, RFC or SOAP services. Everything on the BTP side is Level A by construction — the levels are [#29](/advanced/insights/29-when-the-api-is-not-released) — and it works against S/4HANA Public Cloud, where on-stack custom code is not an option at all. { width=90% } The separation is the point. A side-by-side app is released, upgraded and restarted on its own schedule, and the S/4 system does not have to agree. Where a release cycle is the actual constraint — a locked system, a long change window, a team that cannot get a transport through this quarter — that is worth more than the directness on-stack gives. The cost is equally plain, and it is not only technical: a remote call is slower than a local read, the released remote APIs are narrower than what a local `SELECT` can reach, and there is a second system to run, monitor and pay for. When the released remote APIs do not cover the case, a service on the S/4 side closes the gap and is graded on its own — the BTP side stays Level A: { width=90% } Neither choice touches the app class. The same code renders in both places — only what it reads changes.