Wie man SAP-Integrationen auf die neue API Policy v4/2026 migriert – in 7 Schritten

Die neue SAP API Policy v4/2026 hat Ende April 2026 das SAP-Oekosystem erschuettert. Undokumentierte APIs sind jetzt vertragswidrig, KI-Agenten duerfen keine SAP-APIs mehr autonom nutzen, und die DSAG warnt vor massiver Unsicherheit. Wenn Ihr Unternehmen SAP-Integrationen betreibt – und das tun fast alle deutschen Mittelstaendler und Konzerne – muessen Sie jetzt handeln. Dieser Leitfaden zeigt Ihnen in 7 konkreten Schritten, wie Sie Ihre SAP-Integrationen policy-compliant machen, ohne Ihren Geschaeftsbetrieb zu stoeren.

Schritt 1: Vollstaendiges API-Inventar erstellen

Bevor Sie irgendetwas migrieren koennen, muessen Sie wissen, was Sie haben. Der erste Schritt ist ein vollstaendiges Inventar aller Schnittstellen zu und von Ihren SAP-Systemen. Das klingt trivial, ist es aber nicht: In einer typischen mittelstaendischen SAP-Landschaft (z.B. ein Maschinenbauer mit 2.000 Mitarbeitern in Bayern) gibt es oft 30 bis 80 verschiedene Integrationen, von denen die IT-Abteilung nur die Haelfte bewusst dokumentiert hat.

Praktisches Vorgehen: Starten Sie mit dem SAP Integration Content Advisor in der SAP Integration Suite. Dieses Tool analysiert Ihre bestehenden Integrationen und identifiziert die genutzten APIs. Ergaenzen Sie die Ergebnisse mit einer manuellen Pruefung: Fragen Sie Ihre Fachabteilungen, welche externen Systeme auf SAP zugreifen. Haeufig existieren „Schatten-Integrationen“ – Verbindungen, die von Fachabteilungen oder externen Dienstleistern eingerichtet wurden, ohne die IT zu informieren.

Enterprise-Beispiel: Ein grosser Automobilzulieferer im Raum Stuttgart hat bei seinem API-Audit 67 aktive Integrationen gefunden – darunter 12, die niemand in der IT-Abteilung kannte. Drei davon liefen ueber RFCs (Remote Function Calls), die seit SAP-Basis 7.5 als deprecated gelten. Ohne das Audit waeren diese „blinden Flecken“ erst aufgefallen, wenn SAP sie blockiert haette.

Ergebnis dieses Schritts: Eine vollstaendige Excel- oder CMDB-Liste mit: API-Name/Endpunkt, Typ (veroeffentlicht/undokumentiert/RFC/BAPI/IDoc), verbundenes externes System, Datenflussrichtung (eingehend/ausgehend), Aufruffrequenz und Geschaeftskritikalitaet (hoch/mittel/niedrig).

Schritt 2: Compliance-Status jeder Integration pruefen

Mit dem vollstaendigen Inventar koennen Sie jetzt jede Integration gegen die API Policy v4/2026 pruefen. Oeffnen Sie den SAP Business Accelerator Hub und gleichen Sie ab: Ist die genutzte API dort gelistet? Wenn ja: compliant. Wenn nein: non-compliant und muss migriert werden.

Drei Kategorien bilden sich heraus:

Gruen (Compliant): Die Integration nutzt eine veroeffentlichte API im Business Accelerator Hub. Keine Aktion erforderlich, ausser regelmaessigem Monitoring auf API-Aenderungen.

Gelb (Potenziell non-compliant): Die Integration nutzt eine API, die in der Produktdokumentation erwaehnt wird, aber nicht explizit im Business Accelerator Hub gelistet ist. Hier brauchen Sie eine Klaerung mit SAP oder Ihrem SAP-Partner. Dokumentieren Sie die Nutzung und erstellen Sie einen Migrationsplan als Absicherung.

