SAP Build Apps abgekündigt: Was Nutzer jetzt wissen müssen
SAP Build Apps ist abgekündigt. Das sorgt verständlicherweise erst einmal für Unruhe. Vor allem dort, wo das Tool bereits produktiv genutzt wird oder als einfacher Einstieg in die App-Entwicklung auf der SAP BTP eingeplant war. Ganz so dramatisch, wie es im ersten Moment klingt, ist die Lage aber nicht. Bestehende Kunden können SAP Build Apps bis zum Ende ihres aktuellen Vertrags weiter nutzen. Gleichzeitig ist klar: Für neue Vorhaben und die langfristige Planung müssen Unternehmen jetzt umdenken.
Das Wichtigste im Überblick
- SAP Build Apps wird seit dem 23. März 2026 als Standalone-Produkt eingestellt.
- Für bestehende Kunden gibt es keinen Sofort-Stopp. Betrieb, Support, SLAs und Wartung laufen bis zum Vertragsende weiter.
- Für bestehende Frontend-Projekte gibt es keinen direkten Migrationspfad in das neue SAP-Build-Angebot.
- Daten aus dem bisherigen Backend lassen sich laut SAP nur manuell, zum Beispiel per CSV-Export, in ein neues CAP-basiertes Setup übernehmen.
- Künftig rückt stärker in den Fokus, was SAP unter SAP Build bündelt: Low-Code, code-nahe Entwicklung und generative KI mit SAP Build Code.
SAP Build Apps ist abgekündigt – was heißt das konkret?
Wichtig ist zuerst die Einordnung: Nicht die gesamte SAP-Build-Welt verschwindet, sondern SAP Build Apps als eigenständiges Produkt. SAP bündelt seine Angebote stärker unter SAP Build und setzt dabei auf eine integrierte Plattform für Anwendungsentwicklung, Automatisierung und Business Sites. Laut SAP soll diese Plattform Low-Code, code-first und generative KI zusammenbringen.
Für Nutzer von SAP Build Apps ist das trotzdem mehr als eine kleine Produktkorrektur. Denn die Frage ist nicht nur, wie das Produkt jetzt heißt. Die eigentliche Frage lautet: Wie entwickeln Sie Ihre Anwendungen künftig weiter?
Was bedeutet das für bestehende Nutzer von SAP Build Apps?
Die gute Nachricht: Sie müssen nicht von heute auf morgen alles neu bauen. Bestehende Verträge laufen weiter, und SAP sichert zu, dass bestehende Verpflichtungen bis zum Vertragsende erfüllt werden. Die schwierigere Nachricht: Für bestehende Frontend-Anwendungen gibt es keinen einfachen Übernahmeweg. SAP schreibt ausdrücklich, dass ein direkter Migrationspfad für bestehende SAP-Build-Apps-Frontend-Projekte nicht verfügbar ist. Wer also gehofft hat, die bisherigen Oberflächen einfach mitzunehmen, wird neu planen müssen.
Noch wichtiger wird das beim Backend. Unternehmen, die das schlanke Backend von SAP Build Apps genutzt haben, müssen jetzt genauer hinschauen. Laut SAP sollen bestehende Daten manuell exportiert und in ein neues CAP-Projekt importiert werden. Das ist machbar, aber eben kein bequemer Klickpfad. Es bedeutet auch: Die bisher eher leichte Architektur muss durch ein tragfähigeres Zielbild ersetzt werden.
Warum jetzt mehr in Richtung SAP Build Code und Vibe Coding gedacht wird
Jetzt fragen Sie sich vielleicht: Heißt das, Low-Code ist vorbei? Ganz so einfach ist es nicht. Was sich aber klar erkennen lässt: Der klassische Baukastenansatz verliert an Gewicht, während code-nähere und KI-gestützte Entwicklung wichtiger wird.
Genau hier kommt SAP Build Code ins Spiel. SAP beschreibt Build Code als Teil des neuen SAP-Build-Angebots und hebt dabei die generative Unterstützung durch Joule hervor. Damit lassen sich unter anderem Datenmodelle, Services und Logik aus natürlichsprachigen Beschreibungen erzeugen.
Das ist nah an dem, was heute oft unter Vibe Coding verstanden wird: weniger starres Zusammenklicken im Frontend-Baukasten, mehr Entwicklung mit Sprachprompts, KI-Unterstützung und einem sauber definierten technischen Unterbau.
Für Unternehmen ist das vor allem strategisch relevant. Der Fokus verschiebt sich weg von „Hauptsache schnell eine App zusammenbauen“ hin zu „Wie setzen wir einen Entwicklungs-Stack auf, der auch morgen noch trägt“.
Was Nutzer jetzt bei Backend und Datenbankstrategie prüfen sollten
Wer bislang mit dem Build-Apps-Backend gearbeitet hat, steht jetzt vor einer wichtigen Architekturfrage. Reicht eine sehr leichte Lösung noch aus, oder ist jetzt der richtige Zeitpunkt für ein robusteres Backend?
Im SAP-Umfeld läuft diese Diskussion häufig auf CAP als Anwendungsmodell hinaus. Bei der Datenbank kommen je nach Szenario vor allem SAP HANA beziehungsweise SAP HANA Cloud oder PostgreSQL infrage. CAP unterstützt diese Datenbankoptionen offiziell. PostgreSQL ist also in CAP grundsätzlich vorgesehen, HANA bleibt im SAP-Kontext aber oft die naheliegende Wahl für produktive Unternehmensszenarien.
Die entscheidende Frage ist daher nicht nur technisch, sondern strategisch: Welche App soll künftig wie wachsen, wie integriert sein und wie stabil betrieben werden?
Welche Optionen haben Nutzer von SAP Build Apps jetzt?
Die erste Option ist pragmatisch: Bestehende Anwendungen zunächst weiter betreiben und die verbleibende Vertragslaufzeit bewusst nutzen. Das ist vor allem dann sinnvoll, wenn eine Lösung stabil läuft und kurzfristig kein Umbau nötig ist.
Die zweite Option ist ein kontrollierter Neuaufbau. Für viele Web- und Erweiterungsszenarien dürfte der Weg künftig stärker über SAP Build, Build Code und CAP führen. Das ist zwar weniger Baukasten und mehr strukturierte Entwicklung, schafft aber meist mehr Zukunftssicherheit.
Die dritte Option betrifft mobile Projekte. SAP empfiehlt für laufende native Mobile-Vorhaben eher Mobile Development Kit und native SDKs. Auch das zeigt: Künftig wird stärker danach unterschieden, welcher Ansatz wirklich zur jeweiligen Anwendung passt, statt alles in einem Frontend-Baukasten aufzufangen.
Fazit: SAP Build Apps endet – die eigentliche Aufgabe beginnt jetzt
Die Abkündigung von SAP Build Apps ist ohne Frage ein Einschnitt. Vor allem für Unternehmen, die das Tool strategisch eingeplant hatten oder mit dem leichten Backend bewusst auf Schnelligkeit gesetzt haben. Trotzdem wäre es falsch, jetzt nur auf die Produktabkündigung zu schauen.
Die wichtigere Entwicklung ist die dahinterliegende Verschiebung: weg vom reinen Low-Code-Baukasten, hin zu stärker KI-gestützter, code-näherer Entwicklung mit einem solideren Backend-Fundament. Genau deshalb ist jetzt ein guter Zeitpunkt, Frontend, Backend und Datenbankstrategie sauber neu aufzustellen.
Oder anders gesagt: Erst einmal durchatmen. Dann nicht am alten Baukasten festhalten, sondern die Gelegenheit nutzen, den eigenen Dev-Stack zukunftsfähig aufzusetzen.
FAQ
Ist SAP Build komplett abgekündigt?
Nein. Abgekündigt ist SAP Build Apps als Standalone-Produkt. SAP Build als übergeordnetes Angebot bleibt bestehen.
Können bestehende SAP-Build-Apps-Projekte einfach migriert werden?
Nicht direkt. Für bestehende Frontend-Projekte gibt es laut SAP keinen direkten Migrationspfad.
Was passiert mit dem bisherigen Backend?
Bestehende Daten sollen laut SAP manuell exportiert und in ein neues CAP-Projekt übernommen werden.
Wird SAP Build Code jetzt wichtiger?
Ja, das ist die klare Tendenz. SAP positioniert Build Code innerhalb von SAP Build als code-näheren, KI-gestützten Entwicklungsansatz mit generativer Unterstützung durch Joule.
Welche Datenbank kommt künftig infrage?
Das hängt vom Szenario ab. Im CAP-Umfeld sind SAP HANA und PostgreSQL offizielle Optionen.
