SAP Build Apps ist abgekündigt: der Stichtag, den kaum jemand nennt

Läuft bei Ihnen eine produktive App auf SAP Build Apps? Wissen Sie, wann Ihr aktueller Subscription-Term endet? Und haben Sie den Projekt-Export schon gezogen?

Am 23. März 2026 hat SAP SAP Build Apps als eigenständiges Produkt abgekündigt. Ohne Vorlauf: Ankündigung und Wirksamkeit am selben Tag. Ihre bestehenden Verträge laufen weiter, inklusive SLA und Wartung, bis zum vereinbarten Ende. Es gibt aber einen zweiten Termin, der in den meisten Beiträgen zum Thema fehlt und der deutlich näher liegt.

Im SAP Discovery Center steht der Satz, der Ihre Planung bestimmt: Der Service wird zum 30. September 2026 aus der Liste der Eligible Cloud Services entfernt. Bis zum Ende des laufenden Subscription-Terms bleibt er verfügbar, für Verlängerungen, die nach diesem Datum beginnen, nicht mehr. Wer über CPEA oder BTPEA konsumiert, sollte das jetzt gegen den eigenen Vertrag prüfen.

Was anderswo zum Thema steht, ist oft eine Verkürzung. "End of Support: 30. September 2026" stimmt nicht. Support und SLA laufen bis zu Ihrem Vertragsende. Der 30. September ist ein Beschaffungsdatum, kein Abschaltdatum. Das gehört auseinandergehalten, weil daran zwei verschiedene Entscheidungen hängen.

Sicher ist außerdem: Es kommt nichts mehr. SAP hat bestätigt, dass es weder weitere Funktionen noch zusätzlichen Rechenzentrums-Support geben wird. Das Produkt ist im Maintenance Mode.

Für Web-Frontends gibt es ein Transformationstool. Seit dem 9. April 2026 wandelt SAP den .mtar-Export einer Build-Apps-Web-App in ein React- oder SAPUI5-Projekt um. Sie bekommen es nicht als Self-Service, sondern über ein Support-Ticket unter der Komponente CA-LCA-ACP.

Die Einschränkungen stehen nicht im Kleingedruckten, SAP lässt sie sich im Ticket vom Kunden bestätigen: Die Transformation erfolgt "on a best-effort basis", das Ergebnis braucht Review, Anpassung und Test. Für die Weiterentwicklung leistet SAP keinen Support. Und es lassen sich ausschließlich Frontend-Projekte für Web-Anwendungen umwandeln, Backend-Verbindungen entstehen dabei nicht. Rechnen Sie mit einem Gerüst, nicht mit einer lauffähigen Anwendung.

Für Backends gibt es CSV. SAPs Empfehlung lautet: jede Entity im Data Browser einzeln als CSV exportieren und in ein neues CAP-Projekt importieren, in dem die passende Tabelle vorher angelegt wurde. Die Daten kommen mit. Das Modell und die Logik nicht.

Für native Mobile-Apps verweist SAP auf das Mobile Development Kit und die nativen SDKs in SAP Mobile Services. Das ist ein Technologiewechsel, kein Upgrade.

In den Kommentaren zur Ankündigung fragte ein Kunde nach, ob sich denn nur die Lizenzierung ändere. Die Antwort des zuständigen Product Managers ist die aufschlussreichste Stelle der gesamten Kommunikation: Der Build-Apps-Anteil innerhalb des vereinheitlichten SAP Build sei "only a fraction of the standalone offering". Für dringende Projekte empfiehlt SAP ausdrücklich das Pro-Code-Angebot.

Das ist die eigentliche Nachricht. Wer Build Apps eingesetzt hat, um ohne Entwickler auszukommen, tauscht kein Werkzeug gegen ein gleichwertiges. Die Frage lautet damit nicht "welches Tool jetzt", sondern: Ist diese Anwendung wichtig genug, um sie richtig zu bauen?

Der Aufwand einer Migration steckt fast nie dort, wo er vermutet wird.

Ihre OData- und REST-Services bleiben unverändert bestehen, ebenso Destinations, XSUAA-Rollen und das Setup im Subaccount. Auch das Wertvollste bleibt: Prozesslogik, Feldregeln und die UX-Entscheidungen aus dem Betrieb. Genau das ist die Spezifikation der neuen Anwendung.

Neu gebaut wird die proprietäre Schicht: Logic Flows, die Formelsprache, App- und Page-Variablen sowie alles, was im Build Apps Backend lag. Unsere Faustregel für die erste Schätzung: Zählen Sie die Logikflüsse, nicht die Screens. Eine App mit fünf Screens und drei Flüssen ist ein Sprint. Eine mit dreißig Screens, verschachtelten Formeln und eigenem Backend war nie eine Low-Code-App, sondern eine Fachanwendung im Low-Code-Kostüm.

