Erst verstehen, dann migrieren: Verschieben allein schafft kein Verständnis

Die meisten SAP-BW-Cloud-Migrationen scheitern daran, dass niemand mehr weiß, was die Daten eigentlich bedeuten. Unternehmen investieren Millionenbudgets, um Objekte zu verschieben, deren fachliche Logik undokumentiert geblieben ist.

Das Ergebnis ist vorhersehbar: dieselben fragwürdigen Kennzahlen, nur auf schnellerer Infrastruktur. Was als Modernisierung geplant wird, endet als kostspielige Reproduktion alter Probleme auf neuer Hardware. Wer die Bedeutung seiner Daten nicht versteht, kann sie auch nicht migrieren – unabhängig davon, wie leistungsfähig die Zielplattform ist. Mit der konsequenten Neuausrichtung von SAP auf Cloud-native Plattformen, wie SAP Business Data Cloud, SAP Datasphere und BW/4 Hana, wird deutlich, dass die klassische BW-Landschaft ein Verfalls­datum hat. Migrationen werden zu einer zeitkritischen Pflichtveranstaltung.

Problem: Fragmentiertes Wissen

Eine typische SAP-BW-Umgebung im Unternehmenskontext ist ein Produkt von zehn bis zwanzig Jahren organischen Wachstums. Tausende von InfoCubes, Data Store Objects, MultiProvidern und Transformationen haben sich angesammelt – erstellt von Personen, die längst die Organisation verlassen haben, selten dokumentiert, noch seltener konsolidiert. Der entscheidende Faktor: Ein großer Anteil der geschäftskritischen Logik steckt nicht in transparenten Datenmodellen, sondern in individuellem Abap-Code – fachlich intransparent und persönlich gebunden.

SAPs moderne Zielplattformen sind auf SQL optimiert. Eine Migration erfordert daher nicht bloß die Verschiebung von Daten, sondern ein vollständiges Re-Engineering der Logik. Es muss verstanden werden, was jede Abap-Routine leistet, welche fachliche Fragestellung sie bedient, und sie muss anschließend in SQL oder anderen Sprachen re-implementiert werden. Dies ist kein syntaktischer Übersetzungsvorgang, sondern ein Paradigmenwechsel.

Sackgasse Bottom-up-Migration

Der vorherrschende Migrationsansatz behandelt diese Herausforderung als Code-Übersetzungsproblem. Tools und Beratungsmethodiken arbeiten von unten nach oben: sie inventarisieren technische Ob­jekte, ordnen ihnen technische Äquivalente in der Zielplattform zu und konvertieren sie einzeln. SAP selbst bietet leistungs­fähige Instrumente, die jeden Migrationsschritt adressieren.

Doch jedes dieser Werkzeuge betrachtet die einzelnen Objekte isoliert. Was keines leistet, ist ein übergreifendes Systemverständnis: Wie wirken die Objekte zusammen, und welchen geschäftlichen Zweck erfüllen sie gemeinsam? Tools können Regeln und Transformationslogik syntaktisch korrekt migrieren. Aber sie können nicht beurteilen, ob diese Regeln noch geschäftsrelevant sind.

Inkonsistenzen in die Cloud

Die Konsequenzen liegen auf der Hand: Redundante Objekte werden zusammen mit essenziellen migriert. Teams investieren Monate in die Rückwärtsanalyse von Logik, die einem Bericht dient, der seit Jahren irrelevant ist. Technische Altlasten werden ungefiltert in die Cloud überführt. Und wo Definitionen in der Quelle inkonsistent waren, werden die Inkonsistenzen gleich mit überführt.

Ein semantischer Top-down-Ansatz kehrt die konventionelle Migrationslogik um. Statt jedes Objekt von A nach B zu ­verschieben, stellt er die Frage voran: Was bedeuten diese Daten, und wer braucht sie? Der zentrale Treiber dieses Ansatzes ist Relevanz und Vertrauen – und beides entsteht nicht durch Verschiebung, sondern durch Verständnis.

