SAP BW Migration verständlich erklärtVon gewachsener Komplexität zur KI-fähigen Datenbasis
Antworten auf die Fragen, die Datenverantwortliche, BI-Architekten und SAP-Teams tatsächlich stellen – von der Migrationsstrategie über die ABAP-Modernisierung bis zu Datenprodukten und einer belastbaren Datengrundlage für KI.
Ausgangslage
Die Herausforderung SAP BW Migration verstehen
Eine SAP BW Migration umfasst die Überführung Ihrer gesamten SAP Business Warehouse Umgebung (BW 7.5) – einschließlich aller Datenmodelle, Transformationslogiken und Berichtsstrukturen – auf eine moderne Zielplattform. Der Anlass: SAP stellt die Standard-Wartung für BW 7.5 am 31. Dezember 2027 ein. Eine kostenpflichtige erweiterte Wartung läuft bis 2030, danach bedeutet Weiterbetrieb: keine neuen Funktionen, wachsende Sicherheitsrisiken und steigende Betriebskosten für ein System am Ende seines Lebenszyklus.
- Standard-Wartung für SAP BW 7.5 endet am 31. Dezember 2027
- Erweiterte Wartung bis 2030 verfügbar – Aufpreis ca. 2 % des Lizenzwerts pro Jahr
- Über 60 % der SAP-Transformationsprojekte überschreiten Budget und Zeitplan (Horváth-Studie 2025)
- Nur rund 15 % der SAP-Migrationen bleiben im geplanten Kosten- und Zeitrahmen
- Neue SAP-Funktionalität fließt ausschließlich in BW/4HANA, SAP Datasphere und SAP Business Data Cloud
Eine SAP BW Migration ist im Kern ein Wissens- und Logik-Reengineering-Problem – keine reine Datenverschiebung. SAPs moderne Plattformen arbeiten SQL-basiert; entsprechend müssen sämtliche ABAP-Startroutinen, Endroutinen und feldbasierten Transformationsregeln verstanden, der jeweiligen fachlichen Fragestellung zugeordnet und in einer neuen Sprache nachgebaut werden. Die meisten BW-Landschaften sind über 10 bis 20 Jahre organisch gewachsen, enthalten Tausende undokumentierter Objekte und Geschäftslogik, die von Personen erstellt wurde, die das Unternehmen längst verlassen haben.
- Jahrzehnte individueller ABAP-Logik in Transformationen und Routinen
- Tausende InfoProvider, DataStore-Objekte und MultiProvider – oft ohne belastbare Dokumentation
- Komplexe Abhängigkeiten zwischen Datenflüssen, Berichten und Frontend-Werkzeugen wie SAC oder Power BI
- Geschäftskritische Kennzahlen, die nach der Migration exakt dieselben Ergebnisse liefern müssen
- Das klassische Star-Schema und InfoCube-Modell ist architektonisch inkompatibel mit modernen Cloud-Plattformen
ABAP-Routinen in SAP-BW-Transformationen – Startroutinen, Endroutinen, Feldregeln – laufen auf modernen Cloud-Plattformen wie Snowflake, Databricks oder SAP Datasphere nicht nativ. Sie müssen extrahiert, hinsichtlich der kodierten Geschäftslogik analysiert und in eine zielplattformkompatible Sprache wie SQL, Python oder PySpark übersetzt werden. Diesen Schritt zu übergehen, zählt zu den häufigsten Migrationsfehlern – mit der Folge inkonsistenter Kennzahlen und fehlender Geschäftslogik im neuen System.
- ABAP-Code ist auf Cloud-nativen Plattformen nicht lauffähig
- Manuelles ABAP-Reverse-Engineering ist langsam, fehleranfällig und kostenintensiv
- KI-gestützte Werkzeuge automatisieren die Konvertierung von ABAP nach SQL/Python/PySpark und validieren die Ergebnisse gegen die Quelllogik
- Gängiger Richtwert: ca. 20 € Kosten pro manuell übersetzter Codezeile
- Durch Automatisierung lassen sich 50–60 % des manuellen Aufwands einsparen
Lift-and-Shift bezeichnet einen Migrationsansatz, bei dem bestehende SAP BW Objekte 1:1 ins neue Zielsystem übertragen werden – ohne Neugestaltung oder Umfangsreduktion. Der Vorteil ist ein schneller Projektstart; der Nachteil: die höchsten langfristigen Kosten und Risiken. Sämtliche Altlasten – ungenutzte Berichte, redundante Datenflüsse, undokumentierte Logik, doppelte Prozesse – wandern mit. In nutzungsabhängigen Cloud-Abrechnungsmodellen wird diese Redundanz zu einem dauerhaften, sich potenzierenden Kostenfaktor.
- In gewachsenen SAP-BW-Landschaften sind 40–70 % der Objekte erfahrungsgemäß kaum in Nutzung
- Cloud-Speicher- und Rechenkosten skalieren mit Datenvolumen und Komplexität
- Ungenutzte Objekte kosten doppelt: einmal bei der Migration, dann fortlaufend im Cloud-Betrieb
- Ohne Governance und Monitoring entsteht dieselbe Datenausbreitung in kürzester Zeit erneut
- On-Premises-Kosten sind fix; Cloud-Kosten sind variabel und verbrauchsbasiert – Redundanz treibt sie in die Höhe
Lift-and-Shift überträgt bestehende SAP BW Objekte 1:1 ins Zielsystem. Brownfield-Modernisierung bewahrt vorhandene Logik und optimiert sie selektiv. Greenfield baut das Datenmodell ausgehend von den aktuellen Geschäftsanforderungen komplett neu auf. Hybrid kombiniert bewährte BW-Logik mit neu konzipierten Datenstrukturen. Die Wahl hängt von der Qualität und dem Geschäftswert der bestehenden BW-Umgebung sowie der Zielarchitektur und den Migrationszielen ab.
Für die meisten Organisationen empfiehlt sich ein Brownfield- oder Hybrid-Ansatz, wenn vorhandene Logik noch Wert hat, aber unter Jahren an Komplexität und Redundanz begraben liegt. One Data empfiehlt Greenfield, wenn das bestehende Modell nicht mehr abbildet, wie das Unternehmen tatsächlich arbeitet.
| Ansatz | Geschäftslogik | Time-to-Value | Kosten- und Risikoprofil |
| Lift-and-Shift | Wird unverändert übernommen – einschl. bestehender Fehler und technischer Schulden | Schneller Start, langsame Wertrealisierung | Geringer Aufwand heute, hohe Folgekosten |
| Brownfield | Wird bewahrt und selektiv optimiert | Ausgewogen | Moderate, steuerbare Kosten |
| Greenfield | Wird von Grund auf neu gebaut; Altsystem dient als Referenz | Längste Anlaufphase | Höchster Anfangsaufwand, geringste Altlasten langfristig |
| Hybrid | Selektiv weiterverwendet neben neuen Datenstrukturen | Ausgewogen | Flexibel mit kontrollierter Modernisierung |
Cloud-Plattformen rechnen verbrauchsbasiert ab: Jede Abfrage, jedes gespeicherte Byte und jeder Rechenzyklus werden gemessen. On-Premises-Kosten für SAP BW sind fix und planbar, unabhängig vom Datenvolumen. In der Cloud hingegen sorgen mitgeschleppte Altlasten – ungenutzte Berichte, doppelte Datenflüsse, verwaiste Objekte – dafür, dass Rechen- und Speicherkosten exponentiell steigen. Ohne Governance beschleunigt sich diese Kostenspirale, weil auf den migrierten Altbestand neuer Datenwildwuchs aufwächst.
- Cloud-Kosten sind variabel und verbrauchsbasiert – nicht fix
- Redundante Logik erfordert zusätzliche Rechenleistung und Speicherkapazität
- Ungenutzte Berichte verbrauchen weiterhin Ressourcen und Wartungsaufwand
- Ohne FinOps-Funktion oder Governance-Modell eskalieren Kosten, bevor es jemand bemerkt
- Bereinigung vor der Migration ist der wirksamste Hebel zur Kostenkontrolle
SAP BW Metadaten umfassen die strukturellen und beschreibenden Informationen zu jedem Objekt Ihrer BW-Landschaft – Objektnamen, Beschreibungen, Abhängigkeiten, Datenherkunft, Transformationslogik und Nutzungsstatistiken. Sie bilden die Grundlage, um zu verstehen, was Ihr BW-System leistet, welche Objekte relevant sind und wie Daten durch Transformationen zu den Berichtsendpunkten fließen. Ohne Metadatenanalyse lassen sich keine fundierten Entscheidungen über Migration, Konsolidierung oder Stilllegung treffen.
- Metadaten offenbaren das vollständige „Skelett“ Ihrer SAP-BW-Architektur
- Nutzungsstatistiken zeigen, welche Berichte und Abfragen produktiv verwendet werden
- Abhängigkeitsanalysen machen sichtbar, wie Objekte untereinander und mit Frontend-Werkzeugen zusammenhängen
- ABAP-Quellcode kann parallel zu Metadaten für die automatisierte Konvertierung extrahiert werden
- Metadaten-Analyse ersetzt monatelange manuelle Bestandsaufnahme durch automatisierte Transparenz
Ein Data Product ist ein eigenständiges, wiederverwendbares Daten-Asset, das die zugrunde liegenden Daten mit den Geschäftsregeln, die sie erzeugen, den Definitionen, die ihnen Bedeutung geben, und den Data-Quality-Verträgen, die ihre Zuverlässigkeit sicherstellen, bündelt. Für die SAP-BW-Migration verändert die Betrachtung in Data Products statt einzelner BW-Objekte grundlegend, wie eine Migration abgegrenzt, priorisiert und gesteuert wird – weg von technischer Vollständigkeit und hin zu Business Value.
Dabei ist es wichtig, zwischen diesem Ansatz und SAPs Definition von Data Products zu unterscheiden. SAP Data Products sind semantisch ausgerichtete Datenpakete, die vor allem für den Self-Service Konsum innerhalb des SAP Business Data Cloud und Datasphere Ökosystems konzipiert sind. Sie können sowohl von SAP verwaltete Inhalte als auch kundenspezifische Daten aus SAP- und Non-SAP-Quellen enthalten.
One Data verfolgt einen breiteren, plattformunabhängigen Ansatz:
Ein Data Product ist nicht einfach ein für den Konsum zusammengestelltes Datenpaket. Es erfasst Daten, Business Logic, semantische Definitionen, Verantwortlichkeiten, Lineage und Qualitätsanforderungen als ein wiederverwendbares Asset – unabhängig davon, wo die Daten letztendlich gespeichert oder konsumiert werden.
Für eine SAP BW Migration bedeutet das:
- Governance ist integriert: Qualitätsstandards, Freshness-Schwellenwerte, Verantwortlichkeiten und Lineage sind Bestandteil des Data Products.
- Business Logic wird wiederverwendbar: Transformationsregeln und Definitionen werden unabhängig von der zugrunde liegenden Plattform erfasst.
- Migration wird flexibler: Dasselbe Data Product kann heute in der SAP Business Data Cloud und morgen in einer anderen Umgebung bereitgestellt werden.
- Wiederverwendung ersetzt Duplikation: Teams können dasselbe vertrauenswürdige Data Product nutzen, anstatt ähnliche Logik in verschiedenen Systemen neu aufzubauen.
Das Ergebnis ist ein Perspektivwechsel von „Welche BW-Objekte migrieren wir?“ zu „Welche business-ready Data Products brauchen wir – und wo sollen sie betrieben werden?“
Gartner® hat One Data als Sample Vendor für Data Products und Data Contracts ausgezeichnet.
KI-Modelle und -Agenten sind nur so zuverlässig wie die Daten, die sie verarbeiten. Wer KI auf fragmentierte, undokumentierte oder inkonsistente SAP BW Daten aufsetzt, erzeugt keine künstliche Intelligenz – sondern künstliche Halluzinationen. Das bestätigt der BARC Data, BI and Analytics Trend Monitor 2026: Datenqualitätsmanagement führt die Prioritätenliste der Unternehmen mit 7,9 von 10 Punkten an, während generative KI nur auf 5,5 kommt. Datawarehouse-Modernisierung liegt mit 6,1 ebenfalls vor den KI-Themen.
- KI-Agenten interpretieren Datenbedeutung – fehlen Kontext und Semantik, sind die Ergebnisse unzuverlässig
- Datenqualität und Datensicherheit führen die Unternehmensprioritäten gemeinsam mit 7,9/10 an (BARC 2026)
- Datawarehouse-Modernisierung (6,1/10) rangiert vor generativer KI (5,5/10) und agentischer KI (4,5/10)
- Modernisierungsbedarf ist seit 2022 durchgängig unter den Top-8-Prioritäten – ein strukturelles, kein zyklisches Thema
- ISG-Analysen belegen: Der KI-Ertrag nach einer Migration hängt an sauber verwalteten Daten und der Integration von SAP- und Nicht-SAP-Quellen
SAP stellt die Standard-Wartung für SAP BW 7.5 am 31. Dezember 2027 ein. Unternehmen, die BW auf HANA betreiben, können eine Verlängerung verhandeln – diese reicht jedoch nur bis Ende 2030 und kostet einen jährlichen Aufpreis von ca. 2 % des Lizenzwerts. Danach bedeutet Festhalten am klassischen BW: keine neuen Funktionen, wachsende Sicherheits- und Compliance-Risiken, Auslaufen der Excel-basierten BEx-Frontends und zunehmender Mangel an qualifiziertem Personal.
- Standard-Wartung endet: 31. Dezember 2027
- Erweiterte Wartung (gegen Aufpreis): endet 31. Dezember 2030
- Alle neuen SAP-Funktionalitäten fließen in BW/4HANA, Datasphere und Business Data Cloud
- Je näher die Frist rückt, desto größer der Wert jedes beschleunigenden Werkzeugs
- Projekte dauern im Schnitt 30 % länger als geplant (Horváth 2025)
Bewertung
Migrationsansätze, Plattformen und Werkzeuge evaluieren
Die gängigsten Zielplattformen für SAP BW Migrationen sind BW/4HANA, SAP Datasphere, SAP Business Data Cloud (BDC), Snowflake, Databricks und Microsoft Fabric. Innerhalb des SAP-Ökosystems bieten Datasphere und BDC Kontinuität und tiefe Integration. Offene Plattformen wie Snowflake und Databricks bringen Vorteile bei KI-/ML-Workloads, plattformübergreifender Analyse und Herstellerunabhängigkeit. Viele Organisationen wählen hybride Architekturen, die beides kombinieren.
- BW/4HANA: Konservativster Weg; bleibt nah an der bestehenden Landschaft, kann aber technische Schulden mitschleppen. Support bis 2040 verlängert den Zeithorizont, ersetzt jedoch keine Modernisierung.
- SAP Datasphere / SAP Business Data Cloud: Brownfield-Modernisierung innerhalb des SAP-Ökosystems
- Snowflake: Verbreitet für offenes Cloud-Data-Warehousing; flache, breite Modelle; SQL-nativ
- Databricks: Stärken bei KI/ML, Lakehouse-Architektur, PySpark-/Python-Ökosystem
- Microsoft Fabric: Integrierte Analytik auf Azure; wachsend in Microsoft-zentrierten Organisationen
- Hybrid: In der Praxis am häufigsten – SAP-nahe Prozesse in BDC / Datasphere, Analytik- und KI-Workloads auf Snowflake oder Databricks
Nein – ein blindes Kopieren ist riskant und teuer. Moderne Cloud-Lakehouses erwarten flache, breite Datenmodelle, nicht die starren, voraggregierten InfoCubes von SAP BW. Ein reiner Lift-and-Shift transportiert redundante und obsolete Daten, bläht Speicher- und Rechenkosten auf und setzt Sie zwei zusätzlichen Risiken aus: ODP-Extraktionsbeschränkungen (nicht mehr zertifiziert für Nicht-SAP-Konsumenten) und SAP-Lizenzgebühren für indirekten Zugriff, die fällig werden können, wenn SAP-erzeugte Daten von Drittsystemen gelesen werden.
- Moderne Plattformen lehnen starre, voraggregierte Strukturen ab – gefragt sind flache, breite Modelle
- ODP (Operational Data Provisioning) ist für Nicht-SAP-Konsumenten nicht mehr zertifiziert
- SAPs Modell für digitalen Zugriff kann Lizenzgebühren auslösen, wenn Daten in Nicht-SAP-Systeme kopiert werden
- Konsolidieren, vereinfachen und nur geschäftskritische Daten selektiv migrieren, bevor sie SAP verlassen
- Eine Plattform zur Migrationsoptimierung kann Daten und Logik scannen, bereinigen und gezielt überführen
SAPs Lizenzmodell für indirekten Zugriff (auch „Digital Access“) kann Gebühren auslösen, wenn SAP-erzeugte Daten von einem Nicht-SAP-System gelesen oder dorthin kopiert werden – de facto eine „Datenduplizierungssteuer“. Das ist ein erhebliches verstecktes Kostenrisiko bei jeder SAP BW Migration auf Nicht-SAP-Ziele wie Snowflake oder Databricks. Als Gegenmaßnahme empfiehlt sich: Daten konsolidieren und nur geschäftskritische Bestände selektiv migrieren, bevor sie die SAP-Umgebung verlassen.
- Greift, wenn SAP-Daten von Drittsystemen außerhalb von SAP abgerufen werden
- Kann bei unzureichender Steuerung zu überraschenden Audit-Nachforderungen führen
- Das Risiko steigt mit dem Volumen der außerhalb von SAP replizierten Daten
- Bereinigung und Vereinfachung vor der Migration ist die wichtigste Gegenmaßnahme
- Ein Cloud Center of Excellence oder eine FinOps-Funktion hilft, diese variablen Kosten zu steuern
ODP (Operational Data Provisioning) ist SAPs klassische Schnittstelle zur Extraktion von Daten aus SAP-Systemen in nachgelagerte Konsumenten. SAP hat signalisiert, dass ODP für Nicht-SAP-Konsumenten künftig nicht mehr zertifiziert ist – bestehende Extraktionspipelines auf ODP-Basis werden damit zur „Infrastruktur auf Abruf“. Organisationen müssen auf CDS Views (Core Data Services) und moderne APIs umstellen – ein Aufwand, der häufig umfangreich, technisch anspruchsvoll und nicht budgetiert ist.
- ODP war die Standard-Extraktionsschnittstelle für SAP-BW-Daten
- Für Nicht-SAP-Zielsysteme ist ODP nicht mehr zertifiziert
- Bestehende ODP-basierte Pipelines erfordern eine Neugestaltung auf CDS Views und moderne APIs
- Dieser Umbau ist häufig nicht budgetiert und trifft Organisationen unvorbereitet
- Werkzeuge zur Migrationsoptimierung helfen, den Umbauumfang zu ermitteln und zu automatisieren
Bereinigen vor Migrieren – das ist die wichtigste Grundregel. On-Premises-Kosten sind fix, aber Cloud-Abrechnung ist verbrauchsbasiert; wird Altlast-Redundanz in die Cloud mitgenommen, explodieren Rechen- und Speicherkosten. Der bewährte Ansatz: ungenutzte Objekte stilllegen, redundante Modelle vereinfachen und von Tag eins eine Governance-Struktur etablieren – etwa eine FinOps-Funktion oder ein Cloud Center of Excellence – um variable Ausgaben zu kontrollieren.
- Vor der Migration eine Nutzungs- und Abhängigkeitsanalyse durchführen, um Überflüssiges zu identifizieren
- Die 40–70 % der Objekte entfernen, die in gewachsenen BW-Landschaften erfahrungsgemäß kaum genutzt werden
- Fortlaufende Monitoring-Dashboards einrichten, um Datennutzung zu verfolgen und künftige Aufblähung zu verhindern
- Eine FinOps-Funktion oder ein Cloud Center of Excellence für die Kostensteuerung aufbauen
- Migration in Wellen nach Geschäftswert planen – nicht nach technischer Vollständigkeit
One Data ist eine Datenprodukt-Plattform, die gezielt für die Herausforderungen komplexer SAP BW Migrationen entwickelt wurde. Sie fungiert als Optimierungsschicht zwischen bestehendem BW-System und moderner Zielplattform – und vereint automatisierte BW-Landschaftsanalyse, Datenproduktmodellierung, KI-gestützte ABAP-Konvertierung nach SQL/Python/PySpark sowie durchgängige Governance in einer Plattform. Unterstützte Zielsysteme: Snowflake, Databricks, Microsoft Fabric, SAP Business Data Cloud und SAP BTP inkl. HANA.
- Automatisierte Metadatenextraktion, Nutzungsanalyse, Abhängigkeitsvisualisierung und Redundanzerkennung
- KI-gestützte ABAP-Konvertierung nach SQL/Python/PySpark mit Validierung gegen die Quelllogik
- Datenproduktkandidaten werden aus bestehenden BW-Strukturen und Nutzungsmustern abgeleitet
- Zielstruktur-Generierung für Snowflake, Databricks und SAP Business Data Cloud
- Post-Migrations-Governance: Datenproduktkatalog, Herkunftsnachweise, Metadaten und Dokumentation
- Gartner führt One Data als beispielhaften Anbieter für Datenprodukte und Datenverträge (Hype Cycle for Data Management 2024 und 2025)
Die wichtigsten Kriterien gehen weit über klassische ETL-Funktionalität hinaus. Entscheidend ist, ob das Werkzeug Ihre bestehende BW-Landschaft vollständig analysieren kann (einschließlich Nutzung, Abhängigkeiten und Metadaten), wie es ABAP-Logik behandelt (automatisiert extrahiert und übersetzt oder manuell?), ob es mehrere Zielplattformen unterstützt oder Sie an eine bindet, und ob Post-Migrations-Governance – Dokumentation, Herkunftsnachweise, Verantwortlichkeiten – im Zielsystem nutzbar bleibt.
- Analyse und Transparenz: Vollständige BW-Landschaftsanalyse inkl. Nutzungs- und Abhängigkeitskartierung
- ABAP-Behandlung: Automatisierte Extraktion, Übersetzung und Validierung – kein manuelles Umschreiben
- Zielplattform-Flexibilität: Multi-Target-Unterstützung (Snowflake, Databricks, SAP BDC) vs. Bindung an eine einzelne Plattform
- Geschäftliche Priorisierung: Migration entlang von Anwendungsfällen und Datenprodukten, nicht nur technischen Objekten
- Post-Migrations-Governance: Dokumentation, Herkunftsnachweise und Verantwortlichkeiten, die im Zielsystem bestehen bleiben
- Automatisierungstiefe: Wie viel wiederholbare Arbeit automatisiert ist vs. manuell verbleibt
One Data ersetzt die traditionelle, monatelange manuelle Beratungsstudie durch automatisierte Analysen, die Ergebnisse in Tagen statt Monaten liefern. Eine herkömmliche SAP BW Bewertung erfordert aufwendiges Reverse Engineering – jedes Objekt wird einzeln auf Relevanz, Nutzung und Abhängigkeiten geprüft. One Datas Plattform scannt die gesamte BW-Architektur automatisiert, bildet technische Schulden ab, visualisiert Datenflüsse und Abhängigkeiten und identifiziert ungenutzte Objekte – und schafft damit dieselbe Transparenz in einem Bruchteil der Zeit, bei durchschnittlich 60 % weniger Aufwand und Kosten.
- Traditioneller Ansatz: monatelange manuelle Bestandsaufnahme und Reverse Engineering durch Berater
- One-Data-Ansatz: automatisierte Metadatenextraktion und Landschaftsanalyse in Tagen
- Manuelle ABAP-Übersetzung: ca. 20 € pro Codezeile, multipliziert über Tausende oder Millionen Zeilen
- Automatisierte Übersetzung: 50–60 % weniger manueller Aufwand bei validiertem Ergebnis
- Das Vier-Stufen-Framework: Analysieren → Klassifizieren → Transformieren → Empfehlen
Das SAP BW X-Ray ist ein kostenfreies Assessment-Paket von One Data, das ein vollautomatisiertes Diagnosewerkzeug mit individuellem Experten-Coaching kombiniert. Ziel: sofortige Transparenz über Ihre SAP BW Landschaft. In einer 6-stündigen praxisorientierten Coaching-Session parametrisieren One Data Experten das X-Ray-Werkzeug für Ihre Umgebung und erzeugen ein vollständiges „Skelett-Mapping“, das exakt zeigt, was behalten, konsolidiert oder stillgelegt werden sollte – ohne Risiko, Systemeingriffe oder Verpflichtung.
- Automatisiertes Skelett-Mapping Ihres gesamten BW-Systems in Stunden statt Monaten
- Individuelle Coaching-Session zur Konfiguration des Werkzeugs für Ihre spezifische Umgebung
- Identifiziert redundante Berichte, ungenutzte Logik und Konsolidierungspotenziale
- Generiert eine Vereinfachungs-Roadmap auf Basis tatsächlicher Nutzungsmuster
- Richtet fortlaufende Monitoring-Dashboards ein, um Datennutzung zu verfolgen und künftige Aufblähung zu verhindern
- Erfordert ausschließlich lesenden Zugriff auf SAP-BW-Metadaten und ABAP-Code
Die Zeitrahmen für SAP BW Migrationen variieren erheblich – von wenigen Monaten für fokussierte Modernisierungen bis zu mehreren Jahren für große, historisch gewachsene Landschaften. Entscheidend sind Umfangsdefinition, ABAP-Komplexität, Wahl der Zielplattform, interne Kapazitäten und die Frage, ob ein phasenweiser Wellenansatz oder ein Big-Bang verfolgt wird. Eine rigorose Vorabanalyse macht Zeit- und Kostenschätzungen deutlich belastbarer, und automatisierte Werkzeuge können Monate manueller Arbeit auf Wochen komprimieren.
- Kleine, fokussierte Migrationen: wenige Monate
- Große, komplexe Landschaften: 2–4 Jahre
- Projekte dauern im Schnitt 30 % länger als geplant (Horváth 2025)
- Eine saubere Vorabanalyse (Metadaten, Nutzung, Abhängigkeiten) macht Schätzungen belastbarer
- Wellenbasierte Migrationen liefern Wert inkrementell und reduzieren Risiko gegenüber Big-Bang-Ansätzen
Ein semantischer Migrationsansatz bedeutet: die fachliche Bedeutung hinter den SAP BW Objekten verstehen, bevor sie verschoben werden – statt Code Zeile für Zeile zu übersetzen. Anstelle einer rein technischen Codekonvertierung wird erfasst, welchen Geschäftszweck jede Transformation erfüllt, dieser in governierte Datenprodukte verpackt und daraus sauberer, optimierter Zielcode generiert. Das Ergebnis: eine Zielumgebung, die sauberer und vertrauenswürdiger ist als das System, das sie ersetzt.
- Ausgangspunkt ist die fachliche Bedeutung und Absicht – nicht die ABAP-Syntax
- Erzeugt plattformunabhängige Datenprodukte statt plattformspezifischem Code
- KI-Agenten generieren aus der erfassten Fachlogik sauberes SQL oder Python
- Ergebnis: verkürzte Zeitpläne, geringere Kosten und eine sauberere Zielumgebung
- Das semantische Modell wird zur lebenden Dokumentation der Datenlandschaft des Unternehmens
Entscheidung
Die Migration zum Erfolg führen
- 1:1-Migration ohne Umfangsreduktion: Ungenutzte Objekte kosten doppelt – bei der Migration und fortlaufend in der Cloud
- ABAP-Logik als „machen wir später“ behandeln: Führt zu fehlenden oder fehlerhaften Kennzahlen beim Go-live
- Plattformwahl ohne Datenstrategie: Technisch elegant, aber am Geschäftsbedarf vorbei
- Fehlende geschäftliche Priorisierung: Rein technische Planung verliert die Unterstützung der Fachbereiche
- Migration ohne Governance-Modell: Erzeugt dieselbe Intransparenz in der Cloud – nur teurer
Sechs bewährte Erfolgsmuster gelten unabhängig von der Zielplattform: Transparenz schaffen, bevor Entscheidungen fallen; in Datenprodukten statt BW-Objekten denken; ABAP-Logik frühzeitig und parallel zur Zielarchitektur systematisieren; in Wellen nach fachlichem Anwendungsfall migrieren; die Zielarchitektur plattformunabhängig halten; und Governance sowie Betriebsmodell ab Tag eins planen. Jede Welle sollte sichtbaren Geschäftswert liefern und Vertrauen für die nächste aufbauen.
- Transparenz vor Entscheidungen: Nutzung, Abhängigkeiten und Geschäftslogik analysieren, bevor Werkzeuge oder Plattformen gewählt werden
- In Datenprodukten denken: Governierte, wiederverwendbare Geschäfts-Assets migrieren – nicht einzelne BW-Objekte
- ABAP früh systematisieren: Extraktion und Übersetzung parallel zum Design der Zielarchitektur ausführen
- In Wellen migrieren: Organisation nach fachlichem Anwendungsfall; jede Welle liefert sichtbaren Mehrwert
- Architektur plattformunabhängig halten: Datenprodukte und dokumentierte Semantik überdauern plattformspezifische Optimierungen
- Governance ab Tag eins planen: Verantwortlichkeiten, Dokumentation und Datenprodukt-Lebenszyklusmanagement sind keine Nachgedanken
One Data führt die Migration durch fünf logische Stufen: Metadaten extrahieren und laden, Umfang optimieren und reduzieren, neugestalten und übersetzen, Code bereitstellen und ausführen, validieren und iterieren. Die Plattform ersetzt keine strategischen Entscheidungen – sie liefert die datenbasierte Grundlage, auf der diese Entscheidungen belastbar getroffen werden können, bei durchschnittlich 60 % weniger Aufwand und Kosten gegenüber manuellen Ansätzen.
- Metadaten extrahieren und laden: Verbindung zum SAP BW System herstellen und Metadaten, Nutzungsstatistiken sowie ABAP-Quellcode automatisiert in eine Wissensschicht aufnehmen
- Umfang optimieren und reduzieren: Inaktive Objekte identifizieren, Migrationsumfang auf das geschäftlich Genutzte reduzieren und Einsparpotenziale quantifizieren
- Neugestalten und übersetzen: Ziel-Datenprodukte mit definierten Verantwortlichkeiten und Qualitätsverträgen entwerfen; KI-Agenten übersetzen ABAP in SQL/Python/PySpark
- Code bereitstellen und ausführen: Generierte Pipelines im Zielsystem ausführen; Validierung gegen Governance-Verträge
- Validieren und iterieren: Durchgängige Transparenz, Qualitätsmonitoring und Governance, die über den Go-live hinaus wirken
Organisationen, die One Data für die SAP BW Migration einsetzen, erreichen im Durchschnitt eine Reduktion von Kosten und Lieferzeit um 60 % (abhängig von der Codekomplexität), eine reduzierte Migrationslast durch Entfernung der 40–70 % ungenutzter Objekte, die in gewachsenen Landschaften typisch sind, sowie eine Zielumgebung, die messbar sauberer ist als das abgelöste Altsystem. Nach der Migration ermöglicht durchgängige Governance 40 % geringere Wartungskosten und eine skalierbare, KI-fähige Architektur.
- Vor der Migration: Reduzierter Umfang, niedrigere Cloud-Kostenprognosen, klare Priorisierungs-Roadmap
- Während der Migration: Durchschnittlich 60 % Kosten- und Zeitersparnis durch KI-automatisierte ABAP-Konvertierung
- Nach der Migration: 40 % geringere Wartungskosten, skalierbare KI-fähige Architektur, starke fachliche Verantwortung
- Plattformunabhängige Datenprodukte, die teamübergreifend und systemübergreifend wiederverwendbar sind
- Durchgängige Herkunftsnachweise von der BW-Quelle bis zum Datenprodukt im Zielsystem
Datenprodukte werden nach der Migration zum operativen Rückgrat Ihres Datenbestands. Da jedes Produkt ein eigenständiger Baustein mit eingebetteter Governance, Qualitätsregeln, Herkunftsnachweisen und fachlichen Definitionen ist, kann jedes Team es auffinden, verstehen und in neuen Kontexten bereitstellen – ohne Logik von Grund auf rekonstruieren zu müssen. Das verhindert den „Migrations-Kater“: eine technisch moderne Plattform, die wie das alte BW betrieben wird und auf der erneut Datenwildwuchs und Kostenüberschreitungen entstehen.
- Der Datenprodukt-Marktplatz verhindert Doppelarbeit und ermöglicht Self-Service-Nutzung
- Automatisierte Dokumentation und Governance bleiben aktuell, wenn sich das System weiterentwickelt
- Qualitätsverträge (Aktualität, Schema, Service-Level-Zusagen) werden kontinuierlich durchgesetzt
- Dasselbe Datenprodukt dient Finanzanalysten, Lieferkettenplanern und Data Scientists
- KI-Fähigkeit ist kein einmaliger Meilenstein beim Go-live, sondern eine Eigenschaft, die die Governance-Schicht dauerhaft erhält
Kontinuierliches Monitoring und Governance sind unverzichtbar – ohne sie kehrt derselbe Datenwildwuchs, der im Legacy-BW Probleme verursacht hat, innerhalb von Monaten zurück, nun zu Cloud-Preisen. One Data bietet fortlaufende Berichts- und Tracking-Funktionen, darunter Dashboards mit Frühwarnsystemen, die alarmieren, wenn Nutzungsmuster auf steigende Kosten, Datenqualitätsabweichungen oder sich bildende Redundanzen hindeuten.
- Monitoring-Dashboards einrichten, um Nutzungsmuster und Kostentrends zu verfolgen
- Frühwarnsysteme implementieren, die steigende Kosten melden, bevor sie zum Problem werden
- Klare Verantwortlichkeiten für jedes Datenprodukt im Zielsystem zuweisen
- Datenverträge einsetzen, um Qualitätsstandards, Aktualitätsschwellen und Zugriffsbeschränkungen durchzusetzen
- Governance als fortlaufendes Betriebsmodell betrachten – nicht als einmalige Migrationsaktivität
Vertrauenswürdige Daten zeichnen sich durch vier Eigenschaften aus: klare Verantwortlichkeit (jemand ist rechenschaftspflichtig), Transparenz (durchgängige Herkunftsnachweise, die jede Zahl bis zur Quelle rückverfolgen), automatisierte Qualitätsprüfungen (Probleme werden erkannt, bevor sie Dashboards oder KI-Modelle erreichen) und eingebetteter Fachkontext (die Daten bedeuten für alle dasselbe). Ohne diese Eigenschaften widersprechen sich Dashboards, erzählen Kennzahlen je nach Quelle unterschiedliche Geschichten und liefern KI-Agenten zuversichtlich falsche Ergebnisse.
- Verantwortlichkeit: Jemand ist für die Korrektheit jedes Daten-Assets rechenschaftspflichtig
- Transparenz: Jeder Datenpunkt lässt sich lückenlos bis zur Quelle zurückverfolgen
- Qualität: Automatisierte Prüfungen fangen Probleme ab, bevor sie Konsumenten erreichen
- Kontext: Fachliche Semantik ist eingebettet, nicht vorausgesetzt
- Datenprodukte liefern alle vier Eigenschaften von Haus aus – Vertrauen wird Teil der Architektur, nicht nachträglich aufgesetzt
One Datas KI-gestützte Konvertierungsagenten übersetzen ABAP nicht einfach Syntax-für-Syntax nach SQL – sie arbeiten auf Basis der erfassten fachlichen Absicht. Die Plattform baut zunächst ein semantisches Verständnis dessen auf, was jede ABAP-Routine erreichen soll (die Geschäftsregel, die sie durchsetzt), und generiert dann sauberen, optimierten Zielcode. Jede Übersetzung wird gegen die Quelllogik validiert, um nachweislich korrekte Geschäftsregelübernahme sicherzustellen. Architekten behalten durchgängig die Steuerung und können die Ergebnisse nach Bedarf anpassen.
- KI-Agenten analysieren ABAP-Routinen und erfassen die darin kodierten Geschäftsregeln
- Übersetzungen erzeugen sauberes SQL, Python oder PySpark – keine literale Syntaxkonvertierung
- Jede Übersetzung wird gegen die ursprüngliche Quelllogik validiert
- Architekten prüfen und justieren die Ergebnisse – Automatisierung entfernt Aufwand, nicht Kontrolle
- Unterstützte Zielsysteme: Snowflake, Databricks, Microsoft Fabric, SAP Business Data Cloud, SAP BTP inkl. HANA
Ja – One Data ist bewusst plattformunabhängig konzipiert und unterstützt alle gängigen Zielplattformen: SAP-zentriert (BW/4HANA, SAP Datasphere, SAP Business Data Cloud), Nicht-SAP (Snowflake, Databricks, Microsoft Fabric) und hybride Architekturen, die beides kombinieren. Da Datenprodukte plattformunabhängig definiert werden, lässt sich dasselbe Produkt heute in SAP Business Data Cloud und morgen in Snowflake oder Databricks bereitstellen – ohne Logik von Grund auf neu bauen zu müssen.
- Unterstützte SAP-Zielsysteme: BW/4HANA, SAP Datasphere, SAP Business Data Cloud, SAP BTP inkl. HANA
- Unterstützte Nicht-SAP-Zielsysteme: Snowflake, Databricks, Microsoft Fabric
- Ein Zielplattformwechsel während des Projekts ist handhabbar – kein kompletter Neustart
- Plattformunabhängige Datenprodukte gewährleisten volle Flexibilität über die Daten-Assets
- Hybrid ist in der Praxis die häufigste Architektur
One Data arbeitet mit einem starken Ökosystem aus Technologiepartnern, SAP-Spezialisten, Beratungshäusern, Implementierungspartnern und ISVs zusammen, um SAP BW Migrationen durchgängig zu unterstützen. Das Ökosystem bündelt Expertise in SAP-Metadatenextraktion, Datenintegration, Datenprodukten, Governance und Modernisierung und verbindet diese mit SAP-Technologien und Zielplattformen. So kann One Data bestehende Kundenumgebungen ergänzen und unterschiedliche Migrationsstrategien und Zielarchitekturen unterstützen.
Weiterführende Inhalte
Für einen tieferen Einblick in bestimmte Aspekte:
Strategie
How to Approach an SAP BW Migration ↗ — Strategischer Überblick über Migrationspfade
Perspektive
Beyond the Migration ↗ — Warum die BW-Migration mehr ist als nur ein IT-Projekt
Methodik
Smart SAP BW Migration Whitepaper ↗ — Datenprodukte als Migrationsstrategie
Anwendung
Interactive SAP BW Migration Tour ↗ — Eine interaktive Anleitung
Lösungsübersicht
Sind Sie bereit, Ihre SAP-BW-Migration zu optimieren?
Wenn Sie eine SAP-BW-Migration planen – oder Ihren derzeitigen Ansatz hinterfragen –, ist eine strukturierte Analyse Ihrer bestehenden BW-Landschaft der beste nächste Schritt. In einer gemeinsamen Sitzung zeigen wir Ihnen, wie Sie Nutzung, Abhängigkeiten und Optimierungsmöglichkeiten sichtbar machen können – und welche Migrationsstrategie zu Ihrem Zielbild passt.