SAP Business Data Cloud migration: choosing the path, not defaulting to it
As of 2026-08-14
Migrating to SAP Business Data Cloud is not a single motion, and the decision shaping the whole programme is which of four paths to recommend: rehost the existing model, migrate selectively through the bridge, rebuild greenfield, or run both estates side by side while moving line of business by line of business. Most Tier-1 programmes end up on the fourth regardless of what was chosen on paper, which is why the useful question is not which path is best but which one you are honestly planning for.
The four paths and their trade-offs
Lift-and-shift preserves the existing model and rehosts it. Right when the model is in reasonable shape and the driver is infrastructure or licensing pressure rather than modernisation. It buys time without buying capability: the customer inherits the new platform's cost model while keeping every modelling debt accumulated over the old model's lifetime. Frame it as transitional, never as an end state.
Selective migration through the bridge is the pragmatic default for most Tier-1 customers, exposing existing objects as native semantic-layer objects without full re-engineering. It caps how much model debt gets resolved — you inherit the semantics, warts included — in exchange for a shorter timeline and lower delivery risk, and it deserves a stated cap rather than an open-ended runway.
Greenfield redesigns the analytics layer from source. Right specifically when the existing model is the problem: undocumented enhancements, conflicting objects, a model built for a business the company no longer runs. The trade is timeline, cost and retraining every report consumer.
Hybrid extended coexistence is less a choice than a description of what happens. The trade to manage is governance: without an explicit sunset plan it becomes a permanent two-platform estate.
The complexity gate that sets the plan
Where an existing warehouse estate is in scope, the generator scores every object it scans for conversion complexity, and that score turns a wish into a schedule.
Low-complexity objects generate automatically with minimal touch-up. Mid-range objects generate with meaningful remediation expected. The highest-complexity objects are flagged for manual redesign, with scaffolding rather than a finished product.
In a typical Tier-1 estate roughly seventy to eighty per cent of objects fall in the auto-eligible range. The remaining twenty to thirty per cent — custom transformation logic, unusual hierarchies, heavily bespoke authorisations — is where judgement earns its rate, and where a plan assuming full automation goes wrong.
The planning error worth naming: pushing high-complexity objects through automated generation anyway. The tool produces something that runs, and reconciliation against the legacy report fails in ways that surface during acceptance testing rather than build.
Preserve the logic, or fix it
Ask the diagnostic question out loud in front of the customer: do we want to preserve this logic, or is this migration the opportunity to fix what was built wrong?
Generate when the logic is correct and trusted, the business cannot tolerate a reporting freeze, and there is no appetite for a semantic redesign. The generator compresses the mechanical portion of what would otherwise be a many-month manual conversion, concentrating resource on the minority that needs rethinking.
Remodel natively when the logic itself is the problem — undocumented custom exits, a decade of layered workarounds, definitions the business has never trusted. There the generator faithfully reproduces flawed logic, moving technical debt intact rather than eliminating it.
There is a strategic version too. Rehosting the warehouse runtime elsewhere without landing on the platform delivers no data-product catalogue, no lakehouse integration and no agent grounding on the converted objects — which for a customer with an AI agenda is the whole argument.
What the generator will not do
Custom transformation code emits as a stub, not working logic; it has to be rewritten as a data flow or a semantic-layer view, and on a complex estate that is a workstream rather than a task.
Hierarchy versioning does not carry across on its own — the legacy platform supports historical versions natively, and the target mapping needs an explicit version-timestamp design the tool does not infer.
Authorisation models need deliberate conversion into access-control rules rather than a like-for-like copy, because the security models are not identical. And report conversion produces a scaffold: manual finishing is the norm, so budgeting it as automated understates effort.
One more, with the highest blast radius: reporting-parity reconciliation before cutover. A converted object that looks structurally correct but diverges on edge-case rows will not surface until a business user notices a wrong number, and at that point trust in the whole migration is at risk.
The risks that are not technical
The commonest anti-pattern is treating the migration as a technical lift when it is a governance and change-management programme with a technical component. Scoping around object counts and volumes under-prices the stakeholder alignment work.
The second is selling greenfield when the existing model is salvageable, because greenfield engagements are larger. Experienced buyers screen for this explicitly now.
The third is deferring the historical-data question — archive in place, port selectively, or leave cold — which reliably blows both timeline and budget in the final quarter.
The fourth is political: IT, finance and the internal centre of excellence frequently disagree about urgency, and picking a path before that disagreement surfaces means re-litigating the recommendation months into delivery. And archiving source objects before both retention policy and parity sign-off are complete removes the fallback the team needs if a late discrepancy forces a rollback.
What we cannot assert
We publish no migration cost or duration for a named estate. What dominates both is the complexity distribution of the existing objects, observable only from an assessment of that specific estate — a generic figure would be read as a benchmark it cannot support.
Frequently asked
What are the migration paths to Business Data Cloud?
Four: lift-and-shift rehosting the existing model, selective migration through the bridge, a greenfield rebuild, and hybrid extended coexistence. Most Tier-1 programmes land on the hybrid path regardless of which was chosen at kick-off, which is why the hybrid period deserves an explicit sunset plan from day one.
How much of an existing BW estate converts automatically?
Roughly seventy to eighty per cent of objects in a typical Tier-1 estate fall in the auto-eligible complexity range. The remaining twenty to thirty per cent — custom transformation code, complex unions, unusual hierarchies, bespoke authorisations — needs manual redesign, and the tool surfaces those as conversion warnings.
Should we generate the existing logic or rebuild it?
Generate when the logic is trusted and reporting cannot freeze. Rebuild when the logic itself is the problem — undocumented exits, layered workarounds, definitions the business has never trusted — because the generator reproduces faithfully and will move that technical debt into the new platform intact.
How do these migrations usually go wrong?
By being scoped as a technical lift. Object counts and volumes are the easy part; stakeholder alignment, the historical-data decision, reporting-parity discipline and the absence of a hybrid sunset date consume the schedule. Deferring parity testing multiplies rework after dozens of objects are already built.
What this page is built on
- The BW-to-BDC Migration Wave (C050)
- BW Data Product Generator (C013)
- SAP BW Data Product Generator — The BW Modernization Path (C270)
- Hybrid Architecture Patterns (C035)