SAP BW-Migration

01 Der konservative Weg: SAP BW/4HANA On Premise

Geeignet, wenn…

• ein bewährter, kontrollierter Architekturansatz bevorzugt wird
• bestehende SAP-BW-Kompetenzen erhalten bleiben sollen
• Cloud-Ziele mittel- bis langfristig angestrebt werden

Als logische Weiterentwicklung des klassischen SAP BW wurde SAP BW/4HANA im Jahr 2016 eingeführt – mit klarer strategischer Anbindung an die SAP-HANA-Plattform. Im Mittelpunkt stehen eine gestraffte Architektur, moderne Modellierungsansätze (z. B. feldbasiertes Design), eine neue Entwicklungsumgebung (Eclipse-basierte ABAP Development Tools) sowie die Abkehr von veralteten BW-Komponenten. Die Plattform ermöglicht eine performantere Verarbeitung und klarere Modellstrukturen – bei gleichzeitigem Erhalt zentraler BW-Prinzipien wie Metadatensteuerung und eingebetteter Governance. Als On-Premise-Lösung eignet sie sich vor allem für Unternehmen, die Datenhoheit wahren, bestehende BW-Investitionen sichern und den vollständigen Umstieg auf cloud-native Architekturen noch nicht vollziehen möchten.

Allerdings hat SAP in den letzten Jahren den Innovationsfokus deutlich auf Public-Cloud-Produkte (z. B. SAP Datasphere) verlagert. SAP BW/4HANA gilt als stabile, aber funktional weitgehend ausentwickelte Plattform. Das offizielle Wartungsende liegt aktuell bei 2040 – jedoch mit dem Vorbehalt, dass neue Features nur noch in geringem Umfang zu erwarten sind.

Viele produktive BW-Systeme sind über Jahre gewachsen – oft mit komplexen, schlecht dokumentierten Datenflüssen, veralteten Objekten (z. B. BW 3.5-Komponenten) und umfangreichem Custom Code. Häufig ist die Vorbereitung der Migration aufwendiger als die Migration selbst.

Empfohlene Vorarbeiten im Überblick

• Bereinigung veralteter Objekte (z. B. InfoCubes, PSA, BEx Reporting Objekte)
• Ausmisten redundanter Datenflüsse, Queries und Transformationen
• Reduktion nicht genutzter Custom-ABAP-Komponenten
• Analyse technischer Tabellen (z. B. Logs aus Prozessketten, Statistikdaten)
• Konsolidierung und Dokumentation relevanter Objekte

Housekeeping in der Praxis – Beispiele

Technisches Housekeeping

• Aggregate Cleanup: Werden InfoCube-Aggregate noch verwendet, sollte geprüft werden, ob veraltete gelöscht werden können. Läuft das BW bereits auf HANA, sind Aggregate obsolet und können über den Report RS_DELETE_TLOGO entfernt werden.
• PSA Cleanup: Die Persistant Staging Area (PSA) dient als physischer Zwischenspeicher strukturierter Requests. Nach Weiterverarbeitung sollten PSAs bereinigt werden. In BW/4 wurde die PSA dekommissioniert – Staging-aDSOs übernehmen diese Funktion.
• Administration Tables Cleanups: Bereinigung von Prozessketten-Logs, Statistik- und Systemtabellen.

Diese Aufgaben gehören zwar auch zum regulären Betriebs-Housekeeping – im Vorfeld einer Migration ist jedoch eine kritische Prüfung und umfangreiche Vorarbeit besonders empfehlenswert, um Altlasten und überflüssige Datenbestände zu vermeiden.

Tipp: Die SAP Note 2388483 „Data Management for Technical Tables“ bietet umfassende Hinweise zum technischen Housekeeping – vor und nach einer Migration.

Application Housekeeping

• Evaluierung von Custom Code und bestehenden Datenflüssen: In historisch gewachsenen Systemen finden sich oft verwaiste oder veraltete Applikationen und Datenflüsse – ohne dokumentierten Nutzen, ohne verantwortliche Personen. Eine vollständige Übersicht aller Datenflüsse und Applikationen ist notwendig, um deren Relevanz für eine künftige Architektur einzuschätzen.
• Bereinigung von 3.x Objekten: Viele Unternehmen verwenden noch 3.x-Komponenten, die in BW/4HANA nicht unterstützt werden. Diese müssen durch 7.x- oder HANA-optimierte Objekte ersetzt werden. Hilfreich: RS_DELETE_TLOGO zur Löschung veralteter Transferstrukturen, DataSources und InfoPackages.
• Abbau nicht mehr verwendeter BEx Objekten: Alte BEx Queries, Workbooks oder Variablen sollten gezielt identifiziert und entfernt werden.

