Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP BW remote conversion — the third route, and the estates it suits

As of 2026-08-14

Remote conversion is the third of the three routes into SAP BW/4HANA, alongside in-place and shell. It uses a separate target system that receives the model and the selected content from the source, while the source keeps running until cutover. Its distinguishing property is not speed and not cleanliness — it is that the production system is never the thing being converted.

How the three routes differ in one sentence each

In-place converts an existing BW system to BW/4HANA on the same system, object by object: identity and interfaces are preserved, and everything in the source is in scope by default.

Shell builds an empty BW/4HANA system, carries the model across and reloads data afterwards: nothing is in scope until someone argues it in, which is why it is chosen when the estate needs pruning.

Remote provisions a separate target and transfers the model and selected content into it from the source, leaving the source untouched and running.

All three carry the same underlying obligation, because the target object model is smaller than the source's: every InfoCube becomes an aDSO with a chosen configuration, every MultiProvider becomes a CompositeProvider with an explicit join-or-union decision.

When the extra system earns its cost

The case for remote is risk, not effort. A separate target means the source is never in a converted-but-unvalidated state, so the fallback at every point in the programme is "keep running production as it is" rather than "restore".

That matters most where reporting cannot pause and where the business will not accept a conversion window on the system of record — regulated reporting cycles, month-end dependencies, or an estate that feeds downstream systems that cannot be re-pointed quickly.

It also allows selective content transfer, which makes it closer to a shell in outcome and closer to in-place in effort: you can decline to bring objects across without rebuilding the model from nothing.

What it costs is a second landscape for the duration, plus the reconciliation work of proving that two live systems agree. That reconciliation is auditor-grade work and is not a rounding error in the plan.

The decision, stated plainly

Continuity dominates, the estate is in reasonable condition, and a conversion window on the source is acceptable → in-place.

The estate has accumulated more than it can justify and a business sponsor will own retirement → shell.

The source cannot be disturbed, a parallel landscape is affordable, and selective transfer is wanted without a full rebuild → remote.

The destination itself is in question — cloud data products rather than the BW lineage, and an estate small enough to rebuild → none of the three; the conversation is about target platform, not conversion route.

What none of the routes removes

Tooling can carry a large share of any of these conversions. The residue is judgement, and the residue is where the effort concentrates — which is the mechanism behind the observation that BW/4HANA projects rarely resemble upgrades.

The residue is concentrated in predictable places: custom transformation logic, hierarchies that were modelled around a business rule rather than a structure, and authorisation patterns built up over years of exceptions.

The second thing no route removes is reconciliation. Every migration has to prove that the reported numbers still agree, and that proof is planned work with an owner, not a phase that absorbs whatever time is left.

What we cannot assert

Our corpus names the three conversion routes and the decision logic between them; it does not carry a tool-version support matrix, and we do not invent one. Whether remote conversion is available from a specific source release, and with which tooling, is settled in SAP's conversion documentation for that release.

Frequently asked

What is remote conversion in SAP BW?

A conversion route in which a separate BW/4HANA target system receives the model and selected content from an existing BW system, while the source continues to run until cutover. It is one of three routes SAP ships, with in-place and shell.

Remote or shell — which should we choose?

Shell when the driving need is to prune an estate nobody has justified in years and a sponsor will own retirement. Remote when the driving need is that production cannot be disturbed, and selectivity is a benefit rather than the purpose.

Does remote conversion take longer?

It adds landscape and reconciliation work, and it removes the risk of an unvalidated production system. Whether that trade is favourable depends on what an outage or a failed reconciliation would actually cost that business.

Is the conversion route the main cost driver?

No. The main driver is the share of the estate that tooling cannot convert without judgement — custom logic, unusual hierarchies, bespoke authorisations. The route changes risk profile and sequencing more than it changes total effort.

What this page is built on

Read next