Rot (Non-compliant): Die Integration nutzt eine undokumentierte, interne oder private API. Diese muss migriert werden – entweder auf eine veroeffentlichte API (falls verfuegbar) oder ueber einen BTP-Wrapper (Clean-Core-Ansatz). Falls die Integration ein KI-System einschliesst, das autonom API-Aufrufe plant und ausfuehrt, ist sie zusaetzlich durch Abschnitt 2.2.2 betroffen.

Enterprise-Beispiel: Ein Pharmaunternehmen in Frankfurt hat seine 45 Integrationen klassifiziert: 22 waren gruen, 8 gelb und 15 rot. Von den 15 roten Integrationen waren 4 geschaeftskritisch (ERP-zu-Produktionssteuerung), was die Migrationspriorisierung sofort klar machte.

Schritt 3: Priorisierung nach Risiko und Geschaeftskritikalitaet

Nicht alle non-compliant Integrationen muessen gleichzeitig migriert werden. Eine kluge Priorisierung spart Zeit, Budget und Nerven. Die Reihenfolge sollte auf einer Risikomatrix basieren, die zwei Dimensionen beruecksichtigt: Geschaeftskritikalitaet (Wie schlimm ist es, wenn die Integration ausfaellt?) und Entdeckungsrisiko (Wie wahrscheinlich ist es, dass SAP die non-compliant Nutzung erkennt?).

Hoechste Prioritaet: Integrationen mit hoher Geschaeftskritikalitaet und hohem Entdeckungsrisiko. Das sind typischerweise Schnittstellen mit hoher API-Aufruffrequenz (SAP kann ungewoehnliche Muster erkennen) und geschaeftskritischen Daten. Beispiel: Eine ERP-zu-MES-Integration (Manufacturing Execution System) bei einem Automobilzulieferer, die ueber eine undokumentierte BAPI laeuft und stuendlich hunderte Aufrufe generiert.

Mittlere Prioritaet: Integrationen mit hoher Geschaeftskritikalitaet, aber niedrigem Entdeckungsrisiko (z.B. naeechtliche Batch-Prozesse mit geringer Frequenz). Oder: Integrationen mit niedriger Geschaeftskritikalitaet, aber hohem Entdeckungsrisiko (z.B. ein Dashboard-Tool, das staendig SAP-Daten abfragt).

Niedrige Prioritaet: Integrationen mit niedriger Geschaeftskritikalitaet und niedrigem Entdeckungsrisiko. Diese koennen Sie in einer zweiten oder dritten Welle migrieren.

Enterprise-Beispiel: Ein Chemiekonzern in Ludwigshafen hat seine 15 roten Integrationen in drei Wellen aufgeteilt: Welle 1 (4 Integrationen, 8 Wochen) deckte die geschaeftskritischen Produktionsschnittstellen ab. Welle 2 (6 Integrationen, 12 Wochen) umfasste die Finanz- und HR-Integrationen. Welle 3 (5 Integrationen, 6 Wochen) erledigte Reporting- und Analytics-Verbindungen. Gesamtdauer: 6,5 Monate.

Schritt 4: Clean-Core-Wrapper ueber SAP BTP bauen

Dies ist der technisch anspruchsvollste Schritt – und der wichtigste. Fuer jede non-compliant Integration, fuer die keine veroeffentlichte API im Business Accelerator Hub existiert, muessen Sie einen Clean-Core-Wrapper ueber die SAP Business Technology Platform (BTP) bauen.

Das Konzept: Anstatt direkt auf interne SAP-APIs zuzugreifen, erstellen Sie einen Zwischenlayer auf der BTP. Dieser Layer nutzt SAP-interne Werkzeuge (ABAP Development Tools, RAP – RESTful ABAP Programming Model) um die benoetigten Daten aus dem SAP-Kern zu extrahieren und als stabilen, veroeffentlichten OData v4- oder REST-Service bereitzustellen. Die externe Integration greift dann auf den BTP-Service zu – nicht auf den SAP-Kern.