Beim Greenfield-Ansatz sollte mit dem SAP Quick Sizer geplant werden, um Datenbank- und Applikationsgröße korrekt abschätzen zu können. Für Brownfield-Migrationen empfiehlt sich die Verwendung des BW/4HANA Sizing Reports.

Vorteile

• Höhere Genauigkeit: Berücksichtigt nicht nur aktuelle Daten, sondern analysiert detailliert die Speicheranforderungen für BW/4HANA.
• Multi-Temperature-Storage: Unterscheidet zwischen heißem, warmem und kaltem Speicher für optimale Performance und Kostenkontrolle.
• Future Growth: Integriert zukünftiges Datenwachstum in die Sizing-Berechnung, um langfristige Skalierbarkeit sicherzustellen.
• Optimierung für BW/4HANA: Ermittelt die benötigten HANA-Ressourcen speziell für die Zielarchitektur und reduziert unnötigen Speicherbedarf.
• Sicherung bestehender Investitionen
• Hohe Kontrolle über Datenhaltung & Sicherheit
• Vertraute Governance-Strukturen
• Option auf spätere Anbindung an SAP Business Data Cloud

Risiken

• Aufwendige Vorbereitung durch Altsysteme
• SAP-Innovationsfokus liegt auf Cloud
• Begrenzte Offenheit für Non-SAP-Datenquellen
• BW bleibt IT-zentriert – ein echter Self-Service ist nicht möglich
• Unsichere Perspektive nach 2040

Tipp: Die SAP Note 2296290 „SAP HANA: Sizing Report for BW on HANA and BW/4HANA“ und dessen verwandte Notes bieten einen hervorragenden Guide zur Arbeit mit dem Sizing Report.

Erfahrungswert: Das jährliche Datenwachstum liegt meist zwischen 10 % und 30 % – ein entscheiden der Faktor für künftige Hardware-Anforderungen.

Die Migrationsstrategie hin zu BW/4HANA bietet Stabilität und Investitionsschutz. Sie eignet sich gut als Übergangsarchitektur – mit der Option auf spätere Cloud-Anbindung via PCE und BDC.

02 Der Cloud-native Ansatz: SAP Datasphere

Geeignet, wenn…

• Cloud, Offenheit & Self-Service angestrebt werden
• Fachbereiche stärker eingebunden werden sollen
• BW-Strukturen als zu träge empfunden werden
• ein hybrider Parallelbetrieb möglich ist

SAP Datasphere ist die strategische Plattform von SAP für Data Warehousing, Modellierung und Integration in der Public Cloud. Ursprünglich 2019 als SAP Data Warehouse Cloud gestartet, wurde sie 2023 in SAP Datasphere umbenannt und ist heute ein zentraler Bestandteil der SAP Business Data Cloud (BDC). Das Grundprinzip: Unternehmen sollen über eine offene, flexible Cloud-Plattform ihre Daten aus unterschiedlichsten Quellen integrieren, modellieren und für Analytics-Use-Cases bereitstellen können, ohne klassische ETL-Strecken, stattdessen mit Fokus auf Datenvirtualisierung, Self-Service und moderne Data Mesh-Konzepte. Technologisch basiert Datasphere auf SAP HANA Cloud und bietet u. a.:

• Business Data Fabric-Architektur zur Integration verteilter Datenquellen
• Space-Konzept für entkoppelte Entwicklungsräume und Berechtigungsstrukturen
• Virtuelle Datenzugriffe statt redundanter Speicherung
• APIs und Konnektoren für SAP- und Non-SAP-Systeme
• Data Marketplace und Katalog für Datenprodukte und semantische Transparenz
• Semantisches Onboarding für die Übernahme von Business-Logik aus S/4HANA

Mit SAP Datasphere verfolgt SAP das Ziel, IT und Fachbereiche gleichermaßen in die Lage zu versetzen, Daten effizient zu nutzen – mit abgestufter Komplexität (von No-Code bis Pro-Code), zentralem Governance-Anspruch und wachsender Offenheit für externe Plattformen und Ökosysteme.

