Vom technischen Bestand zum semantischen Zielbild Warum Kontext bei der SAP-BW-Migration wichtiger ist als Code

Anbieter zum Thema

One Data GmbH

easy software AG

Hyland Software Germany GmbH

Flexera Software GmbH

In gewachsenen SAP-BW-Landschaften steckt weit mehr als technischer Code. Sie enthalten über Jahre entstandene Geschäftslogik, Abhängigkeiten und fachliche Regeln. Eine intelligente Migration beginnt deshalb nicht mit der Übertragung einzelner Objekte, sondern mit der Rekonstruktion dieses Wissens.

Eine SAP-BW-Migration ist kein reiner Datentransport. Sie ist eine Neuimplementierung von Geschäftslogik. In ABAP-Routinen, Transformationen und historisch gewachsenen Datenflüssen steckt Wissen darüber, wie Kennzahlen berechnet, Sonderfälle behandelt und Informationen für Berichte aufbereitet werden. Häufig ist dieses Wissen jedoch nur unvollständig dokumentiert. Es steckt in Systemen, deren Entwickler das Unternehmen längst verlassen haben, oder in technischen Konstruktionen, deren ursprünglicher Zweck kaum noch nachvollziehbar ist. Eine Migration muss daher nicht nur technische Objekte übertragen. Sie muss zunächst rekonstruieren, was das bestehende System tut, warum es dies tut und ob es künftig überhaupt noch benötigt wird.

Eine intelligente Migration kehrt deshalb die übliche Reihenfolge um. Nicht die Übertragung einzelner Objekte steht am Anfang, sondern der Aufbau eines semantischen Modells der vorhandenen BW-Landschaft. Erst wenn Bedeutung, Nutzung und Abhängigkeiten sichtbar sind, lässt sich fundiert entscheiden, was tatsächlich migriert werden muss.

Genau hier liegt die Schwäche vieler herkömmlicher Migrationsprogramme. Sie beginnen mit einer technischen Inventur und arbeiten sich anschließend Objekt für Objekt durch das System. Erst im Projektverlauf wird sichtbar, welche Logik geschäftskritisch ist, welche Strukturen redundant sind und welche Komponenten seit Jahren nicht mehr verwendet werden.

Die Folge: Unternehmen migrieren nicht nur relevante Daten und Prozesse, sondern auch einen großen Teil ihrer technischen Altlasten. Sie bezahlen für deren Analyse, Neuentwicklung, Tests und anschließend erneut für den Betrieb in der Cloud. Der eigentliche Engpass ist daher nicht die Programmierung, sondern fehlendes Wissen über Bedeutung, Nutzung und Abhängigkeiten.

Zwei Szenarien für SAP-BW-Bestandskunden

SAP BW modernisieren: Welcher Weg passt?

Ein semantisches Modell statt einer Objektliste

Der erste Schritt besteht darin, die Metadaten der bestehenden Landschaft zu extrahieren und zu standardisieren. Dazu gehören Systemobjekte, Transformationen, Dokumentationen, Formeln, ABAP-Code und strukturelle Informationen. Entscheidend ist, dass Logik und Kontext zusammenbleiben. Eine manuelle Bestandsaufnahme kann zwar Routinen und Objekte erfassen, verliert aber leicht den fachlichen Zusammenhang. Welche Kennzahl beeinflusst eine bestimmte Regel? Welcher Report hängt davon ab? Und welchem Geschäftsprozess dient sie?

Das semantische Modell verbindet diese Informationen. Es macht Abhängigkeiten von der Query-Ebene über CompositeProvider bis zu den zugrunde liegenden DataStore Objects sichtbar, sowohl auf Objekt- als auch auf Feldebene. Dadurch lässt sich nachvollziehen, wo eine Kennzahl entsteht, welche Transformation auf ein Feld wirkt und welche Folgen eine Änderung hätte. Diese Transparenz schafft die Grundlage für die wichtigste Scope-Entscheidung: Was soll erhalten, konsolidiert oder stillgelegt werden?

Vom reduzierten Scope zum Datenprodukt