Formular plus Freigabe: SAP Build Process Automation. Ein erheblicher Teil dessen, was in Build Apps gebaut wurde, war nie eine App-Anforderung, sondern eine Prozessanforderung. Dort bleiben Sie im Low-Code und sind von der Abkündigung nicht betroffen.

Listen und Details auf SAP-Daten: SAP Fiori Elements. Annotationsgetrieben auf OData V4, wenig eigener Code, echtes Fiori-UX. Für alles, was im Kern Anlegen, Suchen und Pflegen von Geschäftsdaten ist, die naheliegende Antwort.

Eigenes Datenmodell: CAP. Der von SAP selbst genannte Ersatz für das Build Apps Backend. Sauberes CDS-Modell, Services, Berechtigungen, testbar. Das ist Pro-Code, und genau das ist der Punkt.

Nah am ABAP-Stack: ABAP Cloud und RAP. Sinnvoll, wenn die Logik ohnehin dort liegt und Clean Core über ABAP Cloud abgebildet wird.

Mobil mit Offline, Scan und Kamera: Mobile Development Kit. Im SAP-Stack die einzige belastbare Antwort für echte Außendienst- und Lagerszenarien. Rechnen Sie mit einem Neubau.

Und: abschalten. In fast jedem Portfolio, das wir aufnehmen, stehen Apps, die in einem Innovations-Sprint entstanden und nie in den Betrieb gegangen sind. Die Abkündigung ist ein guter Anlass, das ehrlich zu prüfen. Die günstigste Migration ist die, die entfällt.

Der Satz klingt nach Handarbeit, und vor ein paar Jahren wäre er das gewesen. Inzwischen lässt sich der mühsamste Teil einer Migration maschinell erledigen: das Rekonstruieren dessen, was die alte App eigentlich tut.

Ein SAP-Kollege hat genau das öffentlich dokumentiert. Er hat die laufende Build-Apps-Anwendung per Browser-Automatisierung erfassen lassen, also Screenshots, Beschriftungen, Feldstruktur und Netzwerkaufrufe, und daraus die Spezifikation abgeleitet. Danach entstand die neue SAPUI5-App mit Unterstützung eines UI5-MCP-Servers, der dem Coding-Agent die aktuelle API-Referenz, die Manifest-Validierung und den Linter bereitstellt. Aus einer Aufgabe von mehreren Tagen wurden wenige Stunden.

Das ersetzt kein Projekt. Bei einer einfachen Anwendung verschiebt es den Aufwand spürbar, bei einer komplexen bleibt die Fachlogik der Engpass. Es verändert aber die Rechnung, mit der Sie in die Entscheidung gehen.

Nicht jede App muss jetzt bewegt werden. Läuft Ihr Vertrag noch lange und ist die Anwendung unkritisch, ist bewusstes Abwarten eine legitime Entscheidung, keine Vertagung.

Zwei Dinge sollten Sie trotzdem sofort erledigen. Erstens: den .mtar-Export für jede relevante App ziehen und archivieren, solange die Subscription läuft. Ohne diesen Export gibt es später auch keine Transformation. Zweitens: das Ende Ihres Subscription-Terms nachschlagen. In unseren Projekten ist das die Zahl, die am häufigsten niemand parat hat, und sie bestimmt den gesamten Zeitplan.

Ein Punkt zur Beruhigung: SAP Build Work Zone ist nicht betroffen. Auf ausdrückliche Nachfrage hat SAP bestätigt, dass dort aktuell keine Abkündigung geplant ist. Offen bleibt die Preisfrage. SAP bestätigt, dass sich die Kosten je nach Use Case ändern, konkret wird das nur im Gespräch über Ihren Vertrag.

Uns betrifft die Entscheidung im Übrigen selbst: Unsere mobile Lagerlösung mit Barcode-Scan und Offline-Betrieb läuft auf SAP Build Apps. Wir führen dieselbe Bewertung, die wir hier beschreiben, gerade für das eigene Projekt durch.

SAP Build Apps verschwindet nicht über Nacht. Aber die Entscheidung über Ihre Apps sollte nicht erst fallen, wenn der Vertrag sie erzwingt. Die brauchbare Lehre aus dieser Abkündigung ist ohnehin eine andere: Anwendungen, die auf offenen Standards laufen, also OData, CAP, SAPUI5, Cloud Foundry oder Kyma, überleben Portfolio-Entscheidungen. Anwendungen, deren Logik in einer proprietären Formelsprache steckt, nicht.

Wir nehmen Ihr Build-Apps-Portfolio auf, ordnen jede Anwendung einem Zielbild zu und sagen Ihnen, was davon wirklich neu gebaut werden muss. 30 Minuten, unverbindlich, mit einem Gründer am Tisch.