Der Wechsel von SAP BW zu SAP Datasphere ist keine 1:1-Migration, sondern ein konzeptioneller und technologischer Umbruch. Viele der BW-typischen Elemente – InfoProvider, Transformationen, BEx Queries – existieren in SAP Datasphere nicht mehr. Neue Denkweisen und Fähigkeiten sind gefragt:

• Klassische BW-Objekte und Prozessketten entfallen vollständig
• Die Modellierung erfolgt SQL- und Script-basiert über Views und Business Layer
• Statt ABAP-basiertem ETL liegt der Fokus auf ELT und Datenvirtualisierung
• Data-Mesh-Konzepte erfordern organisatorischen Wandel und klare Verantwortlichkeiten
• Neue Governance-Regeln sind notwendig – etwa zu Zugriffsrechten, Datenschutz, Datenqualität
• Integration mit dem Data Marketplace, Open SQL-Schnittstellen und Non-SAP-Datenquellen erfordern neue Ansätze in der Datenarchitektur

Beim Umstieg auf SAP Datasphere oder bei hybrider Nutzung bringen vor allem große Legacy-BW-Sys-

teme zahlreiche technische Altlasten mit, die eine Migration erschweren oder zumindest vorbereitende

Maßnahmen erforderlich machen:

• Komplexe Logik in ABAP und OLAP-Queries
• BW-Add-ons wie BPC, die in SAP Datasphere nicht mehr direkt unterstützt werden
• Open Hub Strukturen, spezielle Routinen, hybride BW-HANA-Modelle

Diese Aspekte müssen im Vorfeld identifiziert und bewertet werden, um Fehlinvestitionen oder unvollständige Migrationen zu vermeiden.

Vorteile

• Cloud-native Skalierung und moderne Architektur
• Fachbereichsorientierter Self-Service
• Offene Schnittstellen und einfache Integration
• Zukunftssicherheit durch Einbettung in die SAP Business Data Cloud

Risiken

• Kein direkter Technologietransfer – vollständiger Neuaufbau erforderlich
• Deutlicher Schulungs- und Change-Bedarf
• Funktionale Lücken gegenüber klassischem BW (z.B. Debugging, Modellierung, technische Justierung)
• Eine tragfähige Migrationsstrategie ist zwingend erforderlich

SAP Datasphere ist kein Nachfolger im klassischen Sinne – sondern ein Neuanfang mit moderner Architektur. Wer bereit ist für Cloud, Dezentralisierung und neue Rollenverteilung, erhält maximale Flexibilität und Skalierbarkeit.

03 Die integrierte Plattformstrategie: SAP Business Data Cloud (BDC)

Geeignet, wenn…

• bestehende BW-Systeme erhalten, aber modern eingebunden werden sollen
• ein evolutionärer Migrationspfad in Richtung Cloud gesucht wird
• die BDC als zukünftiges Plattformziel im SAP-Kosmos identifiziert wurde

Die SAP Business Data Cloud (BDC) ist SAPs strategische Antwort auf den steigenden Bedarf nach durchgängiger Datenintegration, -bereitstellung und -verwertung – über Systemgrenzen hinweg. Im Februar 2025 offiziell angekündigt, ist sie mehr als nur ein weiteres Tool: Die BDC wird zum zentralen Orchestrator für Datenarchitekturen innerhalb des SAP-Ökosystems.

Die BDC verbindet SAP Datasphere mit Komponenten wie SAP Analytics Cloud, SAP Databricks-Konnektivität, dem Data Marketplace sowie integrierten Sicherheits- und Governance-Funktionen – unter einer gemeinsamen Plattformstrategie.

Für BW-Kunden öffnet die BDC erstmals echte Brücken: SAP BW/4HANA PCE oder SAP BW 7.5 PCE können angebunden werden, bestehende BW-Modelle lassen sich als Data Products integrieren und durch sogenanntes Semantic Onboarding werden Metadaten, Logiken und Strukturen aus BW überführt. In diesem Zusammenspiel übernimmt die BDC eine zentrale Rolle innerhalb der SAP-Datenstrategie. Sie dient gleichzeitig als:

• Modernisierungsplattform für bestehende BW-Landschaften
• Integrationsschicht für SAP- und Non-SAP-Datenquellen
• Zukunftsanker im SAP Data & Analytics-Portfolio

Voraussetzung für die Integration bestehender BW-Systeme in die BDC ist der Betrieb in der Private Cloud Edition (PCE) – sowohl für SAP BW 7.5 als auch für SAP BW/4HANA. Nur in dieser Betriebsform ist ein direkter Zugriff auf Daten und Modelle innerhalb der BDC möglich.

Gerade SAP BW 7.5-Systeme mit hohem Legacy-Anteil (z. B. 3.x-Objekte, klassische DSOs, InfoCubes) müssen bereinigt, konsolidiert und aktualisiert werden – analog zu den Vorbereitungen für eine Migration auf BW/4HANA.

Integration via Data Products

• BW-Daten werden über das Data Provisioning Tool als Data Products im Foundation Layer der BDC bereitgestellt
• Diese können in SAP Datasphere genutzt, mit Non-SAP-Daten kombiniert oder in z. B. Databricks verarbeitet werden
• Bestehende Queries und Use Cases bleiben größtenteils erhalten

Ziel ist es, bestehende BW-Daten und Strukturen schnell verfügbar zu machen – für eine unmittelbare Nutzung in der BDC und deren angebundenen Services, ohne die ursprünglichen Modelle vollständig neu modellieren zu müssen.

Integration via Semantic Onboarding

• Übernahme analytischer Modelle, inkl. semantischer Strukturen, Kennzahlenlogiken etc.
• Realisiert über die SAP BW Bridge (für BW 7.5) oder den Model Transfer Wizard (für SAP BW/4HANA)

Ziel ist es, analytische BW-Modelle nicht nur technisch zu übernehmen, sondern tief in die BDC-Plattform zu integrieren – inklusive ihrer semantischen Logiken, Strukturen und Kennzahlen. So lassen sie sich innerhalb der modernen BDC-Umgebung komfortabel weiterverwenden, weiterentwickeln und mit neuen Szenarien verknüpfen.

Vorteile

• Verlängerte Nutzbarkeit vorhandener BW-Systeme
• Integration in moderne SAP-Datenarchitektur
• Nutzung moderner Services wie Databricks oder SAP Analytics Cloud
• Schrittweise Migration statt Big Bang

Risiken

• Lift & Shift in die PCE ist aufwendig und kann Lizenz-/Betriebsfragen aufwerfen
• Der Parallelbetrieb erzeugt Integrationsaufwand und Komplexität
• Strategische Entscheidungen dürfen nicht aufgeschoben werden – PCE ist Brücke, kein Ziel auf ewig

Die BDC bietet einen praktikablen und zukunftsfähigen Hybridpfad: Bestehende BW-Systeme bleiben nutzbar, während gleichzeitig moderne SAP-Tools integriert werden. So entsteht eine evolutionäre Transformationsstrategie, die heutige Systeme absichert und den Übergang zur Cloud vorbereitet.

04 Der radikale Neustart: Non-SAP-Stack & Open Lakehouse

Geeignet, wenn…

• SAP BW nicht mehr als strategische Plattform betrachtet wird
• die technologische Unabhängigkeit und Zukunftsfähigkeit im Fokus stehen
• ein echter Neuanfang gewünscht ist – etwa bei M&A, Reorganisation oder Plattformwechsel

Für manche Unternehmen reicht ein technischer Zwischenschritt nicht aus. Sie wollen nicht nur ihr SAP BW ablösen, sondern die Grundarchitektur ihrer Datenplattform radikal neu denken – mit maximaler Offenheit, flexibler Skalierbarkeit und konsequenter Cloud-Nativität.Der Weg führt dabei weg von monolithischen, proprietären Systemen hin zu modularen, offenen Datenplattformen wie etwa einem Open Lakehouse, das auf Komponenten wie Databricks, Snowflake, Google BigQuery, Azure Synapse, Dremio oder auch Delta Lake aufbaut.

Es geht nicht um die Nachbildung klassischer BW-Modelle, sondern um die Etablierung neuer Standards für Datenarchitektur, Governance, Analytics und Self-Service – mit dem Ziel, unabhängig und innovationsfähig zu bleiben.

