Concept card

SAP BW/4HANA

As of 2026-08-29

Edited by Cédric-Olivier Mâry, 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/4HANA?

SAP BW/4HANA is SAP's HANA-only data warehouse product, generally available since 2016. The naming invites a mistake worth naming early: it is not "BW, release 4". It is a separate product with its own code line, and a customer does not upgrade into it so much as move into it.

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

Why that makes it a modelling exercise. Because the target has fewer object types than the source, there is no faithful one-to-one translation for a mature BW estate. Every InfoCube must become an aDSO with a chosen configuration; every MultiProvider must become a CompositeProvider with an explicit join or union decision. Tooling can carry a large share of it and SAP ships conversion paths — in-place, remote, and shell — but the residue is judgement, and the residue is where the effort concentrates. This is the mechanism behind the observation that BW/4HANA projects rarely resemble upgrades.

Scale, stated as a floor. The registry carries ~2,500 BW/4HANA customers against the 20,000-30,000 classic BW 7.5 customers SAP named at Sapphire 2025 (Dominik Kurz, reported by SAPinsider). Both are floors from public disclosure rather than counts from a register, and the ratio is the more robust reading: the modernised cohort is a clear minority of the BW estate. That asymmetry, not either number on its own, is what drives the migration-demand argument.

Where it sits against Datasphere and BDC. BW/4HANA is the successor within the BW lineage. SAP Datasphere is a cloud data-warehousing service with a different modelling model, and SAP Business Data Cloud is the packaged data-product layer above it. They are not rival answers to one question. A customer can run BW/4HANA and Datasphere together, and BW Bridge exists precisely to let BW content land inside Datasphere. Treating the choice as either/or is the most common framing error in this part of the stack.

The conversion paths, and what each actually costs

SAP ships three documented paths and none of them is free of the modelling residue described above.

In-place conversion runs inside the existing system: objects are converted where they stand, in a controlled sequence, and the system ends up HANA-only with the same technical identity it had before. It suits a single system with an acceptable downtime window and a technical debt load the team is willing to carry across unchanged — because in-place conversion does not force a redesign, it just executes the object-type mapping (DSO/InfoCube to aDSO, MultiProvider/InfoSet to CompositeProvider) that the reduced object model requires.

Remote conversion stands up a new BW/4HANA system and pulls content across from the source system object by object, which is the natural point to also consolidate multiple source systems or retire content nobody uses. It costs more calendar time than in-place but buys a genuine architecture reset.

Shell conversion keeps only the technical shell of the target system and rebuilds or selectively transports content into it. It is the right call when the source estate carries enough undocumented technical debt that converting it mechanically would just relocate the problem — but it is also the path where the judgement residue is largest, because nothing is carried by tooling alone.

Sizing a BW/4HANA project honestly

The three paths above are not substitutes for scoping; they are different distributions of where the judgement work lands. A vendor quote that names only the path and not the object inventory — how many InfoCubes, how many MultiProviders, how many custom transformation routines — has not actually scoped the project, because the aDSO and CompositeProvider mapping decisions are exactly the line items neither tooling nor the path choice removes.

The decision this forces

Two decisions, taken in order, and the second is the one that carries the estimate. First, path: in-place, remote or shell — a trade-off between calendar time and architecture reset, not between cheap and expensive. Then, for every object with no successor in the smaller model, a per-object decision: map it mechanically, redesign it, or retire it. The tooling carries the mapping; it carries none of the redesign and none of the retirement conversations. Framing the move as an upgrade hides exactly that second decision, which is why an estimate that names a path but not an object inventory is not an estimate — it is a preference.

Why it matters

BW/4HANA is the one path that keeps the BW modelling paradigm intact. Whether that is an asset or a delay depends on where the customer intends to be once BDC and Datasphere are the strategic targets.

Key points

A separate product, not a BW release: its own code line, HANA-only, generally available since 2016.
Installed-base floor ~2,500 customers against 20,000-30,000 BW 7.5 customers (SAP, Sapphire 2025) — the modern cohort is a minority of the BW estate.
The aDSO replaces the DSO/InfoCube split; CompositeProviders replace MultiProviders and InfoSets. Fewer object types, more decisions pushed into modelling.
🔴 It is a successor to BW, not an alternative to Datasphere or BDC — they sit at different layers, and choosing one does not settle the other.
Conversion paths exist (in-place, remote, shell) but the residue is judgement, and that residue is where the effort concentrates.
The path decision (in-place · remote · shell) trades calendar time against architecture reset; it is not a cheap-versus-expensive choice.
The estimate lives in the per-object decision — map, redesign or retire — for every object with no successor in the reduced model.
An estimate that names a path but no object inventory is a preference, not an estimate.

Common pitfalls

Reading the name as a release number — Signal: "We'll just upgrade to BW/4" Fix: Separate product, separate code line. Plan a move, not an upgrade.
Framing BW/4HANA against Datasphere as either/or — Signal: A slide with one arrow and two boxes Fix: Different layers. BW Bridge exists precisely so both can hold at once.
Quoting the BW installed base for BW/4HANA — Signal: 20,000-30,000 attached to BW/4HANA Fix: 20,000-30,000 is classic BW 7.5 (SAP, Sapphire 2025); the BW/4HANA floor is ~2,500. The ratio is the point.

Decision framework

Decision framework
Decision	Option A	Choose A when	Option B	Choose B when
BW/4HANA or straight to Datasphere/BDC	BW/4HANA	The BW modelling paradigm is an asset; the estate is large and the team is BW-fluent	Datasphere / BDC	The target operating model is cloud data products; the estate is small enough to rebuild
How to size the move	Upgrade-shaped	Rarely correct — only for an already-thin estate	Modelling-shaped	The default: fewer target object types than source means per-object decisions

Facts worth quoting

SAP BW/4HANA's installed-base floor is roughly 2,500 customers against the 20,000-30,000 classic BW 7.5 customers SAP named at Sapphire 2025 (SAP — Dominik Kurz, Senior Director Product Management SAP BW/4HANA & BW Bridge, Sapphire 2025, reported by SAPinsider) — a minority of the BW estate.
SAP BW/4HANA has been generally available since 2016 — nearly a decade of GA history against which the ~2,500-customer floor is measured.
3 documented conversion paths exist — in-place, remote, shell — and SAP's own guidance is that tooling carries a large share of each, with the residue landing on judgement.
The reduced object model collapses what were three distinct semantics (standard DSO, write-optimised DSO, InfoCube) into one aDSO with configuration flags — a 3-to-1 consolidation.
MultiProviders and InfoSets — two separate object types in classic BW — both collapse into CompositeProviders in BW/4HANA — a 2-to-1 consolidation.

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.