SAP Build Apps is deprecated: the deadline almost nobody mentions

Do you run a productive app on SAP Build Apps? Do you know when your current subscription term ends? And have you pulled the project export yet?

On 23 March 2026, SAP deprecated SAP Build Apps as a standalone product. With no lead time: announced and effective on the same day. Your existing contracts continue, including SLAs and maintenance, until the agreed end date. But there is a second date, missing from most write-ups on the topic, and it is considerably closer.

The SAP Discovery Center carries the sentence that drives your planning: the service will be removed from the list of Eligible Cloud Services as of 30 September 2026. It stays available until the end of the current subscription term, but not for renewal terms that begin after that date. If you consume via CPEA or BTPEA, check this against your contract now.

Much of what you read elsewhere is a shortcut. "End of support: 30 September 2026" is wrong. Support and SLAs run until your contract ends. The 30th of September is a procurement date, not a shutdown date. Keeping those apart matters, because two different decisions hang on them.

One thing is certain: nothing more is coming. SAP has confirmed there will be no further features and no additional data center support. The product is in maintenance mode.

For web frontends, there is a transformation tool. Since 9 April 2026, SAP converts the .mtar export of a Build Apps web application into a React or SAPUI5 project. You do not get it as self-service, but through a support ticket under component CA-LCA-ACP.

The limitations are not buried in fine print. SAP has the customer confirm them in the ticket: the transformation runs "on a best-effort basis", and the output requires review, adjustment and testing. SAP provides no support for developing the result further. And only frontend projects for web applications can be transformed, with no backend connections established in the process. Expect scaffolding, not a running application.

For backends, there is CSV. SAP's recommendation: export each entity individually from the data browser as a CSV file, then import it into a new CAP project where the matching table already exists. The data comes across. The model and the logic do not.

For native mobile apps, SAP points to the Mobile Development Kit and the native SDKs in SAP Mobile Services. That is a change of technology, not an upgrade.

In the comments under the announcement, a customer asked whether only the licensing was changing. The product manager's answer is the most revealing part of the entire communication: the SAP Build Apps portion inside the unified SAP Build offering is "only a fraction of the standalone offering". For urgent projects, SAP explicitly recommends the pro-code offering.

That is the real news. If you adopted Build Apps to get by without developers, you are not swapping one tool for an equivalent one. The question is no longer "which tool now", but: is this application important enough to build properly?

Migration effort almost never sits where people expect it.

Your OData and REST services carry over unchanged, as do destinations, XSUAA roles and the subaccount setup. So does the most valuable part: process logic, field rules and the UX decisions that came out of daily use. That is the specification for the new application.

What gets rebuilt is the proprietary layer: logic flows, the formula language, app and page variables, and everything that lived in the Build Apps backend. Our rule of thumb for a first estimate: count the logic flows, not the screens. An app with five screens and three flows is a sprint. One with thirty screens, nested formulas and its own backend was never a low-code app. It was a business application in low-code clothing.

Form plus approval: SAP Build Process Automation. A sizeable share of what was built in Build Apps was never an application requirement, it was a process requirement. There you stay in low-code, and the deprecation does not affect you.

Lists and details on SAP data: SAP Fiori Elements. Annotation-driven on OData V4, little custom code, real Fiori UX. For anything that is essentially creating, finding and maintaining business data, this is the obvious answer.

Your own data model: CAP. The replacement for the Build Apps backend named by SAP itself. A clean CDS model, services, authorizations, testable. It is pro-code, and that is precisely the point.

Close to the ABAP stack: ABAP Cloud and RAP. Sensible when the logic sits there anyway and clean core is delivered through ABAP Cloud.

Mobile with offline, scanning and camera: Mobile Development Kit. Within the SAP stack, the only solid answer for real field service and warehouse scenarios. Plan for a rebuild.

And: switch it off. In almost every portfolio we take stock of, there are apps that came out of an innovation sprint and never went into operation. The deprecation is a good moment to check that honestly. The cheapest migration is the one you avoid.

The phrase sounds like manual labour, and a few years ago it would have been. Today the most tedious part of a migration can be handled by machine: reconstructing what the old app actually does.

An SAP colleague documented exactly this in public. He had browser automation capture the running Build Apps application, meaning screenshots, labels, field structure and network calls, and derived the specification from it. The new SAPUI5 app was then built with a UI5 MCP server that gave the coding agent the current API reference, manifest validation and the linter. What would have taken days took a few hours.

This does not replace a project. On a simple application it shifts the effort noticeably, on a complex one the business logic remains the bottleneck. But it changes the numbers you take into the decision.

Not every app needs to move now. If your contract runs for a while yet and the application is non-critical, deliberately waiting is a legitimate decision, not procrastination.

Two things are worth doing immediately. First, pull and archive the .mtar export for every relevant app while the subscription is active. Without that export, there is no transformation later. Second, look up the end of your subscription term. In our projects that is the number nobody has to hand, and it drives the entire schedule.

One point of reassurance: SAP Build Work Zone is not affected. Asked directly, SAP confirmed there is currently no plan to deprecate it. Pricing stays the open question. SAP confirms costs change depending on the use case, and the specifics only emerge in a conversation about your contract.

This decision affects us too. Our mobile warehouse solution with barcode scanning and offline operation runs on SAP Build Apps. We are working through the same assessment described here for our own project.

SAP Build Apps is not disappearing overnight. But the decision about your apps should not wait until the contract forces it. The useful lesson from this deprecation is a different one anyway: applications built on open standards, meaning OData, CAP, SAPUI5, Cloud Foundry or Kyma, survive portfolio decisions. Applications whose logic sits in a proprietary formula language do not.

We take stock of your Build Apps portfolio, map each application to a target architecture, and tell you what genuinely needs rebuilding. 30 minutes, no strings attached, with a founder at the table.