Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Datasphere migration cost — the four variables that set it

As of 2026-08-14

Nobody can quote your migration from a web page, and any figure that does not name your estate is decoration. What can be stated is what the number is made of: how much of the existing estate converts by tooling, how much needs human redesign, how much parity testing the auditors will demand, and how long you run two platforms. Those four variables move the total by a factor of two or more.

Variable one: how much converts automatically

Conversion tooling reads existing BW objects and emits target-platform data products, preserving semantic types, hierarchies, restricted key figures and authorisation patterns wherever a mapping exists. In a typical large estate roughly seventy to eighty percent of objects fall in the automatically eligible band, converting without rewriting calculation logic.

Each object gets a complexity score. The low scores generate with under five percent manual touch-up; the middle band still generates but expects twenty to forty percent manual remediation; the top of the scale is flagged for redesign outright, with the tool offering scaffolding rather than a finished product.

Variable two: the residue that needs a human

The twenty to thirty percent that does not convert cleanly is not random. It is custom transformation code, complex composite unions, unusual hierarchy patterns and bespoke authorisation logic — everything the estate accumulated because standard functionality did not fit.

That residue is where the consulting fee sits, and where the real decision hides. Tooling faithfully reproduces flawed logic into the new platform: technical debt moves intact rather than being eliminated. The diagnostic question is whether you want to preserve this logic or whether the migration is the opportunity to fix what was built wrong.

Variable three: parity testing, which is not optional

Every migrated object has to produce the same number as the object it replaced, and somebody has to prove it. Our field guidance budgets four to eight hours per major object for auditor-grade reporting-parity testing.

Multiplied across a Tier-1 estate that is frequently the largest line in the plan after manual redesign — and the line most often cut in a competitive bid. The reason not to cut it is that a parity failure found after go-live is not a testing cost but a trust cost: finance stops believing the platform, and the recovery takes longer than the testing would have.

Variable four: how long you run two platforms

Dual running is where a well-scoped migration quietly becomes an expensive one. A bridged estate pays capacity on the new platform plus the embedded legacy licence for the whole bridge period, and the bridge is designed as a two-to-four-year ramp, not a destination.

What bounds it is a sunset date in the architecture decision record plus a cadence that runs — five to ten objects converted per quarter gets an estate meaningfully off the bridge by year three. Our guidance caps a bridge at around twenty-four months before it stops being transitional.

The orders of magnitude we can honestly state

For a Tier-1 estate, our research ledger records a manual migration timeline of twelve to eighteen months compressing to six to nine months with conversion tooling, and fees moving from roughly €1-1.8 million to roughly €500,000-900,000.

By phase, the same ledger puts discovery at roughly €50,000-150,000, design at €200,000-400,000, execution at €500,000 to €2 million, and hypercare at €100,000-300,000 as a retainer.

These are orders of magnitude for large estates from our own research, not a vendor price list and not a quote. A mid-market estate of fifty objects is a different exercise: for a small, well-documented estate, direct modelling on the target platform is usually faster and cheaper than any bridge.

What we cannot assert

SAP publishes no migration pricing and neither do we. Every figure above is an order of magnitude from our own research ledger for large estates, and none of it substitutes for a discovery phase that scores your own objects. There is also no single BW end-of-maintenance date to plan against — it depends on the product, the release and the contract, and only SAP's maintenance schedule for your version is authoritative.

Frequently asked

How much does an SAP Datasphere migration cost?

It depends on estate complexity more than anything else. For a Tier-1 BW estate our research ledger records roughly €500,000-900,000 with conversion tooling against €1-1.8 million done manually — orders of magnitude, not a quote.

How much of a BW estate converts automatically?

Roughly seventy to eighty percent of objects in a typical large estate convert without rewriting calculation logic. The remaining twenty to thirty percent — custom code, complex unions, bespoke authorisations — needs human redesign.

What is the most underestimated line in a migration plan?

Reporting-parity testing. Budget four to eight hours per major object for auditor-grade proof that the migrated object returns the same number. Its failure costs trust rather than money.

Does a bridge save money?

It defers spend and adds a second one. A bridged estate pays capacity on the new platform plus the legacy licence throughout, so it only pays off with a dated sunset and a conversion cadence that actually runs.

What this page is built on

Read next