Concept card

SAP BW End of Support — What Is Actually Ending, and the Four Migration Paths

As of 2026-08-02T21:40:00Z

What is SAP BW End of Support — What Is Actually Ending, and the Four Migration Paths?

Search "SAP BW end of life 2027" and you will find a dozen confident dates.

Search "SAP BW end of life 2027" and you will find a dozen confident dates. Be careful with all of them, including the one in the query: your end-of-maintenance date depends on which BW product you run, which release, and what your contract says — and the only authoritative answer is SAP's own maintenance schedule for your specific product version. This page will not invent a date for you. It will tell you what is actually happening and what the decision is.

What is actually happening

SAP has set a maintenance horizon on classic BW and on BW/4HANA, and has made Business Data Cloud the target platform for enterprise analytics. That combination — a closing window on the old platform plus a named destination — is what has triggered the largest migration cycle in the SAP analytics ecosystem since the move from BW on any database to BW on HANA.

The scale is why it matters commercially as well as technically: roughly four thousand BW customers in the main European market plus around seventeen thousand ECC customers sit inside the addressable population, and the resulting consulting demand is measured in billions through 2028.

You are in one of four cohorts, and they do not share a deadline

Customers still on classic BW under extended maintenance face the hardest date and have to decide first.

Customers running ECC alongside BW get pulled into the conversation as part of a broader S/4HANA transformation — their BW decision is a dependent clause in a bigger programme, not a standalone project.

Customers already on BW/4HANA are weighing whether to move again so soon, which is a genuinely different conversation: they modernised recently and the payback argument has to clear a higher bar.

Customers who bypassed SAP's warehouse entirely — Snowflake, Databricks — are being courted back through BDC's SAP-native semantic layer, and for them this is an evaluation, not a deadline.

Each cohort has a different trigger, timeline and risk appetite. A consultant who opens with a generic "BW is ending" pitch is speaking to the wrong cohort three times out of four.

The four paths, and how to argue them

"Migrate to BDC" is not a single motion. The practical decision is which of four paths to recommend, argued on trade-offs rather than defaulted to whichever the consultant knows best.

Lift-and-shift preserves the existing BW model and rehosts it. Right when the model is in reasonable shape and the driver is infrastructure or licensing pressure rather than modernisation. The trade-off is explicit: it buys time without buying capability — you inherit BDC's cost and operating model while keeping every modelling debt the BW model accumulated. Frame it as a transitional step, never as an end state.

Selective migration moves what earns its keep and retires the rest. Usually the honest answer, and usually the one that needs the most political cover, because "retire" means somebody's report disappears.

Rebuild treats the migration as the moment to redo the semantic layer properly in Datasphere. Highest cost, highest ceiling, and only defensible when the existing model is genuinely the problem.

Stay and federate keeps BW where it is and exposes it through BDC Connect. Legitimate for customers whose BW estate works and whose real need is reach, not replacement.

The BW Data Product Generator is worth knowing here: it turns existing BW objects into BDC-consumable Data Products, which changes the arithmetic of the first two paths considerably.

Pitfalls

Quoting a date you did not verify against SAP's maintenance schedule for the customer's exact product version. It is the fastest way to lose a room, and the correction always arrives from the client's basis team.

Selling the wave rather than the cohort. Four cohorts, four triggers; the generic urgency pitch lands on the wrong one most of the time.

Framing lift-and-shift as done. It is a transitional step with a debt attached, and a customer who was told otherwise discovers the debt at the first BDC invoice.

Treating "retire that report" as a technical decision. It is a political one, and it is the actual long pole in selective migration.

Why it matters

This is the migration wave that redraws which firms hold which accounts for the next decade — and the single fastest way to lose the room is to quote a date you did not verify for that customer's exact release.

Key points

🔴 There is no single BW end-of-life date: it depends on the product, the release and the contract. Verify against SAP's maintenance schedule for that customer's version.
What IS true: SAP set a maintenance horizon on classic BW and BW/4HANA, and named Business Data Cloud as the analytics target.
That combination triggered the largest SAP analytics migration cycle since BW-on-any-database moved to BW-on-HANA.
Scale: ~4,000 BW customers in the main European market plus ~17,000 ECC customers, with consulting demand measured in billions through 2028.
Four cohorts, four different deadlines: extended-maintenance classic BW, ECC-alongside-BW, already-on-BW/4HANA, and those who left for Snowflake/Databricks.
A generic "BW is ending" pitch addresses the wrong cohort three times out of four.
Path 1 — lift-and-shift: buys time, not capability. Inherits BDC's cost model AND every existing modelling debt. Transitional step, never an end state.
Path 2 — selective migration: usually the honest answer, and the one needing the most political cover, because "retire" means someone's report disappears.
Path 3 — rebuild in Datasphere: highest cost and ceiling; defensible only when the existing model is genuinely the problem.
Path 4 — stay and federate through BDC Connect: legitimate when the BW estate works and the real need is reach, not replacement.

Common pitfalls

Quoting an unverified end-of-life date — Signal: A slide says 2027 with no product version beside it. Fix: Check SAP's maintenance schedule for that exact release; let the client's basis team confirm it before you present.
Selling the wave, not the cohort — Signal: The same urgency deck for every client. Fix: Identify the cohort first — the trigger, timeline and risk appetite all change.
Lift-and-shift framed as done — Signal: No debt register in the migration plan. Fix: State it as transitional and name what debt was carried across.
Report retirement treated as technical — Signal: The plan retires 400 reports with no sponsor named. Fix: Get a business owner for retirement decisions — it is the long pole.
Ignoring the federate option — Signal: Every proposal is a migration. Fix: For a working BW estate that needs reach, BDC Connect is cheaper and lower risk.

Decision framework

Decision	Option A	Choose A when	Option B	Choose B when
Which cohort is the client in	Classic BW on extended maintenance	Deadline-driven. Lead with the date THEY verified, and the four paths.	Already BW/4HANA or gone to an open stack	Value-driven. The urgency pitch is wrong; argue capability and reach.
State of the existing BW model	Reasonable	Lift-and-shift or selective — do not sell a rebuild the model does not need.	The model IS the problem	Rebuild in Datasphere; anything else re-hosts the defect.
Driver	Infrastructure / licensing pressure	Lift-and-shift, explicitly framed as transitional.	Modernisation and AI grounding	Selective or rebuild — lift-and-shift buys none of that.
Is replacement even required	Yes	One of the three migration paths.	No — the estate works, reach is the gap	Stay and federate through BDC Connect. A legitimate, under-sold answer.
Who owns report retirement	A named business sponsor	Selective migration is viable.	Nobody	Selective migration will stall. Fix sponsorship before scoping.

Sources

Open in the app →