SAP hat angekündigt, SAP Build Apps als eigenständiges Standalone‑Produkt zum 30. September 2026 einzustellen.
Für viele Unternehmen ist das mehr als eine übliche Produktabkündigung. Bestehende Anwendungen lassen sich nicht einfach „umstellen“. Sie müssen neu gedacht und in vielen Fällen manuell neu aufgebaut werden.
Genau deshalb ist eine Build Apps Migration kein reines Technikprojekt. Sie ist eine geplante Transition, die mehrere Ebenen betrifft: das Applikationsportfolio, die Architektur, den Betrieb und nicht zuletzt die benötigten Skills.
Dieser Artikel ordnet die Entscheidung der SAP ein, beschreibt die wichtigsten technischen Konsequenzen und zeigt realistische Handlungsoptionen auf. Dazu zählen der Wechsel in das neue SAP Build Angebot, ein Neubau mit SAPUI5 und CAP sowie der Einsatz von Drittanbieter‑Plattformen.
Die Zielgruppe sind IT‑Leitungen, Enterprise‑ und Solution‑Architekt:innen, Product Owner sowie Verantwortliche für SAP BTP, die bestehende Build‑Apps‑Anwendungen absichern und eine tragfähige Nachfolgestrategie entwickeln müssen.
Um die Tragweite der Abkündigung zu verstehen, hilft ein kurzer Blick in die Vergangenheit: SAP übernahm AppGyver im Februar 2021 und integrierte die No‑Code‑/Low‑Code‑Plattform später als SAP Build Apps in die SAP BTP. Der Ansatz passt zur propagierten Clean‑Core‑Strategie, da so Erweiterungen außerhalb des S/4HANA‑Kerns ermöglicht wurden.
Bereits zuvor gab es erste Einschnitte. Die AppGyver Community Edition verlor ihren Support zum 30. September 2024. Im April 2025 folgte schließlich der Launch des Unified SAP Build Ansatzes. Apps, Prozesse und Work‑Zone‑Themen wurden stärker zusammengeführt und in eine gemeinsame Lobby integriert.
Die Abkündigung der Standalone‑Variante ist eine Weiterführung dieser Konsolidierung. SAP möchte die Werkzeuge für Anwendungen, Prozessautomatisierung und Portale in einem integrierten Angebot bündeln.
Auf dem Papier wirkt das vereinfachend. Für Bestandskunden bedeutet es jedoch einen harten Schnitt. Das frühere Standalone Build Apps basiert technologisch auf anderen Grundlagen als das neue Unified‑Umfeld.
Die wichtigste technische Aussage lässt sich klar zusammenfassen: Für Frontend‑Projekte existiert kein automatisierter Migrationspfad.
Konkret bedeutet das, dass Seiten, Datenbindungen, Logikflüsse, Navigationen und individuelle Komponenten in der Zielumgebung manuell neu aufgebaut werden müssen.
Was viele Teams an Build Apps überzeugt hat – die visuelle Modellierung von Logikflüssen – wird in der Transition zur größten Herausforderung. Es gibt kein Werkzeug, das visuelle Logikdiagramme automatisiert in die neue Architektur überführt. Der Grund hierfür liegt in den unterschiedlichen Grundlagen der Systeme. Während das ursprüngliche Build Apps unter anderem auf steroids.js und AngularJS basierte, orientiert sich das neue Unified‑Angebot an SAP‑Standards wie SAPUI5 und dem Cloud Application Programming Model (CAP).
Das bedeutet nicht, dass ein Migrationspfad grundsätzlich unmöglich gewesen wäre. SAP hat sich jedoch bewusst dagegen entschieden, auch für Standardszenarien einen solchen bereitzustellen.
In der Praxis müssen bestehende Anwendungen daher zunächst sauber dokumentiert und anschließend neu implementiert werden. Betroffen sind unter anderem Variablenbindungen, Formeln, Event‑Handler, Navigationslogik sowie Custom‑JavaScript‑Komponenten.
Für Backend‑Projekte beschreibt SAP zumindest einen rudimentären Weg, Daten zu übernehmen. Dieser Ansatz ist jedoch eher eine manuelle Datenrettung als eine Migration im klassischen Sinn.
Entitäten werden einzeln aus dem Datenbrowser als CSV‑Dateien exportiert. In der Zielumgebung – idealerweise in einem CAP‑Projekt – müssen passende Tabellen manuell angelegt werden. Anschließend erfolgt der Import der CSVs.
Nicht automatisch übernommen werden dabei Beziehungen zwischen Entitäten, Metadaten, Berechtigungsstrukturen und weitere implizite Regeln. Genau diese Aspekte sind in produktiven Anwendungen häufig kritisch. Zusätzlich entsteht ein Integrationsrisiko: Wenn bestehende Frontends Services konsumieren, sollten neue CAP‑Services möglichst kompatible API‑Signaturen bereitstellen, um den Anpassungsaufwand im Frontend zu begrenzen.
Wenn Sie SAP Build Apps produktiv einsetzen, sollten Sie die Situation nicht als „ein Projekt“ betrachten, sondern als Portfolio‑Entscheidung.
Nicht jede Anwendung benötigt denselben Zielpfad.
Ein strukturiertes Application‑Portfolio‑Management hilft, Prioritäten zu setzen. Typische Kriterien sind strategische Relevanz, technische Komplexität und Änderungsdynamik.
SAP garantiert den weiteren Betrieb bis zum Ende laufender Verträge. Das gilt unabhängig vom Lizenzmodell. SLAs und Wartungszusagen bleiben bestehen.
Diese Option ist jedoch mit Einschränkungen verbunden. Für die Standalone‑Version sind keine neuen Funktionen vorgesehen. Neue Sicherheitsstandards oder Innovationen wie die tiefere Integration von Joule fließen primär in das Unified Offering.
Zudem wird es zunehmend schwieriger, qualifizierte Fachkräfte für eine auslaufende Technologie zu finden.
Abwarten kann daher sinnvoll sein, wenn Anwendungen stabil sind oder ohnehin vor September 2026 abgelöst werden. Für alle anderen stellt es meist nur einen zeitlichen Aufschub dar.
Der offizielle SAP‑Pfad ist der Umstieg auf das vereinheitlichte SAP Build Angebot.
Der Mehrwert liegt nicht in einer automatisierten Migration, sondern in einer konsolidierten Entwicklungsumgebung. Low‑Code, Pro‑Code und KI‑gestützte Funktionen sind zentral gebündelt.
Viele Unternehmen nutzen den Neubau gezielt, um technische Schulden abzubauen. Anwendungen werden auf einer moderneren Architektur neu aufgesetzt – mit klarer Trennung von Frontend, Services und Datenmodell.
Gleichzeitig sollte kritisch geprüft werden, ob und in welchem Umfang Investitionen in ein weiteres SAP‑Innovationsprodukt sinnvoll sind, dessen langfristige Stabilität sich erst bewähren muss.
Für geschäftskritische Anwendungen ist der Einschnitt ein Anlass, wieder stärker auf Pro‑Code zu setzen.
CAP und SAPUI5 gelten als strategische SAP‑Standards. Sie bieten langfristige Wartbarkeit und reduzieren die Abhängigkeit von kurzfristigen Tool‑Entscheidungen.
CAP strukturiert die Service‑Entwicklung und etabliert bewährte Enterprise‑Patterns. UI5 – ergänzt durch Fiori Elements – kann die Entwicklung standardisierter Oberflächen beschleunigen.
Der höhere Schulungsaufwand ist real, rechnet sich aber häufig über den Lebenszyklus zentraler Anwendungen.
Einige Unternehmen evaluieren bewusst Alternativen außerhalb des SAP‑Portfolios. Das ist insbesondere dann sinnvoll, wenn Fachbereiche stark eingebunden sind, Time‑to‑Market im Fokus steht oder mobile Szenarien besondere Anforderungen stellen.
Plattformen wie Simplifier, Neptune DXP oder Mendix adressieren unterschiedliche Schwerpunkte – von schneller Fiori‑Entwicklung über ABAP‑nahe Architekturen bis hin zu komplexen, systemübergreifenden Anwendungen.
Gleichzeitig erhöht ein Drittanbieter die Abhängigkeiten, beeinflusst Lizenzkosten und steigert die Komplexität der Landschaft. Dieser Weg sollte daher gut abgewogen sein.
Die größte Gefahr in solchen Umbruchphasen ist Aktionismus: Einzelne Apps werden hektisch neu gebaut, während das Gesamtportfolio unklar bleibt. Besser ist ein klarer Ablauf, der technische und organisatorische Arbeitspakete verbindet.
Der erste Schritt ist eine vollständige Inventarisierung Ihrer SAP Build Apps Lösungen:
Daraus entsteht eine Priorisierung nach strategischer Relevanz und technischer Komplexität. So vermeiden Sie, dass knappe Kapazitäten in Apps fließen, die ohnehin abgelöst werden.
Zum Schluss entscheidet die Umsetzungsgeschwindigkeit oft über Erfolg oder Stillstand. Deshalb ist es sinnvoll, frühzeitig Pilot‑Apps auszuwählen: eine einfache, eine mittelkomplexe und eine kritische App. Auf dieser Basis können Sie Standards für Architektur, Security, Naming, Transport/Deployment und Tests definieren und diese Standards danach konsequent für die restliche Build Apps Migration anwenden.
SAP setzt stark auf generative KI, um den Neubau zu beschleunigen. Joule soll in SAP Build Code und Build Apps helfen, Anforderungen schneller in umsetzbare Strukturen zu übersetzen. Der Trend geht damit von reinem Low‑Code stärker in Richtung „KI‑assistierter“ Entwicklung, bei der Menschen Ergebnisse prüfen, integrieren und absichern.
Wichtig ist hier aber die Erwartungshaltung: KI kann Zeit sparen, sie ersetzt aber nicht die Kernarbeit der Transition – also saubere Zielarchitektur, klare Verantwortlichkeiten, Sicherheitskonzept, Tests und Betriebsprozesse.
Entdecken Sie SAP Clean Core und wie Sie Ihre SAP-Systeme mit einem standardisierten Kern und kontrollierten Erweiterungen zukunftssicher gestalten. Dieses E-Book bietet einen umfassenden Einblick in die fünf Dimensionen von SAP Clean Core
und zeigt, wie Sie diese erfolgreich umsetzen können.
Es richtet sich an SAP-Architekten, Entwickler, Berater und Entscheidungsträger, die SAP Clean Core erfolgreich implementieren möchten.
Entdecken Sie SAP Clean Core und wie Sie Ihre SAP-Systeme mit einem standardisierten Kern und kontrollierten Erweiterungen zukunftssicher gestalten. Dieses E-Book bietet einen umfassenden Einblick in die fünf Dimensionen von SAP Clean Core
und zeigt, wie Sie diese erfolgreich umsetzen können.
Es richtet sich an SAP-Architekten, Entwickler, Berater und Entscheidungsträger, die SAP Clean Core erfolgreich implementieren möchten.
Willkommen bei unserem exklusiven Support für Bestandskunden. Hier finden Sie alle nötigen Informationen, um schnell und unkompliziert Hilfe bei technischen Anfragen zu erhalten.
Für eine direkte Unterstützung per Fernwartung, laden Sie bitte unser TeamViewer-Modul herunter:
Bitte beachten Sie: Dieser Kanal ist speziell für technische Anfragen unserer Bestandskunden vorgesehen. Für allgemeine Anfragen, Informationen zu unseren Dienstleistungen oder eine Erstberatung nutzen Sie bitte unser Kontaktformular oder schreiben Sie eine E-Mail an [email protected].
