SAP BW to Datasphere Migration: BW Bridge, Conversion Paths, and Cutover
Most SAP analytics estates still rest on a decade or more of SAP BW investment, and "how do we get this to Datasphere?" is rarely a single decision. It is a set of them: which content moves, how it moves, what comes with the data, and how you go live without a reporting blackout. In my advisory work the migrations that go badly are almost always the ones that treated this as a lift-and-shift; the ones that go well treated it as a chance to decide, object by object, what deserves to come forward. This guide covers the three realistic paths into Datasphere, gets the shell-versus-remote conversion distinction right (the secondary internet gets it wrong often enough to be dangerous), walks the conversion phases, and lays out the parallel-run cutover that keeps the lights on while you transition.
Three realistic paths, not one
There is no single "migrate BW" button, and pretending there is leads to the worst outcomes. There are three paths, and a real program usually uses more than one across different parts of the estate.
The first is a greenfield re-model directly in SAP Datasphere — rebuilding the semantics natively in Datasphere spaces rather than carrying BW structures across. It is the most effort and the cleanest result, and it is the right choice for content that is valuable but tangled, where the modeling debt is the real problem you are trying to leave behind. The second is SAP BW Bridge, a BW-like (ABAP/BW) environment provisioned inside Datasphere that lets you migrate existing BW objects with the SAP transfer tool — this is the path that preserves your BW investment with the least re-modeling. The third is the Business Data Cloud route: lift BW into SAP Business Data Cloud as a private cloud edition (SAP maintains SAP BW 7.5 there until the end of 2030 and SAP BW/4HANA until 2040), then use the BW Data Product Generator, which replicates BW InfoProvider data into the Datasphere object store so it can be published as data products. The important caveat is that it replicates data — it does not auto-convert your BW models into finished Datasphere analytic models; BW queries move separately with the Query Template Generator.
Shell vs remote conversion — getting it right
Within the BW Bridge path there are two conversion modes, and this is where I see the most confusion, including in otherwise-credible write-ups. The distinction is simple once stated correctly: it is about whether data comes with the metadata. SAP's tooling supports both modes from SAP BW 7.3 (SP10 and higher) through 7.5 and from SAP BW/4HANA 2021, and the bridge itself only connects to sources through ODP.
Shell conversion transfers metadata only — the object definitions (InfoObjects, DataStore Objects, CompositeProviders) move into BW Bridge as empty "shells," with no data. After the structures are in place, you re-point your ODP source connections and load data directly into the new objects. Shell conversion is effectively a subset of remote conversion, and it is the right choice when you want a clean reload, when source data is being re-staged anyway, or when the existing data is not worth carrying forward.
Remote conversion transfers metadata and the business data together, from your on-premise SAP BW or BW/4HANA to the target receiver system, using the SAP transfer tool — metadata moves as XML over RFC and is converted to supported objects on import, and the data comes with it. It is the right choice when the loaded data has value you want to preserve in place rather than rebuild. One correction worth stating plainly, because it trips people up: remote conversion is not federation. It physically transfers data into BW Bridge; it does not leave the data in the source and query it live. That live-access pattern exists in Datasphere as remote tables, but it is a different mechanism and should not be conflated with remote conversion.
How a conversion actually runs
A remote conversion is a staged process, not a single copy, and understanding the phases is what lets you plan the downtime window honestly. It runs as a generation phase that builds the transfer programs, a preprocessing phase executed during a system lock (where PSA data is extracted and delta queues are copied and synchronized), the migration phase that moves the objects and data, and a post-processing phase during a lock that runs validations and repairs. The two locked windows are the part that matters for the business: they are where reporting against the affected objects pauses, so they belong in the cutover plan and the stakeholder communication, not as a surprise on go-live weekend.
The practical lesson from projects is to convert in waves rather than all at once. Group objects by data flow and business area, convert and validate a wave, and only then start the next. A wave that fits inside a weekend lock is recoverable; a big-bang conversion that overruns its window is the scenario that turns into a Monday-morning incident.
Cutover and the parallel run
However you convert, the safest go-live is a parallel run: stand up the Datasphere target alongside the live BW system, load both, and reconcile outputs until the numbers match for long enough to trust them. The discipline that makes this work is defining reconciliation up front — pick the reports and key figures that must tie out, decide the tolerance, and decide how many clean cycles you need before you cut over. Without that definition, "parallel run" becomes an open-ended comfort blanket that nobody is willing to end.
Plan the cutover around the locked windows above, sequence it by wave, and keep a rollback position for each wave until its reconciliation passes. And resist the temptation to carry every legacy object across "just in case" — a migration is the rare moment when the organization has permission to retire the reports nobody runs. The estates that come out of this lighter and clearer are the ones that used the cutover as an editorial decision, not just a technical one.
Where teams go wrong
Three failure patterns recur. The first is lift-and-shift thinking — carrying every BW object across without deciding what deserves to come forward, which simply relocates the modeling debt into a newer tool. The second is conflating remote conversion with live federation and then being surprised by the data-transfer effort and the locked windows; the phases are real and need a plan. The third is treating the parallel run as a vibe rather than a gate, so go-live keeps slipping because no one defined what "reconciled" means. Avoid those three and the rest is project management. As always, validate the specific tool versions, supported object types, and conversion options against SAP's current BW Bridge documentation before you commit a plan — the migration toolset evolves, and the supported-object matrix is the detail most worth confirming for your exact release. For the Data Product Generator, confirm the private cloud prerequisite and the release levels in SAP Note 3590400 (SAP BW/4HANA 2023 SP0 or higher, SAP BW/4HANA 2021 SP4 or higher, SAP BW 7.50 SP24 or higher); at the time of this review it did not yet support BW hierarchies.