Denkbares Szenario: SAP bleibt weiterhin operatives ERP- oder Planungssystem – Data & Analytics wandern jedoch auf eine non-SAP-zentrierte Plattform, ergänzt um moderne BI- und Analysewerkzeuge wie Power BI, Tableau, Looker oder Grafana.

Ein solcher Wechsel ist kein technischer „Plug & Play“ – sondern eine vollständige Neuaufstellung. Neben dem Auseinandersetzen mit neuen Technologien und Logiken fordert die Einführung eines Non-SAP-Stacks vor allem auch neue Rollen, Prozesse und Verantwortlichkeiten.

• Migration historischer Daten aus SAP BW – oft komplex, v.a. bei alten Strukturen
• Neuaufbau analytischer Logiken, da viele BW-Funktionalitäten wie OLAP-Hierarchien nicht übertragbar sind
• Schnittstellen zu SAP-Quellsystemen, etwa via SAP ODP, CDS Views, SAP Data Services oder Dritttools
• Know-how-Transfer: BW-Know-how (ABAP, Queries) muss durch Cloud-/Open-Stack-Kompetenz ersetzt werden
• Neukonzeption von Governance- & Security: rollenbasierte Zugriffe, Data Sharing, Lineage, Auditing
• Etablierung von Rollen wie Data Owner, Product Owner Data, Analytics Engineers
• Aufbau von Data Domains, Data Catalogs, Self-Service-Strecken
• Enge Zusammenarbeit zwischen IT, Data & Analytics Teams und Fachbereichen

Vorteile

• Aufbau einer Best-of-Breed-Architektur
• Unabhängigkeit von SAP-Innovationszyklen und Lizenzmodellen
• Cloud-native Skalierung, einfache Integration von AI/ML-Services
• Pay-per-Use-Modelle und flexible Betriebskosten

Risiken

• Migrationsaufwand ist erheblich – historisch gewachsene BW-Systeme sind komplex
• BW-Funktionalitäten (z. B. OLAP-Funktion, Metadatensteuerung) gehen verloren
• Know-how-Gap in IT und Fachbereichen – Schulungsbedarf ist hoch
• SAP-Integration bleibt komplex – z. B. für S/4HANA oder Embedded Planning
• Neue Vendor Lock-ins sind möglich, trotz vermeintlicher Offenheit

Die Migration von SAP BW zu einer zukunftsfähigen Datenarchitektur ist kein rein technisches Projekt – sie ist eine strategische Weichenstellung mit langfristiger Wirkung. Die vier hier beleuchteten Optionen bieten unterschiedliche Wege, um Datenkompetenz, Governance und Innovationsfähigkeit neu aufzustellen.

1. Der konservative Weg mit BW/4HANA On Premise bietet Stabilität, Kontrolle und Investitionsschutz – besonders für Unternehmen mit großer BW-Historie und mittelfristigem Cloud-Zielbild.
2. Der Cloud native-Ansatz mit SAP Datasphere steht für Offenheit, Cloud-Nativität und Self-Service – ideal für Organisationen mit Modernisierungswillen und transformativem Mindset.
3. Die integrierte Plattformstrategie mit SAP Business Data Cloud erlaubt eine evolutionäre Weiterentwicklung bestehender BW-Systeme – und verbindet Vertrautes mit modernen Cloud-Technologien.
4. Der radikale Neustart mit Non-SAP-Stacks ermöglicht maximale Freiheit – setzt aber strategischen Mut, Ressourcen und tiefgreifende Veränderungsbereitschaft voraus.

Welcher Weg der richtige ist, hängt maßgeblich von der aktuellen Architektur, dem Reifegrad der Organisation und den Zielen für Data & Analytics ab.

Setzen Sie sich strukturiert mit Ihrer Zielarchitektur auseinander:

• Beginnen Sie mit einer fundierten Bestandsaufnahme.
• Bewerten Sie technologische, organisatorische und kulturelle Voraussetzungen.
• Setzen Sie sich damit auseinander, welchen Nutzen Sie erreichen wollen.
• Und wählen Sie dann Ihren Migrationspfad bewusst.

QUNIS unterstützt Sie gerne – von der Strategieentwicklung über Technologieauswahl bis zur Umsetzung. Starten Sie mit uns mit einer Strategieanalyse oder einem Data & Analytics Architektur-Check.

Kontaktieren Sie uns für eine individuelle Beratung und weiterführende Informationen.
Schreiben Sie uns an: team@qunis.de