Die Zielarchitektur wird nicht aus der Legacy-Struktur abgeleitet, sondern aus dem geschäftlichen Mehrwert heraus entworfen. Konkret heißt das: Statt 4000 technische Objekte einzeln zu analysieren, beginnt die Migration mit der Frage: Welche 20 KPIs steuern unser Geschäft, und was brauchen sie?

Migrationsvehikel Datenprodukte

In der Praxis mündet dieser Ansatz in geprüften Datenprodukten. Ein Datenprodukt führt Daten auf ihren geschäftlichen Zweck zurück, erfasst die zugrunde liegende Logik und macht Qualität, Herkunft und Zuständigkeit transparent – das schafft Vertrauen.

Der daraus entstehende Kosteneffekt ist erheblich: Statt sämtliche Objekte einer gewachsenen Legacy-Umgebung in die Cloud zu überführen, wird nur das migriert, was dem Unternehmen tatsächlich auch dient – Obsoletes wird stillgelegt, Redundantes wird konsolidiert. SAP selbst baut entsprechende Konzepte in die Business Data Cloud (SAP BDC) ein. Der semantische Ansatz setzt jedoch noch einen Schritt früher an: Datenprodukte entstehen aus Metadaten, bevor die Rohdaten bewegt werden.

Wie das in der Praxis aussieht

Konkret gliedert sich das Vorgehen in drei Schritte. Zunächst wird die Legacy-Umgebung semantisch erfasst: Eine Plattform liest sämtliche Metadaten aus dem SAP BW-System aus – Systemobjekte, Abap-Quellcode, Transformationslogik, vorhandene Dokumentation. Daraus entsteht eine vernetzte Wissensschicht. Sie macht sichtbar, welche Objekte existieren, wie sie zusammenhängen und welchem Zweck sie dienen.

Im zweiten Schritt definieren Daten­architekten und Fachbereiche gemeinsam die Ziel-Datenprodukte. Sie starten nicht auf einem leeren Blatt, sondern auf Basis dieser Wissensschicht. Wo lässt sich konsolidieren? Welche Logik muss erhalten bleiben, was kann entfallen? Jedes Datenprodukt erhält eine klare Verantwortlichkeit, definierte Qualitätsstandards und dokumentierten Kontext.

Im dritten Schritt wird die erfasste ­Logik automatisiert in ausführbaren Code für die Zielplattform überführt. Da die ­Intention bereits verstanden ist, entsteht optimierter Code statt einer syntaktischen Eins-zu-eins-Übertragung.

Ein Beispiel: Ein Fertigungsunternehmen identifizierte bei der semantischen Erfassung, dass von 3200 BW-Objekten nur rund 40 Prozent aktiv genutzt wurden. Die restlichen 60 Prozent, wie historische Testläufe, temporäre Workarounds oder verwaiste Berichte, konnten stillgelegt werden, bevor ein einziges Byte in die Cloud wanderte.

Eine SAP-BW-Cloud-Migration wird häufig als einmaliges Infrastrukturprojekt betrachtet. Wer dabei einen semantischen Ansatz wählt, gewinnt jedoch mehr als eine neue Plattform: Die entstehenden Assets haben über die Migration hinaus ­Bestand. Das semantische Modell wird zur lebendigen Dokumentation der Datenlandschaft. Die Datenprodukte – mit ihren eingebetteten Qualitätsregeln, ihrer Datenherkunft und ihren fachlichen Defini­tionen – werden zu wiederverwendbaren Bausteinen, die jedes Team auffinden, nachvollziehen und in neuen Kontexten einsetzen kann. Das ist besonders relevant für Organisationen, die auf KI setzen, denn Modelle und Agenten sind nur so zuverlässig wie die ­Daten, die sie konsumieren.

Verlässliches Fundament schaffen

Die eigentliche Migration führt nicht von einem System zu einem anderen. Sie überführt fragmentierte, undokumentierte Daten in eine Governance-fähige, nachvollziehbare und vertrauenswürdige Datenbasis. Wer die Bedeutung zuerst migriert, schafft nicht nur eine Cloud-Landschaft, sondern ein Datenfundament, auf das sich das Unternehmen verlässlich stützen kann. Für korrekte KPIs, für zuverlässige Berichte und für fundierte Entscheidungen.

Zum Partnereintrag: