Konzeptkarte

SAP BW End of Support — Was tatsächlich endet, und die vier Migrationspfade

Stand 2026-08-02T21:40:00Z

Redaktion: Cédric-Olivier Mâry, alleiniger Redakteur und verantwortlich für die Veröffentlichung — 27 Jahre im SAP-Ökosystem. Wie diese Seiten entstehen und wo Automatisierung eingesetzt wird.

Was ist SAP BW End of Support — Was tatsächlich endet, und die vier Migrationspfade?

Das Ende-der-Wartung-Datum hängt von Produkt, Release und Vertrag ab — diese Seite erfindet keines davon. Sie hält fest, was real ist: ein Wartungshorizont mit BDC als benanntem Ziel, vier Kundenkohorten ohne gemeinsame Frist und vier Migrationspfade, die anhand von Trade-offs begründet werden.

Sucht man „SAP BW End of Life 2027", findet man ein Dutzend selbstbewusster Daten. Seien Sie bei allen vorsichtig, auch bei dem in der Suchanfrage: Ihr Wartungsende-Datum hängt davon ab, welches BW-Produkt Sie betreiben, welches Release, und was Ihr Vertrag sagt — und die einzig maßgebliche Antwort ist SAPs eigener Wartungsplan für Ihre spezifische Produktversion. Diese Seite erfindet Ihnen kein Datum. Sie sagt Ihnen, was tatsächlich passiert und worin die Entscheidung besteht.

Was tatsächlich passiert

SAP hat einen Wartungshorizont für klassisches BW und für BW/4HANA gesetzt und Business Data Cloud zur Zielplattform für Enterprise-Analytics gemacht. Diese Kombination — ein sich schließendes Fenster auf der alten Plattform plus ein benanntes Ziel — hat den größten Migrationszyklus im SAP-Analytics-Ökosystem seit dem Wechsel von BW auf beliebiger Datenbank zu BW auf HANA ausgelöst.

Der Umfang ist der Grund, warum es kommerziell wie technisch relevant ist: rund viertausend BW-Kunden im europäischen Hauptmarkt plus rund siebzehntausend ECC-Kunden liegen innerhalb der adressierbaren Population, und die daraus resultierende Beratungsnachfrage wird bis 2028 in Milliarden gemessen.

Sie gehören zu einer von vier Kohorten, und sie teilen keine Frist

Kunden, die noch auf klassischem BW unter erweiterter Wartung sind, stehen vor dem härtesten Datum und müssen zuerst entscheiden.

Kunden, die ECC parallel zu BW betreiben, werden als Teil einer breiteren S/4HANA-Transformation in das Gespräch hineingezogen — ihre BW-Entscheidung ist ein Nebensatz in einem größeren Programm, kein eigenständiges Projekt.

Warum es zählt

Das ist die Migrationswelle, die neu zeichnet, welche Firmen für das nächste Jahrzehnt welche Accounts halten — und der mit Abstand schnellste Weg, einen Raum zu verlieren, ist, ein Datum zu zitieren, das man nicht für das exakte Release dieses Kunden verifiziert hat.

Kernpunkte

🔴 Es gibt kein einzelnes BW-End-of-Life-Datum: Es hängt vom Produkt, dem Release und dem Vertrag ab. Verifizieren Sie es gegen SAPs Wartungsplan für die Version dieses Kunden.
Was WAHR ist: SAP hat einen Wartungshorizont für klassisches BW und BW/4HANA gesetzt und Business Data Cloud als Analytics-Ziel benannt.
Diese Kombination löste den größten SAP-Analytics-Migrationszyklus seit dem Wechsel von BW-auf-beliebiger-Datenbank zu BW-auf-HANA aus.
Umfang: ~4.000 BW-Kunden im europäischen Hauptmarkt plus ~17.000 ECC-Kunden, mit einer Beratungsnachfrage, die bis 2028 in Milliarden gemessen wird.
Vier Kohorten, vier unterschiedliche Fristen: klassisches BW unter erweiterter Wartung, ECC-parallel-zu-BW, bereits-auf-BW/4HANA, und diejenigen, die zu Snowflake/Databricks gewechselt sind.
Ein generischer „BW endet"-Pitch spricht in drei von vier Fällen die falsche Kohorte an.
Pfad 1 — Lift-and-Shift: kauft Zeit, nicht Fähigkeit. Erbt BDCs Kostenmodell UND jede bestehende Modellierungsschuld. Übergangsschritt, nie ein Endzustand.
Pfad 2 — selektive Migration: meist die ehrliche Antwort, und die, die die meiste politische Deckung braucht, weil „stilllegen" bedeutet, dass jemandes Report verschwindet.
Pfad 3 — Rebuild in Datasphere: höchste Kosten und Obergrenze; nur vertretbar, wenn das bestehende Model tatsächlich das Problem ist.
Pfad 4 — Bleiben und föderieren über BDC Connect: legitim, wenn der BW-Bestand funktioniert und das echte Bedürfnis Reichweite ist, nicht Ersatz.

Begriffe auf dieser Seite

Erweiterte Wartung: Die bezahlte, zeitlich begrenzte Support-Phase nach dem Ende der Mainstream-Wartung. Ihr Ablauf ist das harte Datum für die erste Kohorte — und es ist produkt- und vertragsspezifisch.
Lift-and-Shift: Das unveränderte Neuhosten des bestehenden BW-Models auf der neuen Plattform. Kauft Zeit, nicht Fähigkeit; die Modellierungsschuld reist mit.
Selektive Migration: Verschiebt, was sich lohnt, und stilllegt den Rest. Meist der ehrliche Weg; die Stilllegungsentscheidungen sind politisch, nicht technisch.
BW Data Product Generator: Der Mechanismus, der bestehende BW-Objekte in BDC-konsumierbare Data Products verwandelt und die Kostenarithmetik der weniger invasiven Pfade verändert.
BDC Connect: Die Föderationsschicht, die es erlaubt, einen funktionierenden BW- oder externen Bestand von BDC aus zu erreichen, ohne ihn zu ersetzen.
Kohorte: Die Ausgangsposition des Kunden — klassisches BW, ECC+BW, BW/4HANA oder Abwanderung zu einem offenen Stack. Sie bestimmt Auslöser, Zeitachse und Risikobereitschaft.
Migrationswelle: Ein ökosystemweiter Zyklus, der etwa einmal pro Jahrzehnt wiederkehrt und neu zeichnet, welche Firmen für die folgenden zehn Jahre welche Accounts halten.
Modellierungsschuld: Workarounds und Kompromisse, angehäuft über das Leben eines Warehouse-Models. Sie überlebt ein Rehosting und taucht als Kosten auf der neuen Plattform wieder auf.

Quellen

Vollständige Karte für Mitglieder. Was die vollständige Karte ergänzt: den vollständigen Entscheidungsrahmen · den Vergleich SAP · Snowflake · Databricks · Fabric · die häufigen Fallstricke und ihre Behebung · die Kurzreferenz · die Architekturschemata · die Codeblöcke · die zitierfähigen Kennzahlen.

In der App öffnen →