The Third Deprecation in Four Years
SAP acquired AppGyver in February 2021. By late 2022, it had been rebranded as SAP Build Apps and positioned as the cornerstone of SAP's citizen developer strategy. As of March 23, 2026, SAP Build Apps is deprecated.
Three names. Four years. Zero continuity.
The announcement came via an SAP Community blog post by Patrick Schad, Product Manager for SAP Build. The key facts are stark:
- No automated migration path for frontend projects. If you built a UI in Build Apps, you are rebuilding it from scratch.
- Manual migration only for backend projects. Export your data as CSV files, entity by entity, and re-import them into a new CAP project in SAP Build. Hope nothing breaks.
- All roadmap features are abandoned. The planned deep integration with SAPUI5, the low-code/pro-code collaboration features — all of it is gone. When asked directly, Schad confirmed: "Yes, all of the features like the UI5 integration are abandoned."
- Existing contracts are honored through their end date. After that, you are on your own.
The successor is the "unified SAP Build offering" — a platform that combines application development, process automation, and business site creation. But as multiple community members pointed out, SAP Build has basic form-based UI capabilities that do not come close to replacing what Build Apps offered. Even SAP's own Discovery Center and BTP catalog had not been updated to reflect the deprecation weeks after the announcement. That tells you something about how coordinated this decision was internally.
What SAP Left Out
The announcement raises more questions than it answers.
No timeline for free-tier users. AppGyver had a free Community Edition that SAP marketed with the tagline "AppGyver is free, forever." Thousands of non-SAP developers built applications on it. The deprecation post provides no clarity on when their access ends. One community member asked directly. No answer as of this writing.
No real replacement for the low-code capability. The unified SAP Build offering is positioned as a pro-code platform with some low-code features. When a community member asked "which current SAP product will replace Build Apps using a low-code/no-code approach," the response was to wait for SAPPHIRE. Customers with active projects and mid-cycle budgets cannot wait until June for a product direction.
No acknowledgment of the CX impact. SAP Sales and Service Cloud V2 was coupled with Build Apps. Consulting firms spent years training teams and selling the combination to customers. That investment is now stranded.
The SAPPHIRE deflection. Multiple times in the comment thread, Schad pointed to SAP SAPPHIRE as the venue where "product updates and new products are introduced." This is not a transition plan. It is a holding pattern.
Who Gets Hurt and How Badly
This is not a niche deprecation. SAP positioned Build Apps as a key pillar of three major enterprise strategies: citizen development, Clean Core side-by-side extensions, and BTP-native application development. The blast radius is wide.
Citizen developer programs. Organizations that invested in training business users to build apps — the entire promise of low-code — now have stranded skills and stranded applications. The skills built on Build Apps do not transfer to CAP or SAPUI5 development. These are fundamentally different programming models.
Clean Core architectures. SAP explicitly recommended Build Apps for building side-by-side UI extensions on BTP. If you followed SAP's own architecture guidance for separating custom UIs from the S/4HANA core, Build Apps was on the recommended list. Those architecture decisions now need revisiting.
BTP cost models. Customers who purchased CPEA credits or BTP subscriptions with Build Apps as a primary consumption driver have unused entitlements. The credits can be redirected to other BTP services, but the applications they were meant to support no longer have a platform.
In-progress projects. This is the most painful category. Teams that are mid-build face an impossible choice: continue building on a deprecated platform with no future, or restart on an alternative technology and absorb the sunk cost.
| Impact Area | Severity | Mitigation Available |
|---|---|---|
| Existing frontend apps | High | None automated — manual rebuild required |
| Existing backend data | Medium | CSV export/import to CAP on SAP Build |
| Citizen developer training | High | Skills not transferable to pro-code |
| BTP licensing / CPEA credits | Medium | Redirect to other BTP services |
| Clean Core extension plans | Medium | Swap Build Apps for SAPUI5/CAP |
| In-progress projects | Critical | Case-by-case evaluation |
The Pattern: Why SAP Low-Code Keeps Failing
This is not an isolated event. SAP has a repeating pattern with low-code tools: acquire, rebrand, promote aggressively, then quietly deprecate when enterprise adoption does not materialize at scale.
AppGyver was a well-regarded independent low-code platform before SAP acquired it. The acquisition was supposed to give SAP a competitive answer to Microsoft Power Apps, Mendix, and OutSystems. Instead, it produced a product that struggled to find its place in the SAP ecosystem.
The fundamental tension is structural. SAP's core customer base needs deep ERP integration — complex business logic, tight authorization models, transactional consistency across modules. Low-code tools are designed for broad, shallow use cases — simple forms, approval workflows, basic CRUD applications. These two needs pull in opposite directions. Building a low-code tool that is simultaneously simple enough for citizen developers and deep enough for real SAP integration is extraordinarily difficult. SAP tried and concluded that AI-assisted pro-code is a better bet.
Compare this to Microsoft's approach. Power Apps has been generally available since 2016. It has a stable, growing platform with deep Dynamics 365 and Azure integration, a massive developer community, and a clear long-term roadmap. Ten years of incremental improvement, not a cycle of acquisitions and deprecations. SAP's low-code story has no comparable stability.
The community response captures this perfectly. As one commenter put it: "SAP's goal should actually be to quickly bring ONE technology to market that is customer-friendly in terms of pricing and feature set, and then support it for 10 years — not to develop overlapping tools in the same segment in parallel."
What To Do Now
The right response depends on where you are. Here is a decision framework.
If You Have Build Apps in Production
Step 1: Inventory everything. Document every Build Apps application — frontend complexity, backend dependencies, user count, business criticality, and contract end date. You need to know your exposure before you can plan.
Step 2: Triage by complexity and criticality.
- Simple form-based apps (data entry, approval screens, basic dashboards): These are the easiest to rebuild. Evaluate SAP Fiori Elements, which can generate standard UIs from CDS annotations with minimal code. For non-SAP use cases, consider Microsoft Power Apps or a similar platform.
- Complex frontend apps (custom navigation, rich interactions, offline support): Plan a full rebuild. The realistic options are SAPUI5 with Fiori Elements (stays in SAP ecosystem, Clean Core compatible), a CAP backend with a modern frontend framework like React or Angular deployed on BTP, or a non-SAP low-code platform if tight SAP integration is not required.
- Native mobile apps: SAP recommends the Mobile Development Kit (MDK) and native SDKs via SAP Mobile Services. Evaluate whether this meets your requirements before committing.
Step 3: Migrate backend data now. Do not wait. Use the CSV export path while you still have full access. Export every entity, validate the data, and test the import into your new CAP project thoroughly. "Manual migration" means data loss risk if you are not careful.
If You Are Mid-Project
This is the hardest position. Here is how to think about it:
- Less than 30% complete: Stop and re-evaluate the technology choice now. The cost of switching today is lower than the cost of finishing a build on a deprecated platform and then rebuilding again in 12 to 18 months.
- More than 70% complete: Finish the build, deploy, and extract value from the application. Plan a migration to an alternative technology within the timeframe of your current contract. You will get ROI from the application before you need to replace it.
- 30% to 70% complete: This is the gray zone. Factor in your contract end date, the application's business criticality, your team's skills in alternative technologies, and whether the remaining build effort is primarily frontend (high risk, no migration path) or backend (lower risk, CSV migration available).
If You Were Planning to Adopt Build Apps
Do not. The product is in maintenance mode with no future features and no migration path to its successor. Evaluate these alternatives instead:
- SAPUI5 / Fiori Elements for SAP-centric user interfaces. This is SAP's most durable frontend technology with decades of investment behind it.
- SAP Build Code (CAP) for full-stack BTP applications. CAP is well-integrated with S/4HANA APIs and has a clear long-term roadmap.
- Microsoft Power Apps or Mendix for low-code use cases that do not require deep SAP integration.
How to Make Defensible Platform Bets on BTP
BTP is not going away. It is too deeply embedded in SAP's Clean Core and S/4HANA Cloud strategy. But individual BTP services have varying levels of strategic durability, and Build Apps is the proof.
Here is a heuristic for evaluating which BTP services are safe long-term bets:
High durability — Services that are deeply integrated into S/4HANA core workflows. SAP cannot deprecate these without breaking their own product:
- SAP Integration Suite (the backbone of all S/4HANA integrations)
- ABAP Environment / Steampunk (the runtime for ABAP Cloud development)
- SAP HANA Cloud (the database underneath everything)
- SAP Build Work Zone (the launchpad for all Fiori applications)
Medium durability — Services with large installed bases and clear revenue, but that could theoretically be replaced:
- SAP Analytics Cloud
- SAP Datasphere
- SAP Build Process Automation
Lower durability — Services that were acquired, rebranded, or have unclear differentiation from established competitors. Watch for the pattern: acquisition, rebrand, aggressive marketing, quiet feature stagnation, deprecation:
- SAP Build Apps was in this category
- Evaluate any newly acquired or rebranded service with this lens
The architectural principle that protects you regardless of which services survive: design your extensions so the UI layer is swappable. If your BTP extension uses clean APIs between the backend (CAP or ABAP Cloud) and the frontend, you can replace the frontend technology without rebuilding the entire application. Build Apps customers who built monolithic applications with tightly coupled frontend and backend have no escape hatch. Those who used Build Apps purely as a UI layer on top of well-defined OData or REST APIs have a painful but manageable migration ahead.
This is not hypothetical advice. It is the difference between a three-month frontend rebuild and a twelve-month full rewrite.
Trust Is the Real Casualty
The financial cost of the Build Apps deprecation is measurable. The trust cost is not.
SAP is asking customers to make multi-year, multi-million-dollar bets on BTP as the extension platform for Clean Core. Every deprecation like this makes that bet harder to justify in a steering committee. Every "wait for SAPPHIRE" response makes it harder to convince a CFO that the next SAP product recommendation will still be supported in three years.
The customers who were burned are not the ones who made bad technology decisions. They are the ones who followed SAP's own guidance. They built citizen developer programs because SAP told them to. They chose Build Apps for side-by-side extensions because SAP's architecture documentation recommended it. They invested in training, built applications, and integrated them into business processes. And now they are told to start over with no migration path and a vague promise that something better is coming at SAPPHIRE.
Our recommendation: continue investing in BTP's durable services. Integration Suite, ABAP Cloud, HANA Cloud, and Build Work Zone are safe bets with deep integration into S/4HANA's core architecture. Be skeptical of anything that looks like an acquired product searching for an enterprise use case. And always — always — design for replaceability. The next deprecation is not a question of if. It is a question of when.