Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BW4HANA upgrade path — the three conversion routes, and why none of them is an upgrade

As of 2026-08-14

There is no upgrade path into SAP BW/4HANA, and the name is what makes people look for one. BW/4HANA is not "BW, release 4": it is a separate product with its own code line, HANA-only, generally available since 2016. A customer does not upgrade into it so much as move into it, and SAP ships three conversion routes for that move — in-place, remote and shell. Choosing between them is a modelling decision, not a basis one.

Why the target has fewer object types than the source

Classic BW accumulated object types over eighteen years. BW/4HANA cut them back deliberately. The Advanced DSO absorbed the roles that standard DSOs, write-optimised DSOs and InfoCubes played separately — one object with configuration flags instead of three with distinct semantics. CompositeProviders absorbed MultiProviders and InfoSets. Classic InfoCubes, 3.x dataflows and transfer rules are gone. What survives is the part that carried the analytical meaning: InfoObjects, transformations, DTPs, process chains and the query layer.

Because the target has fewer object types than the source, there is no faithful one-to-one translation for a mature estate. Every InfoCube becomes an aDSO with a chosen configuration; every MultiProvider becomes a CompositeProvider with an explicit join-or-union decision. That is the mechanism behind the observation that BW/4HANA projects rarely resemble upgrades.

The three routes, and what each one is for

In-place conversion converts an existing BW system into BW/4HANA on the same system, object by object. It preserves system identity and interfaces, and it inherits everything else too — including the objects nobody has justified for years.

Shell conversion builds an empty BW/4HANA shell, carries the model across, and reloads data afterwards. It is the route chosen when the estate needs pruning, because a shell forces an explicit decision about what travels.

Remote conversion sits between them: a separate target system receives the model and selected content from the source, which keeps running until cutover. It suits estates where a parallel target is worth the infrastructure cost — typically because the source cannot be disturbed.

All three are tooling-assisted, and none removes the residue: the remainder is judgement, and the remainder is where the effort concentrates.

How to size the move honestly

Upgrade-shaped sizing is rarely correct, and it is only defensible for an already-thin estate. The default is modelling-shaped sizing: fewer target object types than source types means per-object decisions, and those do not scale down with a bigger project team.

The useful first measurement is therefore not the object count but the shape of the estate — how many objects carry custom logic, how many hierarchies are unusual, how many authorisations are bespoke. That tail sets the timeline.

For context on scale: our registry carries a floor of roughly 2,500 BW/4HANA customers against roughly 18,000 for BW overall, both floors from public disclosure rather than counts from a register. The ratio is the robust reading — the modernised cohort is a clear minority of the BW estate.

The decision this page should settle

The BW modelling paradigm is an asset, the estate is large, the team is BW-fluent → BW/4HANA is a reasonable destination, and the route follows the estate's condition.

The target operating model is cloud data products and the estate is small enough to rebuild → the question is not which route, but whether the BW lineage is the right destination at all. Datasphere and Business Data Cloud sit at different layers, and choosing one does not settle the other.

Continuity matters most and the estate is in reasonable condition → in-place.

The estate needs pruning and sponsorship exists to decide retirement → shell.

The source cannot be disturbed and a parallel target is affordable → remote.

What we cannot assert

Which conversion routes are available for a given source release, and which tool version supports them, depends on that release and is settled in SAP's own conversion documentation for it — we do not restate a support matrix here, because a support matrix quoted second-hand is the kind of claim that ages without warning.

Frequently asked

Can we upgrade from BW 7.5 straight to BW/4HANA?

Not as an upgrade. BW/4HANA is a separate product with its own code line, so the move runs through one of the three conversion routes and is sized as a modelling exercise, not a release upgrade.

Which conversion route is fastest?

In-place looks fastest on paper because nothing is rebuilt, but it carries the whole estate forward. Shell is slower up front and cheaper afterwards when much of the estate should not have travelled. The fastest route on a spreadsheet is rarely the fastest to a signed-off reconciliation.

Is BW/4HANA an alternative to Datasphere?

No. It is the successor within the BW lineage; Datasphere is a cloud data-warehousing service with a different modelling model, and BDC the packaged data-product layer above it. Framing them as either/or is the most common architecture error here.

Do we still need to move now that maintenance was extended?

The maintenance change removed the deadline framing — BW 7.5 extended maintenance moved to 31 December 2030 — but it did not change the object-model gap that makes this a modelling exercise.

What this page is built on

Read next