Concept card

BW Bridge: The Migration Arbitration

As of 2026-10-06

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is BW Bridge?

BW Bridge is SAP's bridging path that lets existing BW/4HANA on-prem investment co-exist with Datasphere — running BW/4HANA-style objects (advanced DataStore Objects, CompositeProviders, transformations, process chains — not InfoCubes, not BEx queries) inside the Datasphere tenant. It's the migration accelerator that buys customers 2-4 years to move from BW to Datasphere-native modeling without a rip-and-replace. The wave-level view of the same migration — who moves…

What is BW bridge in SAP Datasphere?

BW Bridge is a BW/4HANA-based runtime embedded in an SAP Datasphere tenant. It lets existing BW objects, extractors and ABAP transformations keep running inside Datasphere, exposed as remote tables to Datasphere views, so a BW landscape can move to Datasphere without rebuilding everything first. It is a transition tool: what it carries should be given a sunset date, not treated as the permanent target.

The architectural reality. BW Bridge runs a BW/4HANA system inside Datasphere with shared storage. Existing BW objects continue working; new modeling happens Datasphere-native (Spaces · Analytic Models · Data Builder per M001-M006). The two co-exist; over time, BW objects migrate or retire as the customer chooses.

When BW Bridge wins. Large BW estate (1,000+ queries, 100+ InfoProviders) where rip-and-replace would consume 18-24 months and break daily reporting. The bridge buys time: 2-4 years to migrate object-by-object while staying live.

When BW Bridge loses. Small BW estate (< 50 objects) — direct migration to Datasphere is faster + cheaper. Greenfield customer — no need to bridge what doesn't exist.

Senior craft signal — migration cadence. A junior provisions BW Bridge and lets it sit. A senior runs a quarterly migration sprint: 5-10 BW objects → Datasphere-native each quarter, sequenced by business value + complexity. By year 3, BW Bridge is < 30 % of analytics surface; by year 5, it can retire.

Cost discipline. BW Bridge consumes Datasphere capacity units PLUS the embedded BW/4 license footprint. Customers pay both during the bridge period. Documenting a sunset date in the ADR is the difference between a 2-year bridge and a 7-year permanent fixture.

Migration path decision: BW Bridge vs. greenfield Datasphere vs. stay on-prem BW/4HANA. The three-way decision is the core consulting conversation at every BW customer account. Stay on-prem BW/4HANA: valid only if the customer has no cloud mandate and the BW estate is stable and fully depreciated. Staying on-prem is a strategy decision, not an expiry decision: BW/4HANA maintenance runs to at least 2040, aligned with SAP S/4HANA (SAP maintenance announcement, 23 April 2020), so the pressure comes from the direction of travel towards BDC — and, for any classic BW 7.5 still in the estate, from its own clock: mainstream maintenance to 31 December 2027, paid extension to 2030. Greenfield Datasphere without BW Bridge: the right choice when the BW estate is small (fewer than 50 active InfoProviders, fewer than 100 active queries) or when the business is willing to freeze reporting during a migration sprint — typically 6-9 months for a small estate. The advantage is a clean Datasphere architecture from day one with no dual-runtime cost, no legacy object debt, and no bridge sunset risk. BW Bridge: choose it when the estate is large (hundreds of InfoProviders, thousands of queries), the business cannot tolerate a reporting freeze, and there is a funded 3-5 year modernisation programme. The bridge is not a destination — it is a time-boxed coexistence stage. The consultant's job is to make that time box explicit in the ADR at project kickoff.

Versus BW/4HANA Public Cloud Edition (PCE): BW PCE is a managed BW/4HANA instance in SAP's cloud, not Datasphere. It extends the BW runtime longer than on-prem but does not give BDC lakehouse integration or the Datasphere semantic layer. BW Bridge into Datasphere is the forward path that lands on BDC; BW PCE is a hosting lift without a semantic-layer upgrade. Choose PCE when the customer's primary driver is infrastructure modernisation, not analytics modernisation.