In nahezu jeder gewachsenen BW-Landschaft befinden sich Objekte, die technisch noch existieren, aber fachlich nicht mehr gebraucht werden. Dazu gehören nicht mehr genutzte Queries, verwaiste DataStore Objects oder längst abgelöste Multi-Provider.

Ohne transparente Lineage und Nutzungsinformationen werden sie häufig vorsorglich mitmigriert. Werden ihre Beziehungen dagegen vorab sichtbar, lässt sich der Scope gezielt reduzieren. Das senkt nicht nur den Migrationsaufwand, sondern auch die späteren Betriebs- und Cloud-Kosten. Erst danach beginnt die Gestaltung der Zielarchitektur. Der zentrale Baustein dafür ist das gesteuerte Datenprodukt. Es handelt sich um ein fachlich ausgerichtetes Asset, das seine eigene Definition, die zugrunde liegende Logik, die vollständige Lineage, klare Verantwortlichkeiten sowie verbindliche Qualitäts- und Governance-Regeln enthält.

Damit wird nicht nur beschrieben, welche Daten bereitgestellt werden. Es ist ebenso festgelegt, wie sie entstehen, wem sie gehören und unter welchen Voraussetzungen sie als verlässlich gelten.

Automatisierung braucht fachlichen Kontext

Erst auf dieser semantischen Grundlage kann Automatisierung ihren vollen Nutzen entfalten. KI-gestützte Verfahren können die rekonstruierte Geschäftslogik in SQL oder native Artefakte der Zielplattform überführen. Der Unterschied zu einer reinen Code-Konvertierung ist entscheidend: Übersetzt wird nicht nur die Syntax einer ABAP-Routine, sondern ihre zuvor erfasste fachliche Bedeutung. So entsteht Code, der zur neuen Architektur passt, statt historische Strukturen lediglich in einer anderen Sprache nachzubauen.

Architekten und Entwickler behalten dennoch die Kontrolle. Generierter Code wird versioniert, geprüft und erst nach Freigabe in der Zielumgebung ausgeführt. Automatisierung reduziert den manuellen Aufwand, ersetzt aber weder fachliche Entscheidungen noch Architekturverantwortung. Auch die Validierung wird vorgezogen. Qualitätsregeln, Schemas, Verantwortlichkeiten und Service-Level werden bereits beim Entwurf der Datenprodukte festgelegt. Nach der technischen Umsetzung wird jedes Ergebnis gegen diese Vereinbarungen geprüft. Erfüllt ein Produkt seinen Datenvertrag nicht, wird es überarbeitet und erneut validiert. Probleme werden damit nicht erst nach dem Go-live entdeckt, sondern bereits während der Modellierung.

„Quantensprung“ für KI-gestützte Unternehmensanalysen

SAP stellt Business Data Cloud vor

Mehr als ein Systemwechsel

Das semantische Modell bleibt auch nach der Migration bestehen. Es wird zur lebenden Dokumentation der Datenlandschaft und zeigt, welche Datenprodukte existieren, wie sie zusammenhängen, wer für sie verantwortlich ist und ob sie weiterhin ihre Qualitätsanforderungen erfüllen. Dadurch entstehen wiederverwendbare Assets. Eine für das Finanzreporting definierte Kennzahl kann auch in der Planung, der Konsolidierung oder einer KI-Anwendung genutzt werden, ohne ihre Logik jedes Mal neu rekonstruieren zu müssen.

Die eigentliche Migration führt deshalb nicht nur von SAP BW zu einer neuen Plattform. Sie führt von fragmentierten und unzureichend dokumentierten Daten zu einer Landschaft, in der Bedeutung, Herkunft, Verantwortung und Qualität nachvollziehbar sind. Eine intelligente SAP-BW-Migration kehrt deshalb die klassische Reihenfolge um: Sie rekonstruiert zuerst Kontext, Bedeutung und Abhängigkeiten, entwickelt daraus ein semantisches Zielbild und überträgt erst dann die tatsächlich benötigten Daten und die zugrunde liegende Geschäftslogik.

(ID:51012423)