Part 7 of 7 · Series index · ← Deploying to Datasphere
SAP already ships a way to bring SAP BW into the Business Data Cloud. So the fair question is: why build anything? The short answer is that SAP’s path and our tool do two different jobs — SAP’s moves your data, ours rebuilds your model — and they’re better together than either is alone. And the way ours is built brings advantages of its own: a metadata-only security surface, determinism that scales, and a model you can reuse anywhere. This post is the honest map of how the pieces fit, and why the architecture earns its keep.
If you’ve read the first six parts, you know what we built: a tool that reads the modelling already sitting in SAP BW and regenerates it as a ready-to-use SAP Datasphere model, deterministically and without ever handing a password to an AI. Since we started our Data Warehouse cloud journey, the ground shifted underneath the destination — “Datasphere” is now sold as part of SAP Business Data Cloud — and SAP shipped its own tooling for the BW-to-cloud journey. That’s not a problem for us; it’s a clarification. This post walks through what BDC changed, what SAP’s own on-ramp does, and the one leg of the trip our tool was built for.
What BDC changed
From the start of 2026, SAP stopped offering SAP Datasphere and SAP Analytics Cloud as standalone subscriptions for new bookings and renewals. They now arrive bundled, under one license, as SAP Business Data Cloud (BDC)¹ — a packaged SaaS solution that runs on top of SAP Business Technology Platform rather than as a service you provision yourself. Datasphere didn’t go away; it became a component of a larger offering. BDC also ships SAP-managed data products² — curated, SAP-maintained datasets delivered straight from applications like S/4HANA (built on ABAP CDS views) and ready to combine with your own. Those are the standard content SAP keeps current for you; everything below is about your custom BW models, which are yours to bring across.
For existing BW customers, SAP frames the move as a three-step journey: Lift, Shift, Innovate. Lift your BW or BW/4HANA system to the private cloud; shift selected data into Datasphere as data products; innovate by gradually replacing custom models with SAP-managed ones. It’s a sensible arc — but what if it isn’t available to you?
SAP’s own on-ramp: the Data Product Generator
The centrepiece of the “Shift” step for SAP BW is SAP’s Data Product Generator (DPG) — available only for Private Cloud Edition systems, i.e. BW that has already been lifted to the cloud. It’s a genuinely useful, fully supported tool. From inside your BW system — transaction RSDPS on BW 7.5, or the Data Subscription app and Scenario Generator on BW/4HANA³ — you pick an InfoProvider, and the DPG replicates its data into the object store of the Datasphere tenant in your BDC formation. The result is a set of delta tables you can expose as Data Products and consume in SAC or share with SAP Databricks for AI and machine-learning work, all without copying the data again.
Two complementary on-ramps from SAP BW into Datasphere within BDC: SAP’s Data Product Generator lands the data as tables, while this tool regenerates the modelling structure — the two meet to form a complete, populated model.
SAP’s Data Product Generator carries your data into Datasphere’s object store as landed tables, ready to publish as Data Products. Our tool carries your modelling — the typed tables, dimension and text and hierarchy views, associations and keys — and deliberately moves no data. The two arrive on the same platform from opposite ends and meet in the middle: structure waiting for data, data waiting for structure.
Two things about that path are worth holding onto. First, it’s deliberately about data and data products — landing the rows and making them shareable. Second, it has a firm prerequisite: lifting BW to the private cloud is required before BW can participate in BDC at all⁴, and it is supported only on recent releases⁵. The DPG is the supported tool for the customer who has already committed to that journey.
Where the two part ways: data versus structure
Here’s the distinction that explains why we built anything. The DPG lands your data as flat tables in the object store, and then — in SAP’s own words — you “use the data builder to create additional Datasphere entities on top of it”. That step, building the semantic model by hand, is exactly the years-of-work nobody wants to suffer through again that Part 1 opened with: the dimension views, the text views, the fiddly hierarchies, the associations and keys that turn a pile of tables into something a person can report on.
That missing leg is the one our tool was built for. It reads BW’s metadata through the two APIs in Part 3, and the generator in Part 4 produces the whole Datasphere structure — the same way every time — while moving no data at all. We say it plainly back in Part 1: the tool generates the structure, not the rows. That isn’t a limitation we apologise for; it’s the precise complement to a tool that moves rows but not structure.
So the line between the two is clean, and worth stating once without hedging: SAP’s Data Product Generator moves your data; our tool rebuilds your model. And because ours only ever reads — metadata, never rows — it runs against the BW you already have, on-premise and before any lift to the private cloud. That is exactly who we built it for: the BW customers who can’t or won’t go Private Cloud Edition yet, but still want their models standing in Datasphere. You don’t have to have started SAP’s journey to start ours. They add up; they don’t compete.
So they add up
Put the two side by side and the scenarios sort themselves out:
- Already lifted and using the DPG. You have BW data landing in the object store as tables. Point our generator at the same concepts and it produces the dimension, text and hierarchy views, the associations and the keys that sit on top — the semantic model you’d otherwise hand-build screen by screen.
- Not yet lifted to private cloud. The DPG isn’t an option until you’ve done the Lift step, but the modelling doesn’t have to wait. Because our tool only needs to read BW metadata, you can stand up — and review, and version — your Datasphere structure now, against the BW you already have, and prototype the target before committing the data path.
- Either way, data stays a separate decision. How the rows finally flow — through the DPG, through replication flows, or through files — is a choice you make independently, exactly as Part 1 intended. One generated structure serves whichever loading approach you pick.
What the architecture buys you — beyond filling a gap
Filling the modelling leg is the headline, but the way the tool is built carries advantages of its own — the same ones the earlier parts kept circling back to. Three are worth naming as reasons to reach for this approach even once you’re inside BDC.
Security — a metadata-only blast radius. Because the tool reads metadata and regenerates structure, your actual business data never travels through it. There’s no landing zone to secure, no copy of sensitive rows in flight, no extract left on a disk. Layer on the rules from Part 2 and Part 3 — credentials only ever in memory, a connector that is read-only by construction, a UI with no route to the internet — and the worst case is the exposure of the shape of your cost centers, never the figures inside them. A data-movement path can be made perfectly safe too, but it necessarily takes on a data-security surface that a structure-only tool simply never has.
Scalability — by determinism, not by effort. The generator is a pure function: tidy metadata in, the same model out, every time (Part 4). So it scales the way good machinery does — run it over one concept or a hundred, today or next quarter, and the cost per model stays flat and the result stays identical. There’s no manual retyping that grows with the backlog, and no AI variance to reconcile run to run. The work scales by repetition; the only deliberately human moment is the review gate.
Reusability — one model, many destinations; one generator, many customers. The output is deliberately decoupled from how data is loaded, so a single generated structure serves the Data Product Generator, replication flows, or file loads equally (Part 1). Naming conventions live in configuration rather than in code, so the same generator serves customers with different house styles without a line changing (Part 4). The known-good exports that scaffold the output double as its tests, and the connector’s standard MCP surface (Part 3) is ready to be reused by an AI assistant later — without ever putting a credential within its reach.
Underneath all three sits auditability: because every run is deterministic and reproducible, you can diff two versions, prove exactly how a model was produced, and re-run it without holding your breath — the property a migration of a reporting foundation needs, and an improvised one can never offer.
What we’re not claiming
To be clear, because it matters: we are not replacing SAP’s path, and we are not competing with the Data Product Generator. If your destination is a fully SAP-managed, RISE-based landscape running on SAP’s own data products, that supported route is the destination, and the DPG is the right tool for the data. What our tool offers is a faster, deterministic, credential-safe way through the one leg SAP’s data tooling deliberately leaves to you — the modelling — and the freedom to walk that leg before the rest of the journey is booked. Complementary, not a contest.
Lessons learned
- Read the platform’s own roadmap before positioning your tool. “Lift, Shift, Innovate” told us exactly which leg was already covered and which was left open.
- Data and structure are separate problems — and separable tools. Moving rows and rebuilding a model are different jobs; conflating them is how you end up competing where you should complement.
- A prerequisite is a market. SAP’s path needs the lift to private cloud first; the customers who haven’t taken that step still have modelling they’d like to move.
- Be honest about the boundary. Saying clearly what a tool doesn’t do — here, move data or replace the supported route — is what makes the claim about what it does worth trusting.
- The same choices that make a tool safe can make it scale. Metadata-only, deterministic, config-driven: one set of decisions bought security, scalability, reusability, and auditability at once.
Wrap-up
Over seven parts we’ve gone from a problem — years of SAP BW modelling nobody wants to suffer through again — to a working tool that reads it, rebuilds it, and deploys it, and finally to where that tool sits in the world SAP is actually building. Business Data Cloud is the destination; SAP’s Data Product Generator carries the data there; our tool carries the model. Pick the leg you need. And if you only remember one thing: this was never about doing SAP’s job differently — it was about doing the part SAP leaves to you, faster and the same way every time.
Thanks for reading. Start over at the series index, or revisit where it began.
Related ZPARTNER reading
- Road2BDC — our way to SAP Business Data Cloud with SAP Analytics Cloud and SAP Datasphere
- SAP BW und Business Data Cloud: jetzt umsteigen oder noch warten?
- End-to-end data model in Datasphere and SAP Analytics Cloud — how to leverage the Business Content
Part 7 of 7 · Series index · ← Deploying to Datasphere
