Concept card

SAP BW Bridge: The Runtime Inside Datasphere

As of 2026-09-27

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 SAP BW Bridge?

How SAP BW Bridge actually runs inside a Datasphere tenant: what the SAP transfer tooling carries across, how ECC and S/4HANA ODP extractors keep feeding it unchanged, why custom ABAP must be rewritten against the released API set, and how its objects reach the semantic layer as Datasphere remote tables. Whether to bridge at all is arbitrated on a separate card.

BW bridge Datasphere?

Short answer above

What it is

SAP BW Bridge is a BW/4HANA ABAP runtime provisioned inside an SAP Datasphere tenant. It is not a connector and not an emulation: it is BW — InfoObjects, aDSOs, CompositeProviders, transformations, DTPs, process chains and ABAP routines — running as a managed service under the same subscription as the Datasphere spaces that consume it. This card is the mechanism. Whether to bridge at all, against which alternative and for how long, is arbitrated on the companion card, BW Bridge: The Migration Arbitration.

Where the data enters. The bridge keeps the extraction estate the customer already owns. ODP-based DataSources — the SAP Business Content extractors against ECC and S/4HANA, plus CDS-based and BW-based ODP providers — keep feeding it through the same source-system definitions, with SAP Cloud Connector standing between the cloud tenant and the on-premise system. Nothing in the extractor layer is re-authored. That single property carries most of the bridge's value: the extraction estate is the least documented and most expensive part of a BW landscape to rebuild.

Why it matters

Every migrated CompositeProvider becomes a Datasphere Remote Table, consumable by analytic models, Stories, and Delta Sharing without re-modelling.
Existing ECC/S/4 extractors keep feeding data through the same Source Systems and DataSources the customer has run for years — no re-plumbing required.
It's the wrong choice for greenfield programmes or small, well-documented BW content, where a direct Datasphere re-model is faster and cleaner.

Key points

BW/4HANA runtime embedded in Datasphere — InfoProviders, transformations, DTPs, ABAP exits run as a managed service inside the Datasphere subscription.
Lift-and-shift from on-prem BW/4HANA — SAP-provided migration cockpit moves InfoObjects, aDSOs, CompositeProviders, ABAP code as-is.
ECC / S/4 extractors continue to feed — same Source Systems and DataSources the customer has run for years.
Exposed to Datasphere — every CompositeProvider becomes a Remote Table consumable by analytic models, Stories, Delta Sharing.
Not for greenfield — use native Datasphere when no BW legacy exists; BW Bridge is purely a migration scaffold.
The bridge's own sunset should be planned from day one as a multi-year wave sequence, not left open-ended — an undated bridge becomes a second permanent platform running alongside Datasphere.
Passing the ABAP readiness check technically is not the same as a routine being organisationally safe to carry forward — an orphaned-but-technically-fine routine is a bigger silent risk than one the check flags outright.
A CompositeProvider imported as a Datasphere remote table is not yet a BDC data product — the Data Builder modelling step (business-friendly names, associations, data-product declaration) is what actually makes it Knowledge-Graph-ready, and that step costs the same whether the content came through the bridge or a native rebuild.

Terms used on this page

BW Bridge: A BW/4HANA runtime delivered as a managed service inside a SAP Datasphere tenant; lets customers migrate on-prem BW/4HANA content as-is and expose it to the Datasphere semantic layer.
Migration cockpit: The SAP-provided tool that moves on-prem BW/4HANA objects (InfoObjects, aDSOs, transformations, ABAP code) into a BW Bridge tenant with a structured object inventory and a phased migration plan.
CompositeProvider: A BW/4HANA InfoProvider that unions and joins underlying aDSOs and InfoObjects for query consumption; in BW Bridge, every CompositeProvider can be exposed to Datasphere as a Remote Table.
Remote Table: A Datasphere object that points to data held outside Datasphere — in BW Bridge, an HDP or BTP source, or a Delta Sharing surface — without copying the data.
ABAP readiness check: The assessment run against a bridge candidate's custom ABAP to identify routines, BAdI implementations and CMOD enhancements that call unreleased APIs and must be rewritten before migration — a technical check only, not an ownership check.
Capacity unit (BW Bridge): The Datasphere billing unit that also meters the bridge's own runtime footprint — a standing cost for as long as the bridge runs, independent of the Datasphere spaces it feeds.
Data product declaration: The Data Builder step that marks a modelled Datasphere object as a governed data product — the form the SAP Knowledge Graph and Joule's grounding pipeline actually consume; a remote table alone does not qualify.
BW/4HANA Public Cloud Edition (PCE): The rival lift-and-shift target that rehosts BW/4HANA with its own reporting stack intact, unlike the bridge, which always subordinates BW content to Datasphere's semantic layer.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →

Guides that answer with this page

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