SAP BW Bridge or Full Datasphere Migration? Choosing the Route by Reuse, Cost and Lock-in

SAP BW Bridge carries BW staging logic, meaning data models, transformations, ABAP routines and process chains, into SAP Datasphere, but not queries, the OLAP engine or analysis authorisations. Choose it where custom staging logic is heavy and well built; rebuild natively where models are weak; run a staged hybrid where the estate is mixed.

The pressure is a published date. SAP's maintenance strategy for SAP NetWeaver 7.5 states that maintenance for SAP BW 7.5 continues to the end of 2027, with extended maintenance to 2030. The same statement aligns SAP BW/4HANA with SAP S/4HANA and commits it to maintenance until the end of 2040 through a sequence of releases. Those two horizons put BW 7.5 and BW/4HANA owners in very different positions, and the route choice should reflect that.

The second pressure is less visible. SAP's own maintenance statement records that BW 7.5 has been in maintenance mode since 2016, with feature investment going into BW/4HANA instead. A BW 7.5 estate that stays put does not just age; it stands still while every surrounding SAP product moves.

This article sets out what the bridge does and does not carry, the three questions that decide the route, and the conditions under which the bridge is the wrong answer. For the mechanics of running the migration itself, including usage rationalisation and readiness artefacts, our step-by-step BW to Datasphere migration guide covers the how; this piece covers the which.

#What SAP BW Bridge Actually Is

What this means for you: if your plan assumes the bridge is "BW in the cloud", the plan is already over-scoped, because SAP describes something much narrower.

SAP Datasphere is SAP's cloud data-warehousing and data-integration service. SAP BW Bridge is a component provisioned inside it that runs BW-style data staging in the public cloud. The term is often used loosely, as though a BW system is moved wholesale into Datasphere and keeps working as before.

SAP's own Shell Conversion Guide is explicit that this is not the case. It describes the bridge as "not a full SAP BW/4HANA component within SAP Datasphere" and as limited to the ABAP-based staging layer. The guide goes on to state that the bridge has no OLAP engine, and therefore no support for features that depend on it, naming non-cumulative key figures, analysis authorisations, planning and variables.

The useful definition, then, is this. BW Bridge is a hosted staging layer that accepts converted BW data models, transformations and ABAP routines, loads data through Operational Data Provisioning, and hands the result to native Datasphere models for everything above staging. Reporting, security and semantics are rebuilt in Datasphere and its consuming tools whatever route you take. The real question is how much of the layer beneath them you carry across.

#The Three Routes at a Glance

What this means for you: read the last column first; if none of its conditions describe your estate, the native rebuild is your default route.

Two observations sit behind this table. First, every route shares the same top half: queries, authorisations and reporting are redesigned in Datasphere and its consuming tools whichever route you pick, so the bridge saves effort only in staging. Second, the lock-in column is not an argument against Datasphere. It is an argument for knowing which of your logic you are choosing to keep in ABAP, and for how long.

#What BW Bridge Carries Over, and What It Leaves Behind

What this means for you: the bridge's value is proportional to the share of your estate that lives in staging, so measure that share before you price the route.

SAP's Shell Conversion Guide sets out the conversion paths. The shell conversion transfers selected data models from SAP BW systems on SAP NetWeaver 7.30 to 7.51, on any database, and from SAP BW/4HANA 2021. A separate remote conversion can also transfer and synchronise existing data. The guide states plainly that systems on SAP NetWeaver 7.52 or higher are not supported for shell conversion.

Custom code deserves its own line. The guide notes that ABAP classes and function modules outside routines must be moved separately using abapGit, and that ABAP reports are not supported in that transfer. It also states that the bridge is not intended for ABAP application development beyond BW transformations; customers needing that are pointed to a separately licensed SAP BTP ABAP environment.

The bridge saves you remodelling effort only below the query line, and it charges you rent on everything you keep there.

Source connectivity narrows the scope again. The bridge is only intended for ODP-based source systems: BW, SAP extractors, ABAP CDS views from SAP S/4HANA, and SLT. Other source types have to be integrated through Datasphere's own interfaces, which means part of a bridge-route estate is a native build regardless.

#Three Questions That Decide the Route

What this means for you: three counts, each producible from system metadata in a few weeks, settle most of the decision before an architecture workshop is booked.

The cheapest way to make this decision is to stop arguing about platforms and count three things. Each one moves the answer in a known direction.

#How much custom ABAP sits in staging, and how good is it?