The two maintenance dates, and why conflating them loses a deal. They belong to different products and they run on different clocks. Classic SAP BW 7.5 leaves mainstream maintenance on 31 December 2027, with optional paid extended maintenance running to 2030 (SAP maintenance announcement, 23 April 2020). SAP BW/4HANA is an independent decision: its maintenance runs to at least 2040, aligned with SAP S/4HANA (same announcement, 23 April 2020). BW Bridge inherits the clock of the product it runs, and what runs inside Datasphere is BW/4HANA — so the bridge is not the thing that expires. A customer still on BW 7.5 has a dated, contractual deadline; a BW/4HANA customer has a strategic one, and a consultant who sells the second as if it were the first will be corrected in the room.

Where the mechanics live. This card arbitrates: whether to bridge, against which alternative, for how long, and at what standing cost. How the bridge actually runs — what the SAP transfer tooling carries across, which ODP extractors keep feeding it unchanged, why custom ABAP has to be rewritten against the released API set, and how CompositeProviders surface as Datasphere remote tables — is the companion card, SAP BW Bridge: The Runtime Inside Datasphere.

The AI-readiness angle, September 2026

BW Bridge's sunset-date question is no longer only a cost argument — it is also an AI-readiness argument, and naming both together in the ADR conversation is materially more persuasive than cost alone. Everything SAP's Business AI Platform promises for analytics — Joule's natural-language query layer, generative AI hub grounding, the SAP Knowledge Graph reading business entities — runs on governed BDC data products exposed through Datasphere, not on BW objects still running inside the bridge's embedded runtime. An advanced DataStore Object or CompositeProvider that has not yet been re-platformed to a Datasphere-native model or space is, for as long as it stays on the bridge, invisible to that entire AI layer: Joule cannot answer a natural-language question grounded in it, and the Knowledge Graph has nothing published to read.

This reframes the migration cadence this card already recommends. A quarterly sprint of five to ten objects is not only a cost-containment discipline against double CU-plus-license spend — it is also, object by object, the rate at which the customer's data becomes reachable by whatever Joule agent or generative-AI use case the business wants to build next. SAP's own BW Data Product Generator, an add-on that converts BW/4HANA InfoProviders and the BW/4HANA model transfer into governed Datasphere views and Analytic Models, exists precisely to remove the mechanical translation work from that sprint — what remains manual is renaming technical fields to business labels, wiring Data Access Controls, and completing the BDC data contract, the same annotation discipline that also determines whether Joule can ground on the result.

The practical implication for scoping: when a customer asks why the bridge should not simply run indefinitely at low cost, the AI-readiness answer is sharper than the licensing one. A stalled bridge does not just carry a standing bill — it freezes the customer's own data out of every AI capability SAP is shipping into the platform this estate is supposed to be moving toward, while competitors migrating on schedule get there first.

What the contract market asked for, 27 September – 6 October 2026

Six of the ten missions listed were in Germany and named BW/4HANA or BW directly: an in-house BW on HANA consultant post in Heidelberg (60 % remote), a team lead BI/BW, a Data Platform Consultant for BW and data and analytics, a senior BW/4HANA and Business Data Cloud consultant, an ABAP security developer for BW/4HANA, and a BW consultant / solution architect from 1 November 2026 for 12 months, remote or Berlin. The installed BW base is still being staffed, not just maintained.
BW was repeatedly co-requested with the target platform: BW/4HANA with Business Data Cloud (Germany), BW with data and analytics (Germany), a "SAP BW / DataSphere" consultant (Mexico) and a Datasphere architect (United States). The profile in demand is the one that can sit on both sides of the bridge.
Two Belgian postings, a BW/HANA application analyst and a senior business and data analyst for SAP BW, point to run-side demand: keeping existing BW content working while the migration question is still open.
None of the listed titles named BW Bridge. For a practitioner the implication is that the arbitration is argued as "BW plus Datasphere or BDC" skills, so a bridge recommendation has to be backed by both BW/4HANA depth and Datasphere modelling, not by bridge-specific vocabulary.