Praktisches Vorgehen:

1. Identifizieren Sie die Datenobjekte und Funktionen, die die undokumentierte API bereitstellt.
2. Erstellen Sie ein ABAP-Cloud-Datenobjekt (CDS View Entity) im SAP-System, das die gleichen Daten bereitstellt.
3. Nutzen Sie das RAP-Framework, um daraus einen OData v4-Service zu generieren.
4. Exponieren Sie den Service ueber die SAP BTP Integration Suite.
5. Stellen Sie die externe Integration auf den neuen BTP-Endpunkt um.
6. Deaktivieren Sie die alte, undokumentierte Verbindung.

Enterprise-Beispiel: Ein Maschinenbauer in Augsburg musste eine kritische Schnittstelle zwischen SAP und seinem PLM-System (Product Lifecycle Management) migrieren. Die alte Integration nutzte einen undokumentierten RFC-Funktionsbaustein, um Stuecklisten (BOMs) abzurufen. Der neue Ansatz: Ein CDS View Entity auf die STPO/STKO-Tabellen, exponiert als OData v4 ueber RAP, zugaenglich ueber die BTP API Management. Migrationszeit: 4 Wochen. Ergebnis: Eine stabile, dokumentierte, policy-compliant Schnittstelle mit besserer Performance als die alte RFC-Verbindung.

Schritt 5: KI-Integrationen auf SAP-konforme Architekturen umstellen

Abschnitt 2.2.2 der API Policy v4/2026 verbietet ausdruecklich die Nutzung von SAP-APIs durch „(semi-)autonome oder generative KI-Systeme, die Sequenzen von API-Aufrufen planen, auswaehlen oder ausfuehren“. Wenn Ihr Unternehmen KI-Systeme einsetzt, die mit SAP-Daten arbeiten – etwa Microsoft Copilot, einen selbstentwickelten KI-Agenten oder eine Integrationsplattform mit KI-gesteuerter Orchestrierung – muessen Sie diese Integrationen umbauen.

Drei Optionen stehen zur Verfuegung:

Option A – SAP-eigene KI nutzen: Migrieren Sie Ihren KI-Use-Case auf SAP Joule oder SAP AI Core. Diese Loesungen sind per Definition policy-compliant. Nachteil: Sie sind an SAPs KI-Oekosystem gebunden und koennen moeglicherweise nicht alle Use Cases abdecken, die Ihr bestehendes KI-System bedient.

Option B – Datenexport statt API-Zugriff: Exportieren Sie die benoetigten SAP-Daten regelmaessig in ein externes Datenlager (Data Lake, Data Warehouse), das dann von Ihrem KI-System genutzt wird. Der Export erfolgt ueber veroeffentlichte APIs und zeitgesteuerte Batch-Prozesse – nicht ueber autonome Agenten. Ihr KI-System arbeitet dann mit den exportierten Daten, nicht direkt mit SAP.

Option C – Mensch-in-der-Schleife: Bauen Sie Ihre KI-Integration so um, dass das KI-System API-Aufrufe vorschlaegt, aber ein Mensch sie ausfuehrt oder explizit genehmigt. Damit faellt die Integration nicht mehr unter die Definition von „(semi-)autonomen Systemen, die API-Aufrufe planen und ausfuehren“. Das ist ein Workaround, der die Compliance sichert, aber die Effizienz reduziert.

Enterprise-Beispiel: Ein Logistikunternehmen in Hamburg hatte einen KI-Agenten entwickelt, der eigenstaendig Bestellstatus in SAP abfragte, Liefertermine berechnete und automatisch Kundenbenachrichtigungen ausloeste – alles ueber eine Kette von 5-8 API-Aufrufen pro Vorgang. Nach der Policy-Aenderung hat das Team auf Option B umgestellt: Die relevanten SAP-Daten werden stuendlich in eine PostgreSQL-Datenbank exportiert, der KI-Agent arbeitet mit den exportierten Daten. Die Latenz hat sich um maximal 60 Minuten erhoeht – fuer den Anwendungsfall akzeptabel.