Custom ABAP volume is the strongest argument for the bridge. Years of routines encoding currency handling, organisational mappings, or data corrections are expensive to re-express as native Datasphere transformations, and every re-expression is a reconciliation risk.

Volume alone is not enough, though. Grade the code. Routines that are documented, tested and tied to active data flows are worth carrying. Routines that nobody can explain, that duplicate each other across layers, or that call reports and function modules outside the transfer scope are a reason to rebuild, because the bridge would preserve the confusion along with the logic.

#What do your process chains actually orchestrate?

Process chains survive conversion, with SAP's tooling adjusting them to successor objects. That matters if your chains carry real operational knowledge: load dependencies, error handling, restart logic and timing that the business relies on at month end.

It matters less if most chains are thin wrappers around loads you would redesign anyway. SAP's release notes for the bridge also describe external access to process chains, letting a bridge administrator control chains held in a third-party tool or in SAP BW, which helps while both platforms run side by side. Count the chains that encode genuine operational logic, not the chain total.

#Who reads BW queries today, and through which tools?

Downstream reporting is where the bridge saves least. Because queries cannot run in the bridge, every consumer of a BW query, whether in SAP Analysis for Office, SAP BusinessObjects, an SAP Analytics Cloud live connection or a scheduled broadcast, needs a new path to Datasphere-side models whatever route you choose.

That makes the consumer inventory a cost to budget, not a tiebreaker. Where the consumers sit in BusinessObjects, our BusinessObjects and Analytics Cloud practice maps them before the staging route is fixed. Where the estate leans on analysis authorisations for row-level security on regulated data, treat the redesign of that security model as a design deliverable in its own right, with its own test evidence.

#The Staged Hybrid: How to Make It Hold

What this means for you: hybrid is the honest answer for most large estates, and it fails only when nobody writes down which subject areas leave the bridge, and when.

A staged hybrid uses the bridge where the three questions favour it and rebuilds natively elsewhere. Done well, it front-loads the cheap reuse and spreads the expensive rebuild across waves the business can absorb. Done badly, it produces two warehouses inside one tenant with no plan to converge them.

Three disciplines keep it honest. Every subject area admitted to the bridge carries an exit criterion, such as a source-system change, a model redesign or a date, recorded in the business case that funds it. Native Datasphere models are the only place new reporting logic is built, so the bridge stays a staging layer rather than becoming a second semantic layer. And waves are sequenced against the source systems: if an ECC to SAP S/4HANA conversion is moving extractors underneath you, staging built against those extractors should move after its source stabilises. Our account of protecting analytics through an S/4HANA conversion covers that coupling in detail.

A hybrid with no exit dates is not a strategy, just two warehouses sharing a login.

Moving hundreds of objects wave by wave, each with reconciliation evidence, is a delivery discipline in itself. It is the workload our migration factory model is built for: dependency-aware sequencing, automated reconciliation and rollback paths agreed before cutover. The integration side, connecting SAP and non-SAP sources to the Datasphere target with lineage intact, sits with our SAP data integration and orchestration work.

#Cost, Reuse and Lock-in, Without the Brochure

What this means for you: the cheapest route on day one is often not the cheapest across the life of the platform, so price both horizons before you sign.

The bridge lowers first-wave effort because converted objects do not need remodelling. But it runs as a separately provisioned instance alongside Datasphere, and every subject area that later leaves it is rebuilt natively anyway. If most bridged areas will exit within a few years, the bridge has bought time rather than reduced total effort. Time can be worth buying, but it should be bought deliberately.

A native rebuild front-loads cost into modelling. Its total cost depends far more on how much of the estate you decline to rebuild than on any licence line, which is why usage rationalisation matters more on this route than on any other. The reward is one platform, one modelling pattern and one set of skills to run afterwards.

Reuse should be measured in active, well-graded staging logic, not in object counts. A bridge that carries a thousand objects of which a few hundred are used has reused a cost, not an asset.

#When BW Bridge Is the Wrong Choice

What this means for you: if two or more of these describe your estate, the bridge is likely to cost more than it saves.

The bridge is the wrong route in five recognisable situations.

The first is a light staging layer. If most of your logic lives in queries, restricted key figures and front-end calculations rather than in ABAP routines, the bridge carries little of value, because none of that query-layer logic runs there. The second is a source landscape that is not ODP-based: the bridge is only intended for ODP sources, so heavy flat-file, database or third-party feeds push the work into native Datasphere regardless.

