Die Abkündigung von SAP Build Apps hat in den letzten Wochen für spürbare Unruhe in vielen SAP‑Organisationen gesorgt. Was lange als strategisches Low‑Code‑Werkzeug für schnelle App‑Entwicklung galt, wird nun als eigenständiges Produkt eingestellt. Für Unternehmen mit produktiven Anwendungen auf Basis von SAP Build Apps stellt sich damit nicht nur eine technische, sondern vor allem eine strategische Frage: Wie geht es weiter und was bedeutet diese Entscheidung konkret für die eigene SAP‑Architektur?
Dieser Beitrag ordnet die Entscheidung ein, erläutert die Auswirkungen für Unternehmen und zeigt auf, warum jetzt ein geeigneter Zeitpunkt ist, die eigene Low‑Code‑ und Erweiterungsstrategie kritisch zu überprüfen.
Einordnung der Abkündigung: Was SAP entschieden hat – und warum
SAP Build Apps war über mehrere Jahre hinweg das zentrale No‑/Low‑Code‑Werkzeug im SAP‑Portfolio. Ziel war es, Fachbereiche und IT‑Teams in die Lage zu versetzen, einfache Web‑ und Mobile‑Anwendungen vergleichsweise schnell zu erstellen – insbesondere für SAP‑nahe Anwendungsfälle.
SAP hat nun SAP Build Appszum 23. März 2026 als eigenständiges Produkt abgekündigt. Bestehende Verträge werden bis zum jeweiligen Vertragsende weiterhin erfüllt, einschließlich Support und vereinbarter Service Level Agreements.
Mit dieser Entscheidung verändert SAP die bisherige Ausrichtung grundlegend. Künftig sollen folgende Bereiche in einer einheitlichen Entwicklungsplattform (SAP Build) gebündelt werde :
- Low‑Code‑, Pro‑Code‑ und Automatisierungsfunktionen
- klassische Entwicklung (z. B. CAP, ABAP Cloud, SAPUI5)
- sowie KI‑gestützte Entwicklungsansätze
SAP Build Apps wird dabei nicht weiter als eigenständiger Service fortgeführt. SAP hat ergänzend ein technisches Migrationstool vorgestellt, das den Übergang bestehender Build-Apps-Frontends zu Pro-Code-Technologien unterstützen soll
Rückblick: Von AppGyver zu SAP Build Apps
Ein kurzer Rückblick hilft, die Entscheidung besser einzuordnen:
- 2021 übernahm SAP den No‑Code‑Anbieter AppGyver, um Citizen Development im SAP‑Kontext auszubauen.
- In den Folgejahren wurde die Plattform in SAP Build Apps integriert und Teil der SAP Build Suite.
- Parallel entwickelte SAP jedoch weiterhin seine klassischen Erweiterungstechnologien (CAP, SAPUI5, ABAP Cloud) und investierte zunehmend in KI‑gestützte Entwicklung.
In der Praxis zeigte sich, dass SAP Build Apps insbesondere für einfache, klar abgegrenzte Anwendungsszenarien geeignet war. Für komplexere Anforderungen, langfristige Erweiterungen oder architekturrelevante Anwendungen setzten viele Teams weiterhin auf etablierte SAP‑Technologien.
Vor diesem Hintergrund ist die Abkündigung weniger als abruptes Ende zu verstehen, sondern vielmehr als Konsolidierung eines Portfolios, das sich funktional und strategisch auseinanderentwickelt hatte.
Kein „Aus“ für Low‑Code – aber ein klares Umdenken
Wichtig ist: Die Abkündigung von SAP Build Apps bedeutet nicht das Ende von Low‑Code bei SAP. Vielmehr investiert SAP gezielt in folgende Bereiche:
- SAP Build als vereinheitlichtes Entwicklungsangebot
- SAP Build Code für KI‑gestützte Pro‑Code‑Entwicklung
- CAP (Cloud Application Programming Model), ABAP Cloud und SAPUI5
- stärkere Einbindung generativer KI (z. B. Joule) in den Entwicklungsprozess
Für Unternehmen bedeutet das eine strategische Verschiebung: weg von isolierten Low‑Code‑Werkzeugen hin zu ganzheitlichen Entwicklungs‑ und Erweiterungsarchitekturen auf der SAP BTP.
Auswirkungen für Unternehmen: Was die Abkündigung und Migration konkret bedeuten
Auch wenn bestehende SAP‑Build‑Apps‑Umgebungen zunächst weiter betrieben werden können, ergeben sich mittel‑ bis langfristig relevante Risiken – insbesondere für Unternehmen mit produktiven oder geschäftskritischen Anwendungen.
1. Bestehende Apps bleiben lauffähig, aber ohne Zukunftsperspektive
SAP erfüllt bestehende Verträge inklusive Support und Wartung bis zum jeweiligen Laufzeitende. Es gibt also keinen sofortigen Handlungszwang. Gleichzeitig ist jedoch klar: SAP Build Apps wird nicht mehr weiterentwickelt.
Das bedeutet:
- keine neuen Funktionen,
- keine strategischen Innovationen,
- keine langfristige Produktsicherheit.
Für Anwendungen mit hoher geschäftlicher Bedeutung ist das ein relevanter Risikofaktor.
2. Steigende technische und organisatorische Abhängigkeiten
Je länger Anwendungen auf einer abgekündigten Plattform betrieben werden, desto größer werden potenzielle Nachteile:
- begrenzte Erweiterbarkeit,
- steigende Wartungskosten,
- Risiko bei Sicherheits‑ oder Compliance‑Anforderungen,
- Abhängigkeit von spezifischem, zunehmend knapperem Know‑how.
Vor allem im Kontext von S/4HANA‑Transformationen und Clean‑Core‑Strategien kann das zum Blocker werden.
3. Kein klassischer Migrationspfad – Neuaufbau statt Übernahme
Ein Punkt, der in vielen Organisationen zunächst unterschätzt wird, ist der fehlende vollständig automatisierte Übergang zu anderen SAP‑Technologien.
In der Praxis heißt das:
- Benutzeroberflächen aus SAP Build Apps lassen sich nicht ohne manuelle Anpassungen in andere UI‑Technologien überführen.
- Logik, die in visuellen Flows modelliert wurde, muss neu implementiert werden.
- Daten können zwar exportiert werden, müssen jedoch in neue Modelle und Architekturen integriert werden.
Der Wechsel auf eine neue Plattform ist damit kein technisches Update, sondern in der Regel ein gezielter Re‑Design‑ und Re‑Build‑Prozess. Der tatsächliche Aufwand hängt stark von Anzahl und Komplexität der bestehenden Anwendungen ab.
Vor diesem Hintergrund stellt sich für viele Unternehmen die Frage, welche konkreten Unterstützungsangebote SAP inzwischen bereitstellt – und wie diese einzuordnen sind.
Neues Migrationstool von SAP: Technische Brücke statt vollständiger Migration
SAP hat kürzlich ein offizielles Migrationstool für bestehende SAP Build Apps Frontend‑Webanwendungen veröffentlicht. Ziel dieses Tools ist es, betroffene Kunden beim Übergang zu unterstützen und einen vollständigen Neubau der Anwendungen nicht zwingend erforderlich zu machen.
Das Migrationstool ermöglicht die Konvertierung bestehender SAP Build Apps Frontends in React‑ oder SAPUI5‑Projekte. Damit eröffnet SAP einen Weg, bestehende Anwendungen technisch in eine Pro‑Code‑Umgebung zu überführen und weiterzuentwickeln. In der Praxis bleibt die zentrale Frage bestehen: Ist eine Migration sinnvoll oder ein kontrollierter Neuaufbau die bessere Option? Das Migrationstool kann diese Entscheidung erleichtern – sie jedoch nicht ersetzen
SAP Build Apps abgekündigt: Welche strategischen Handlungsoptionen haben Unternehmen jetzt?
Die Abkündigung zwingt Unternehmen nicht zu einem sofortigen Aktionismus – wohl aber zu einer strukturieren Entscheidungsfindung. Folgende Optionen stehen aus unserer Sicht zur Auswahl:
Option 1: Gezielter Weiterbetrieb einzelner Anwendungen
Für wenig kritische oder zeitlich begrenzte Apps kann ein befristeter Weiterbetrieb sinnvoll sein – etwa, um Zeit für eine fundierte Neuplanung zu gewinnen. Voraussetzung ist jedoch ein klar definiertes Enddatum und eine bewusste Risikoabwägung.
Option 2: Migration und Neuentwicklung auf Basis SAP‑nativer Technologien
Viele Unternehmen entscheiden sich bewusst für einen Neuaufbau mit:
- SAP Build (in seiner vereinheitlichten Form),
- SAP Build Code,
- CAP (Cloud Application Programming Model),
- SAP Fiori Elements / UI5 oder ABAP Cloud.
Diese Option bietet die größte Zukunftssicherheit, erfordert jedoch auch strukturierte Architekturarbeit und entsprechende Entwicklungsressourcen.
Option 3: Einsatz externer Low‑Code‑Plattformen
Alternativ kommen spezialisierte Low‑Code‑Lösungen von Drittanbietern infrage. Sie können Entwicklungszeiten reduzieren, bringen jedoch neue Fragestellungen mit sich:
- Integrationstiefe in SAP‑Systeme
- Governance und Sicherheitskonzepte
- langfristige Abhängigkeiten vom jeweiligen Anbieter
Ohne klare Leitplanken besteht die Gefahr, bestehende Herausforderungen lediglich zu verlagern. Eine fundierte Bewertung ist hier entscheidend.
Option 4: Hybridansätze und strategische Neuausrichtung der App‑Governance
Die Abkündigung bietet auch eine Chance: Viele Unternehmen nutzen den Anlass, um ihre App‑Landschaft, Entwicklungsmodelle und Verantwortlichkeiten grundlegend neu zu ordnen.
In vielen Fällen erweist sich ein kombinierter Ansatz als sinnvoll:
- stabile Business‑Logik in SAP‑nahen Technologien,
- darauf aufbauend flexible Frontends oder Low‑Code‑Komponenten.
Unabhängig vom gewählten Tool ist entscheidend, jetzt klare Regeln für App‑Governance, Verantwortlichkeiten und Lebenszyklen zu definieren.
SAP Build Code und KI: Was sich im Entwicklungsansatz ändert
Mit SAP Build Code setzt SAP verstärkt auf KI‑unterstützte Entwicklung. Der Fokus liegt weniger auf rein visueller Modellierung, sondern auf der Unterstützung professioneller Entwickler durch generative KI – etwa bei:
- der Erstellung von Datenmodellen,
- der Implementierung von Geschäftslogik,
- Tests und Qualitätssicherung.
Für Unternehmen bedeutet das: Low‑Code wird nicht abgeschafft, sondern stärker in einen gesamtheitlichen Entwicklungsprozess eingebettet, in dem Architektur und Wartbarkeit klar im Vordergrund stehen.
Wie Unternehmen die Situation jetzt sinnvoll nutzen können
Die Abkündigung von SAP Build Apps ist für viele Organisationen unbequem – bietet aber auch eine Chance. Sie zwingt dazu, Fragen zu stellen, die oft lange aufgeschoben wurden:
- Welche Anwendungen sind wirklich geschäftskritisch?
- Wo reicht Standard‑SAP aus?
- Wo sind individuelle Erweiterungen strategisch sinnvoll?
- Wie sieht eine nachhaltige App‑Landschaft in fünf Jahren aus?
Unternehmen, die diese Fragen jetzt strukturiert angehen, vermeiden spätere Notlösungen und schaffen Planungssicherheit.
In diesem Kontext kann es sinnvoll sein, auf externe, erfahrungsbasierte Unterstützung zurückzugreifen – insbesondere bei der Bewertung von Architekturoptionen, Migrationspfaden und Governance‑Modellen. Entscheidend ist dabei weniger das konkrete Werkzeug als vielmehr ein tragfähiges Gesamtkonzept.
Wie ORBIS konkret unterstützen kann
ORBIS unterstützt Unternehmen seit vielen Jahren bei der strategischen Nutzung der SAP Business Technology Platform – von der Einordnung technischer Veränderungen bis zur strukturierten Umsetzung moderner Erweiterungsarchitekturen:
1. Analyse & Bewertung bestehender SAP‑Build‑Apps‑Lösungen
- Technische Bestandsaufnahme
- Bewertung der geschäftlichen Relevanz
- Abhängigkeiten & Integrationen
- Risiko‑ und Business‑Impact‑Analyse
2. Definition einer zukunftsfähigen Zielarchitektur
- SAP‑Build‑Strategie (Low‑Code vs. Pro‑Code)
- Clean‑Core‑konforme Erweiterungsmodelle
- Integration in bestehende S/4HANA‑Landschaften
- Governance‑ und Security‑Konzepte
3. Migrations‑ und Modernisierungskonzepte
- Re‑Design statt reinem „Nachbauen“
- Einordnung von Migrationsoptionen
- Schrittweise Migration mit minimalem Risiko unter Berücksichtigung der Möglichkeiten des neuen SAP-Migrationstools
- Unterstützung beim Einsatz von SAPUI5, CAP, SAP Build Code oder Alternativen
4. Enablement & langfristige Begleitung
- Architektur‑Workshops
- Entwickler‑Enablement
- Citizen‑Development‑Governance
- Strategische Roadmaps für nachhaltige App‑Entwicklung
ORBIS versteht sich dabei nicht als reiner Tool‑Anbieter, sondern als strategischer Partner für Architektur‑, Plattform‑ und Transformationsfragen im SAP‑Umfeld.
Fazit: Jetzt handeln – strategisch, nicht hektisch
Die Abkündigung von SAP Build Apps ist mehr als eine reine Produktmeldung. Sie markiert einen strategischen Richtungswechsel und bietet Anlass, die eigene App‑ und Erweiterungsstrategie auf der SAP BTP kritisch zu überprüfen und zukunftssicher auszurichten.
Unternehmen, die diese Phase strukturiert nutzen, gewinnen Transparenz über ihre App‑Landschaft, erhöhen ihre Planungssicherheit und schaffen die Grundlage für eine nachhaltige, skalierbare Architektur.
Dabei kann es hilfreich sein, auf erfahrene SAP‑Partner zurückzugreifen, die sowohl technologische als auch organisatorische Aspekte berücksichtigen. Sprechen Sie mit uns, wenn Sie wissen möchten, wie Ihre SAP‑Build‑Apps‑Lösungen langfristig sicher, modern und businessorientiert weiterentwickelt werden können.
Veröffentlicht am 29.04.2026