Why it matters

Large BW estates (1,000+ queries, 100+ InfoProviders) avoid an 18-24 month rip-and-replace that would break daily reporting.
Without a documented sunset date in the ADR, a 2-year bridge silently becomes a 7-year permanent fixture — customers pay both Datasphere capacity units and the BW/4 license footprint throughout.
Under 50 BW objects, direct migration to Datasphere is faster and cheaper — provisioning BW Bridge there is pure overhead.

Key points

Bridges existing BW estate inside Datasphere tenant
Buys 2-4 years for object-by-object migration
Wins for 1,000+ query estates; loses for small estates
Sunset date in ADR, not open-ended
Migration cadence 5-10 objects/quarter
Mixed DAC layers in one story = drift
Two clocks: BW 7.5 mainstream to 2027 (paid extension to 2030), BW/4HANA to at least 2040 (SAP, 23 April 2020)
Custom ABAP migrations 3-5× complexity

Common pitfalls

Provisioning the bridge and letting it sit — Signal: BW Bridge still carries 100% of the analytics surface two years after go-live Fix: Run the quarterly migration sprint (5-10 objects/quarter) from month one; track the percentage still on the bridge, not just its existence.
No sunset date in the ADR — Signal: The bridge decision memo has no target retirement date Fix: Document the sunset date at project kickoff — this is what separates a 2-4 year bridge from a 7-year permanent fixture.
Conflating the BW 7.5 and BW/4HANA maintenance clocks — Signal: A proposal cites 2030 — the BW 7.5 extended-maintenance end — as the deadline for a BW/4HANA customer Fix: Confirm which product is actually running before quoting a date: BW 7.5 = 2027 mainstream / 2030 extended, BW/4HANA = at least 2040.
Selling BW PCE as the BDC-native forward path — Signal: The proposal presents BW PCE as equivalent to BW Bridge into Datasphere Fix: PCE is a hosting lift, not a semantic-layer upgrade — name the difference before the customer signs a PCE contract expecting Datasphere capability.

Decision framework

Decision framework
Decision	Option A	Choose A when	Option B	Choose B when
Migration path for an existing BW estate	BW Bridge (coexist inside Datasphere)	Large estate (1,000+ queries, 100+ InfoProviders); business cannot tolerate a reporting freeze; funded 3-5 year modernisation programme.	Greenfield Datasphere, no bridge	Small estate (fewer than 50 active InfoProviders, fewer than 100 active queries), or the business accepts a 6-9 month reporting freeze.
Bridge vs staying on BW/4HANA on-prem	Stay on-prem BW/4HANA	No cloud mandate; estate stable and fully depreciated; maintenance runs to at least 2040.	Bridge into Datasphere	Cloud/BDC direction is already set; the customer wants object-by-object migration without freezing reporting.
BW Bridge vs BW/4HANA Public Cloud Edition (PCE)	BW Bridge into Datasphere	The driver is analytics modernisation — lands on BDC with the Datasphere semantic layer.	BW PCE	The driver is infrastructure modernisation only — a managed hosting lift, no semantic-layer upgrade.

Facts worth quoting

BW 7.5 leaves mainstream maintenance 31 December 2027, with paid extended maintenance to 2030; BW/4HANA maintenance runs to at least 2040, aligned with SAP S/4HANA (SAP maintenance announcement, 23 April 2020) — two different clocks that BW Bridge inherits from whichever product it wraps.
A well-run BW Bridge programme reduces its own footprint to under 30% of the analytics surface by year 3 of a quarterly 5-10-object migration cadence (this platform's field benchmark, not an SAP-published figure).
BW Bridge consumes Datasphere capacity units on top of the embedded BW/4HANA license footprint for the duration of the bridge — a standing double cost that a documented sunset date is what bounds (SAP Datasphere product documentation, help.sap.com/docs/SAP_DATASPHERE).

Sources

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.