The third is a system the conversion tooling does not cover. SAP's shell conversion supports BW on NetWeaver 7.30 to 7.51 and BW/4HANA 2021; anything outside that range needs an upgrade, or a different route, before the bridge is an option. The fourth is a planning-heavy estate, because the bridge does not support BW planning.

The fifth is a BW/4HANA estate with no business reason to move now. SAP has committed BW/4HANA to maintenance until the end of 2040, so a well-run BW/4HANA system faces no 2027 cliff, and a forced bridge conversion would spend money to solve a problem that does not yet exist. In that case the better move is to build new use cases natively in Datasphere and let the BW/4HANA estate shrink on its own schedule.

#The Path Forward: A Route Decision in Weeks

What this means for you: the route decision is a scoped piece of analysis, not a programme, and it should be finished before any conversion tooling is bought.

The common misreading is that choosing a route requires a pilot migration. It does not. A route decision for a mid-sized estate, scoped to a metadata and usage analysis with no data moved, typically takes weeks rather than quarters.

1. Confirm your release and its horizon. Record the SAP_BW release and support package of every system in scope, and its maintenance date. A BW 7.5 system and a BW/4HANA system face different deadlines and different conversion options.
2. Inventory staging logic by subject area. Count and grade custom ABAP routines, classes and function modules, and flag any reports that the transfer will not carry.
3. Classify the process chains. Separate chains that encode operational logic from chains that only sequence loads.
4. Map every query consumer. List each report, workbook, broadcast and extract that reads a BW query, with its owner and its target in the new estate.
5. Assign a route per subject area. Apply the three questions, record the result, and give every bridged area an exit criterion.
6. Price both horizons. Model first-wave effort and the cost of running and later exiting the bridge, including the skills to maintain it.

The output is a short, evidence-led recommendation per subject area that a steering group can approve. Our SAP BW modernisation and Datasphere migration engagement produces exactly that: an object and usage audit, a rationalised scope, and a sequenced route weighed against staying on extended maintenance. Where the BW work runs alongside an ECC conversion, our S/4HANA transformation practice keeps the two timelines from colliding. Reporting logic rebuilt on the Datasphere side is the moment to agree one governed semantic layer rather than recreating every query as it stood.

#Frequently Asked Questions

#What does SAP BW Bridge carry over into SAP Datasphere?

SAP BW Bridge carries the BW staging layer: data models converted to their current equivalents, transformations and data transfer processes with their ABAP routines, process chains, and ODP-based source connections. It does not run analytical queries and has no OLAP engine, so analysis authorisations, planning, variables and non-cumulative key figures are not supported in the bridge. Reporting and security are rebuilt on the Datasphere side, whichever route an organisation chooses.

#Can BEx queries run in SAP Datasphere, SAP BW bridge?

No. SAP's release notes for SAP Datasphere, SAP BW bridge state that analytical queries cannot be created, changed or executed in the bridge. Queries transferred from SAP BW or SAP BW/4HANA can be checked in the bridge cockpit and imported into SAP Datasphere, where the resulting artefacts can be used for reporting. Queries that use functions SAP Datasphere does not support are flagged as unsuitable, so each consumer still needs reviewing.

#Is BW Bridge cheaper than rebuilding natively in Datasphere?

BW Bridge is usually cheaper in the first wave, because converted models and ABAP routines do not need remodelling. It is not automatically cheaper overall. The bridge runs as a separately provisioned instance, needs BW-skilled people to maintain it, and any subject area that later leaves it is rebuilt natively anyway. It wins on total cost when staging logic is heavy, well built and expected to stay for several years.

#Which SAP BW releases can be converted to BW Bridge?

SAP's Shell Conversion Guide for SAP Datasphere, SAP BW bridge covers SAP BW systems based on SAP NetWeaver releases 7.30 to 7.51, on any database, and SAP BW/4HANA 2021. Systems on SAP NetWeaver 7.52 or higher are not supported for shell conversion. A separate remote conversion can also transfer existing data. Minimum support packages apply, so check the current guide and SAP Notes before planning.

#Do SAP BW/4HANA customers face the same 2027 deadline?

No. SAP's published maintenance strategy ends mainstream maintenance for SAP BW 7.5 at the end of 2027, with extended maintenance to 2030, but commits SAP BW/4HANA to maintenance until the end of 2040 through a sequence of releases. BW/4HANA owners can therefore choose a Datasphere route on business merit rather than deadline pressure, building new use cases natively while the existing estate keeps running.

---

Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.

If you are weighing whether BW Bridge, a native Datasphere rebuild or a staged hybrid fits your estate, book a discovery call and we will work through it with you.