Schritt 6: Testen, dokumentieren und abnehmen

Jede migrierte Integration muss gruendlich getestet und dokumentiert werden. Das klingt nach Standard-Softwareentwicklung – aber die Besonderheit bei API-Migrationen liegt darin, dass semantische Aequivalenz sichergestellt werden muss: Der neue API-Endpunkt muss exakt die gleichen Daten im gleichen Format liefern wie die alte, undokumentierte Schnittstelle.

Teststrategie: Fuehren Sie parallelene Tests durch, indem Sie fuer einen definierten Zeitraum (mindestens 2 Wochen) sowohl die alte als auch die neue Integration laufen lassen und die Ergebnisse vergleichen. Achten Sie besonders auf: Datenformate (Datumsformate, Dezimaltrennzeichen – ein Klassiker bei deutschsprachigen SAP-Systemen), Datenvolumen (liefert die neue API alle Datensaetze, die die alte geliefert hat?), Performance (ist die neue Integration schnell genug fuer Ihre SLAs?) und Fehlerbehandlung (wie reagiert die neue Integration auf Timeouts, fehlende Daten oder Berechtigungsfehler?).

Dokumentation: Erstellen Sie fuer jede migrierte Integration eine Dokumentation, die folgendes enthaelt: alte API (welche undokumentierte Schnittstelle wurde ersetzt), neue API (welcher veroeffentlichte Endpunkt oder BTP-Wrapper wird genutzt), Datenmapping (wie wurden die Datenfelder zugeordnet), Testergebnisse (Protokoll des Paralleltests) und Compliance-Bestaetigung (die Bestaetigung, dass die neue Integration mit der API Policy v4/2026 konform ist). Diese Dokumentation ist nicht nur fuer Ihre eigene Absicherung wichtig – sie kann auch bei einem SAP-Audit als Nachweis der Compliance dienen.

Schritt 7: Laufendes API-Monitoring und Governance einrichten

Die Migration ist kein einmaliges Projekt – sie ist der Beginn einer permanenten API-Governance. SAP kann den Business Accelerator Hub jederzeit aendern: APIs koennen hinzugefuegt, aktualisiert oder entfernt werden. Neue Policy-Versionen koennen weitere Einschraenkungen bringen. Und Ihre eigene IT-Landschaft entwickelt sich weiter – mit jeder neuen Integration entsteht potenziell ein neues Compliance-Risiko.

Praktisches Vorgehen: Richten Sie ein API-Governance-Board ein, das quartalsweise alle SAP-Integrationen ueberprueft. Automatisieren Sie die Ueberwachung ueber die SAP BTP API Management, die API-Aufrufe loggt und bei ungewoehnlichen Mustern alarmiert. Abonnieren Sie den SAP Business Accelerator Hub Newsletter, um ueber API-Aenderungen informiert zu werden. Und schulen Sie Ihr Entwicklerteam regelmaessig – die API-Landschaft bei SAP aendert sich schneller, als die meisten Teams realisieren.

Enterprise-Beispiel: Ein Versicherungskonzern in Muenchen hat ein dediziertes „SAP API Competence Center“ mit drei Vollzeitstellen eingerichtet. Das Team ueberwacht alle SAP-Integrationen, prueft quartalsweise die Compliance und beratet die Fachabteilungen bei neuen Integrationsanforderungen. Die Investition: 350.000 Euro pro Jahr. Der Gegenwert: Null Compliance-Verstoeesse und eine durchschnittliche Time-to-Market fuer neue Integrationen von 3 Wochen statt vorher 12 Wochen.

Typische Fehler bei der API-Migration – und wie Sie sie vermeiden

In unserer Beratungspraxis sehen wir immer wieder die gleichen Fehler bei SAP-API-Migrationen. Hier die fuenf haeufigsten – und wie Sie sie umgehen:

