BDC and Datasphere: What Changes, What Stays

When SAP folded Datasphere into Business Data Cloud, the first question from every customer with a running Datasphere tenant was the same: what happens to what we built? The short answer is reassuring; the interesting part is what you should stop building.

The one-sentence takeaway: your Datasphere investment survives — but hand-built replication flows are now technical debt with an expiry date.

What stays

Datasphere does not disappear. It continues as the modelling and integration layer inside BDC:

• Spaces and models carry over. Your semantic models, views, and data flows keep working — BDC consumes them rather than replacing them.
• SAP Analytics Cloud stays as the visualisation layer, now bundled instead of separately contracted.
• Skills stay valuable. People who can model in Datasphere are exactly the people who will wire data products to business questions in BDC.

If you invested in Datasphere over the past years, none of that was wasted. This is the difference between an evolution and the platform funerals SAP customers have attended before (we said the same about Sales Cloud V1 to V2: rebuilds are honest, renames are not — BDC is closer to a rebuild of the packaging around a surviving core).

What changes

Three things are genuinely different:

1. Packaging and licensing. One BDC contract in capacity units covers Datasphere, SAP Analytics Cloud, and the embedded Databricks engine. The era of negotiating three SAP data products separately ends at your next renewal.
2. Data products replace hand-built extraction. Where SAP ships a data product — S/4HANA finance, Sales Cloud V2 pipeline, SuccessFactors — the replication flow your team built for the same data becomes legacy. SAP maintains the data product through releases; nobody maintains your custom flow but you.
3. Machine learning moves inside the fence. Workloads that used to require copying SAP data out to a separate ML platform now run in embedded Databricks, under the same governance. For anyone who has sat through a data-protection review of a shadow analytics platform, this is the quiet headline. Under Swiss nDSG and GDPR, “the data never left SAP governance” is a sentence your DPO will enjoy saying.

What to stop building

Concretely, as of this year:

• Stop building new replication flows for data SAP ships as a data product. Check the catalogue first; build only for the gaps.
• Stop modelling generic entities from scratch. “Customer”, “sales order”, “invoice” arrive semantically modelled. Your modelling effort belongs in the last mile — your industry logic and KPIs — not the first.
• Stop treating S/4HANA and CX analytics as separate projects. On the integrated stack, one foundation serves both. Splitting them recreates the disagreeing-numbers problem BDC exists to end.

The renewal conversation

Time your move commercially. If your Datasphere or SAC contract renews in the next 12 months, negotiate the BDC conversion at renewal — that is when SAP is flexible. Bring your consumption history: capacity-unit sizing rewards customers who know their actual usage rather than accepting the default t-shirt size.

And keep the scope honest. The right first BDC step after conversion is not a platform migration project — it is one domain, one set of data products, one insight app that answers a question your management already asks. The platform work follows demand, never the other way round.