Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BW shell conversion — the route that forces the estate to justify itself

As of 2026-08-14

A shell conversion builds an empty BW/4HANA shell, carries the model across, and reloads the data afterwards. It is one of three conversion routes SAP ships alongside in-place and remote, and it is the one chosen when the estate needs pruning — because a shell makes somebody decide, object by object, what deserves to travel.

What a shell conversion actually does

The target starts empty. The model — the objects that carry the analytical meaning, InfoObjects, transformations, DTPs, process chains and the query layer — is carried across into the new object model, and data is reloaded into it afterwards rather than converted in place.

That sequencing is the whole point. In an in-place conversion, everything in the source is in scope by default and must be argued out. In a shell conversion, nothing is in scope by default and must be argued in.

The object-model gap is what makes either route a modelling exercise. The Advanced DSO absorbed what standard DSOs, write-optimised DSOs and InfoCubes did separately; CompositeProviders absorbed MultiProviders and InfoSets. Fewer target object types than source types means per-object decisions, and a shell simply front-loads them.

When it beats in-place

Choose shell when the estate has accumulated more than it can justify: objects nobody queries, hierarchies built for a business the company no longer runs, transformations whose owner left. Carrying that across is not neutral — it becomes cost on the new platform and it becomes the reason the next transformation is also expensive.

Choose in-place when continuity is the dominant requirement and the estate is in reasonable condition. In-place preserves the system identity and the surrounding interfaces, and it does not ask the organisation to re-decide anything.

Choose remote when the source system cannot be disturbed and a parallel target is affordable.

The honest test is not technical: it is whether anybody is willing to say out loud that a given report will no longer exist.

The political cost nobody prices

A shell conversion is the route that requires the most sponsorship, because retiring content is a political decision and not a technical one. "Retire" means somebody's report disappears, and the plan that retires four hundred reports without a named business owner will stall, whatever the tooling says.

The signal to look for in a migration plan is straightforward: a retirement list with no sponsor attached. That is the long pole of the programme sitting unowned in an appendix.

The second unpriced item is history. Every route has to decide what happens to years of BW history — archive in place, port selectively, or leave cold — and a shell forces that question early, which is an advantage disguised as an obstacle. Treated as an afterthought, it reliably damages both timeline and budget in the final quarter.

What it does not buy you

A shell does not clean a model by itself. It creates the moment at which cleaning can happen; if nobody uses that moment, you have rebuilt the same estate on a new platform at higher cost than an in-place conversion would have charged.

It also does not remove the residue. Tooling carries a large share of any conversion, and what remains is judgement — custom logic, unusual hierarchies, bespoke authorisations — which is where the effort concentrates regardless of route.

And it does not settle the destination question. BW/4HANA is the successor within the BW lineage; Datasphere and Business Data Cloud sit at different layers. If the target operating model is cloud data products and the estate is small enough to rebuild, the right conversation is about destination, not about which conversion route to use.

What we cannot assert

We do not publish a tool-by-tool procedure for a shell conversion, nor which tool version supports which source release — that is settled in SAP's own conversion documentation for the release in question, and a procedure restated second-hand is the kind of content that silently goes out of date.

Frequently asked

What is the difference between shell and in-place conversion?

In-place converts an existing BW system to BW/4HANA on the same system, object by object, with everything in scope by default. Shell starts from an empty BW/4HANA system, carries the model across and reloads data, so nothing is in scope until someone argues it in.

Is shell conversion slower?

It is slower to start and often cheaper to finish, because the work removed up front is work not carried for the rest of the system's life. The comparison only makes sense against how much of the estate should not have travelled.

Does a shell conversion keep our history?

Only what you reload. That is an explicit decision per data set — archive in place, port selectively, or leave cold — and deciding it late is one of the most reliable ways to overrun the last quarter of a migration.

Who should own a shell conversion decision?

A named business sponsor who can approve retirement, alongside the architect. Without that sponsor the route is not viable, because its entire advantage rests on decisions the business has to make.

What this page is built on

Read next