Fehler 1: Alles auf einmal migrieren wollen. Unternehmen, die versuchen, alle non-compliant Integrationen gleichzeitig zu migrieren, ueberfordern ihr Team und riskieren Systemausfaelle. Besser: Wellenbasierter Ansatz mit 3-5 Integrationen pro Welle und 2-3 Wochen Stabilisierungsphase dazwischen.

Fehler 2: Die Fachabteilungen nicht einbeziehen. API-Migrationen sind kein reines IT-Projekt. Die Fachabteilungen muessen verstehen, warum die Migration noetig ist, und bei der Definition der funktionalen Anforderungen mitwirken. Ein CDS View Entity, das technisch korrekt ist, aber die falschen Daten liefert, nuetzt niemandem.

Fehler 3: Keine Rollback-Strategie haben. Jede Migration kann schiefgehen. Stellen Sie sicher, dass Sie die alte Integration jederzeit reaktivieren koennen – zumindest fuer eine Uebergangsperiode von 4-6 Wochen nach der Migration.

Fehler 4: Performance-Tests vergessen. Ein haeufiges Problem bei der Umstellung von RFC auf OData: Die Performance-Charakteristik aendert sich fundamental. Ein RFC, der 10.000 Datensaetze in 2 Sekunden liefert, kann als OData-Service 15 Sekunden brauchen, wenn das Paging nicht korrekt konfiguriert ist. Testen Sie die Performance unter realistischer Last.

Fehler 5: Die SAP BTP-Lizenzkosten unterschaetzen. BTP ist nicht kostenlos. Jeder Service, jede Integration und jeder API-Aufruf hat einen Preis. Kalkulieren Sie die laufenden BTP-Kosten in Ihre Migrationsplanung ein – sie koennen die einmaligen Migrationskosten innerhalb von 2-3 Jahren uebersteigen. Sprechen Sie fruehzeitig mit Ihrem SAP-Vertriebskontakt ueber BTP-Lizenzbuendel.

Skills und Team-Aufbau fuer die Migration

Die API-Migration erfordert ein spezifisches Skill-Set, das in den meisten deutschen SAP-Teams nicht vollstaendig vorhanden ist. Hier die Kernkompetenzen, die Sie brauchen:

SAP BTP Fundamentals: Verstaendnis der BTP-Architektur, Cloud Foundry Runtime, SAP Integration Suite und API Management. Dies ist die Grundlage fuer jeden Clean-Core-Wrapper.

ABAP Cloud und RAP: Das RESTful ABAP Programming Model ist das Rueckgrat der neuen API-Architektur. Entwickler muessen CDS View Entities, Behavior Definitions und Service Bindings beherrschen. Wer bisher nur klassisches ABAP kennt, braucht 4-8 Wochen intensive Schulung.

OData v4 und REST-Design: Verstaendnis von RESTful API-Design, OData-Konventionen, Paging, Filtering und Error Handling. Viele klassische SAP-Entwickler haben hier Nachholbedarf, weil sie bisher mit RFCs und BAPIs gearbeitet haben.

API Governance und Security: OAuth 2.0, API Keys, Rate Limiting, CORS und Content Security Policies. Die neuen BTP-APIs muessen korrekt abgesichert werden – ein unsicherer BTP-Wrapper ist schlimmer als eine undokumentierte API.

Wenn Ihr internes Team diese Skills nicht mitbringt, haben Sie zwei Optionen: Weiterbildung Ihrer bestehenden SAP-Entwickler (4-8 Wochen pro Person) oder die Rekrutierung erfahrener BTP-Spezialisten. Bei Programmier-Anfang sehen wir, dass qualifizierte SAP-BTP-Entwickler aktuell zu den meistgesuchten IT-Profis in Deutschland gehoeren – die Nachfrage uebersteigt das Angebot um den Faktor 3-4.