„How do I migrate my BW objects to Datasphere one to one?“ It is the question we get most often, and it is often the wrong one. SAP Datasphere is a different animal. It is not an SAP BW living in the cloud. This post walks through why the 1:1 instinct is so natural (I felt it too), where it quietly traps you, and why I have moved away from it over time. Two better questions are worth asking:
- what does the new architecture allow us to do?
- what added value can we generate from the move?
From „how do I lift my BW?“ to „what can we finally do now?“: the same data, a very different set of options.
Almost every conversation about moving off SAP BW starts the same way. A customer has years of investment in InfoObjects, ADSOs, transformations and process chains, and the very reasonable wish is to carry all of it across untouched. So the first question is: how do I migrate my BW to Datasphere one to one?
I understand the instinct completely, and nobody wants to redo years of work. So let me be clear up front: the BW you built was the right tool for its time, and the skills you acquired on it are exactly what will make this next step go well. None of that investment is wasted; we are just going to spend it differently.
After some of these projects, my honest answer has become for many objects, a 1:1 migration is the wrong goal. Increasingly, my recommendation drifts toward doing 1:1 migrations only strategically for specific metadata, and metadata only. SAP itself positions Datasphere as the strategic successor to BW, while being clear that it is not a direct one-to-one replacement, because the two differ fundamentally in how they work.1 Go the full 1:1 route and you will recreate the very problems you set out to leave behind. The better questions are the ones that unlock the reasons to move at all: added functionality, easier setup for an ever growing number of (cloud) sources, and new possibilities opening up in the cloud.
The honest first stop: you can lift it (maybe)
We should be fair to the 1:1 instinct, because SAP does give you a near-1:1 path. With SAP BW bridge and a shell conversion, you transfer the metadata of your BW objects (InfoObjects, DSOs, CompositeProviders) into the bridge, which recreates them as empty object shells in the cloud and reloads data afterwards.2 It works. Object types even get modernised on the way: classic DSOs and InfoCubes become ADSOs, InfoPackages become DTPs.2
From my perspective it is a trap. A shell conversion faithfully reproduces the model you already have, including the parts that existed only to work around BW’s limitations and overcome concepts. It will also faithfully reproduce architectures you have long outgrown and design patterns that only ever made sense under BW’s old constraints. Even SAP’s own conversion guidance frames the bridge as a chance to redesign, not to freeze yesterday’s design in a newer place.2 If you lift everything one to one, you inherit ten layers of persistence, the lookups you built because joins were expensive or impossible within the limits of classic ABAP SQL, and the routines you wrote because the database would not let you do it the clean way. You arrive in the cloud still carrying every workaround collected over the years, winded from the climb, instead of finally setting that weight down. The bridge is a genuinely useful tool for the data flows that should stay as they are; for the whole landscape it makes a poor default. Monty Python fans will indulge me here: the Bridgekeeper on the Bridge of Death waves across only those who travel light and answer their questions well. So the way forward I recommend is the unladen swallow. Carry over only the metadata that earns the trip, leave the years of baggage on the near bank, and the crossing turns out quick, light, and entirely free of any Gorge of Eternal Peril 😉
So this is not about throwing your landscape away. It is about choosing, deliberately, what deserves to come with you, and that turns out to be a more rewarding job than it sounds.
A different animal, not a faster BW
The deepest difference between BW and Datasphere is conceptual, not technical. BW is a system that executes business logic: ABAP routines, exits, planning functions and process chains actively calculate key figures, distribute values and run accruals. Datasphere deliberately steps back from that role. Modelling here means representing structure, relationships and semantics, then letting the HANA Cloud engine underneath do the heavy lifting, with federation and virtualisation as a first-class strength rather than an afterthought.3
BW executes business logic at runtime; Datasphere models meaning and lets HANA Cloud do the lifting.
That massive shift is why a 1:1 copy makes little to no sense. Half of what your BW model is consists of machinery for executing logic, staging data, and leaning on existing libraries such as function modules and classes that do not, and will never, exist in Datasphere. A lot of very useful, tried-and-true constructs from SAP BW are handled differently in Datasphere, or are no longer needed at all. Move only the machinery and you miss most of the upside. Move the meaning, the entities, relationships and definitions, and rebuild the rest the way the new platform wants, and the system gets simpler and faster almost effortlessly, as a side effect.
The pain we are glad to leave behind
This is where the move stops being abstract, because some of BW’s daily frustrations simply disappear.
The one I personally will miss least is the crippled Open / ABAP SQL. In a classic BW transformation, real logic meant an ABAP routine combined with a subset of SQL that made me sad. I know where it comes from: a subset that worked with pretty much any database made a lot of sense at the time. But that time is long gone, and it should have been retired with BW/4HANA. When SAP later let transformations push down to HANA, the door opened only partly. Pushdown requires writing field, start, end and expert routines as AMDP (ABAP Managed Database Procedures) in SQLScript; the formula editor accepts only SAP-delivered functions, or additional ones wedged in awkwardly; transformations with rule groups can run only in ABAP; and the moment you use a single ABAP routine, the whole transformation drops back to ABAP-only runtime and loses its pushdown.4 Anyone who also worked on the HANA side felt this gap keenly. You could feel the power of the engine underneath, but the framework only let you reach it through the controls of an older car: reliable and well-built, just not made for this speed. It kept a polite but firm hand between you and the throttle.
In Datasphere, a graphical view is drag and drop for the people who want it, and a SQL view is just HANA SQL.5 Whoever asks me will get the same answer: use SQL views whenever you can. Finally, some freedom 😉 You can paste in the statement you already have, use the full dialect, and skip the AMDP scaffolding entirely. Even without a full AI integration, you can drop the SQL into a chat window and ask for an error analysis or a hand getting the syntax right. After years of redrawing logic in form-based editors in the SAP GUI, and in the Eclipse BW modelling tools where the transformation editor had a habit of drawing connection lines into nowhere, being able to copy and paste a working SQL view feels less like a feature and more like a release. I will not pretend I will miss that view. And that is before we even get to pushing the CSN into Git for proper versioning (one can dream).
The second relief is associations instead of hard-wired lookups. In BW, giving a fact its context usually meant a lookup or a join that loaded and joined everything up front, whether or not a given query needed it. A Datasphere association is a semantic relationship that is resolved only when a query actually asks for it at runtime, with the engine pruning away all the clutter, the dimensions the current drill-down does not touch.6 You model the relationship once and the runtime decides what to pay for, rather than paying for all of it on every run. For anyone who has watched a BW query crawl through lookups it never needed, this is the difference between modelling intent and hand-optimising plumbing.
Persistence with a scalpel, not as a reflex
BW’s LSA taught a generation of us to persist data at every layer: acquisition, propagation, harmonisation, reporting, each one a set of ADSOs paid for in HANA memory. It was a reflex, and it was expensive.
Not ten ADSO layers by habit, but storage placed where a query actually needs it.
Datasphere lets you trade that reflex for a conscious decision, because federation and remote tables let you leave data where it lives and access it virtually (with the trade-off that performance can suffer, so you need to know when and where to use it). Redundant copies stop being the default.7 When you do need to materialise something for performance, view persistence stores a view’s result in a HANA persistency table, so the runtime reads it instead of recomputing the whole graph each time.8 The shift is the point: not ten layers of expensive ADSOs by habit, but one or two persisted views or local tables, filled by transformation flows and placed exactly where a query needs them. Persistence becomes a fine-tuned scalpel, not a reflex. You pay for storage where it buys you speed, and nowhere else. The object store compounds this nicely and lets you have your cake and eat it too: keep the big, cooler data in the Delta-format object store (Parquet files with a transaction log) at performance that is still fine for many scenarios, and bring your most important data into local in-memory tables for blazing-fast reporting when the model is built right.9
Moving with the source, not re-staging it
Where BW leaned on its own extractors and staged everything inbound, Datasphere moves closer to where the data is born. For S/4HANA, the CDS view is the premium, first-class source. Delta arrives through trigger-based Change Data Capture, so consumers receive only what changed, via Replication Flows as SAP’s preferred path for bringing ABAP data across.10 If no standard CDS view for extraction exists, you have a lean option to build your own, and with ABAP CDS syntax (sadly, again, not the full HANA power) you can prepare the data in ways that were rather hard in the old extractors. On the monitoring side you are not flying blind: the CDC monitor DHCDCMON tracks the delta logging tables, DHRDBMON shows buffer-table status, and DHADM covers initial-load partitioning and access-plan calculation.11 Looking forward, data products bundle all of this into governed, reusable units of data, with the Data Product Studio in SAP Business Data Cloud positioned as the place to build and manage them, managed by Foundation Services and stored in an SAP-managed object store.12
CDS views plus Change Data Capture move only what changed, into a model that is yours.
The practical effect for an architect is that you stop rebuilding the source’s logic inside your warehouse. You consume a CDS view or a data product that already carries the right semantics, and you spend your effort on the model that is genuinely yours.
Less grind, with new disciplines to learn
It would be dishonest and wholly unrealistic to claim maintenance vanishes, so let me be precise. A lot of the old pains are gone. As a SaaS platform Datasphere removes database and Basis upgrades, and the cloud model retires the aggregates, indexes and accelerator tuning that used to fill the calendar. Fewer persisted layers means fewer things to load, monitor and reconcile, and brittle process-chain choreography gives way to simpler and shorter flows. So why migrate any of that?
In exchange, new disciplines arrive. Spaces and connections need governing, and they also simplify access control. Federated queries need tuning, so a convenient virtual model does not quietly become a slow one. Consumption-based resources put a real premium on designing well: the gap between a good, fine-tuned SQL statement and a bad one can be massive, and now it is also directly billable. The maintenance burden does not disappear so much as move up the stack, from babysitting infrastructure to curating a model and its costs. For most teams that is a far better trade, though it does come with a steep learning curve, so it is not quite a free lunch. On on-premise BW, a badly modelled flow mostly costs you time and compute; in Datasphere it shows up on the bill more directly, which is really just a good incentive to model with care.
A bigger toolbox, and the door to other architectures
Two more things open up once you stop thinking of Datasphere as BW.
The toolbox gets bigger. Because HANA Cloud sits underneath, you are no longer limited to the analytics primitives BW exposed. SQL and graphical views, imported calculation views with their semantics intact, plus spatial, graph, JSON and vector capabilities are all on the table for the problems that need them.13 Adding non-SAP cloud sources stops being a project of its own, too. Datasphere ships native connections for Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage, BigQuery and more, as federated sources or replication targets.14 The lake you already have becomes something you can reach, not something you have to re-host.
And new architectures become reachable: data mesh through spaces, a business data fabric across a distributed landscape, hybrid setups where BW/4HANA, Datasphere and SAC each play to their strength, and lakehouse patterns with partners under Business Data Cloud.3 None of these have a clean equivalent in a classic BW world. They are available precisely because Datasphere is built on different assumptions. Add Databricks, Snowflake and the like, and you open up a whole new world of options, from machine learning to big data and beyond.
The better questions to bring to the project
If there is one thing to take away, it is to retire the migration-shaped question. „How do I move my whole BW one to one?“ optimises for changing as little as possible, which is the opposite of why you are moving and what you should want.
Ask instead:
- which of our models exist only to work around BW, and can therefore be simplified, modified or dropped altogether?
- where does federation let us stop copying data, and where is a single persisted view worth more than a layer of them?
- which logic belongs at the source as a CDS view or a data product, rather than restaged in the warehouse?
- what could we build now, with the bigger toolbox and the open connections, that BW simply could not?
Datasphere is not the new BW, and from my perspective that is good news. In Germany we say alte Zöpfe abschneiden, to cut off the old braids, and I would gently encourage you to do exactly that wherever it is possible and where it makes sense. And if you have spent years inside BW, take heart: you already know your data better than any tool ever will, and that knowledge is the one thing that carries across one to one. Treat the move as a chance to put down weight you have carried for years, keep the things that genuinely earn their place, and finally spend that hard-won expertise on the value the old architecture never let you reach.
Related ZPARTNER reading
- How SAP Data Warehouse Cloud (DWC) consumes SAP HANA calculation views
- ZPARTNER blogs on SAP Analytics
References
- SAP positions Datasphere as the strategic successor to SAP BW/4HANA while stating it is not a one-to-one replacement, given the architectural differences. SAP Learning, „Differentiating SAP BW and SAP Datasphere.“
- Shell conversion transfers BW object metadata into SAP BW bridge as empty shells (data reloaded afterwards) and modernises object types (classic DSOs/InfoCubes to ADSOs, InfoPackages to DTPs), and is framed as an opportunity to redesign rather than copy 1:1. SAP, „Shell Conversion Guide for SAP Datasphere, SAP BW bridge.“
- BW executes business logic (ABAP routines, exits, planning), whereas Datasphere models structure, relationships and semantics, with federation/virtualisation as a primary strength, enabling data fabric and data mesh architectures. SAP Learning, „Differentiating SAP BW and SAP Datasphere.“
- BW transformations push down to HANA only via AMDP/SQLScript routines; the formula editor allows only SAP-delivered functions, rule groups force ABAP-only execution, and using any ABAP routine reverts the transformation to ABAP-only runtime. ABAP Open SQL is itself a subset of the DML scope of supported databases, by design. SAP Help Portal, „HANA Transformations / AMDP Routines.“
- SAP Datasphere supports graphical views (drag and drop) and SQL views written directly in HANA SQL / SQL Script. SAP Help Portal, „Creating a Graphical View“ / „Creating an SQL View.“
- Associations define a semantic relationship that is resolved only when a query requires it, with data pruning loading only the dimensions a given drill-down needs, in contrast to hard joins that always load and join. SAP Learning, „Working with Analytic Models“ (SAP Datasphere).
- Remote tables federate data, leaving it in the source and accessing it remotely in real time without redundant copies; replication is an optional choice for performance. SAP Help Portal, „Replicate Remote Table Data.“
- View persistence stores a view’s result set in a persistency table in SAP HANA Cloud so the runtime reads stored data instead of recalculating the view on every access. SAP Help Portal, „Persisting and Monitoring Views.“
- In SAP Datasphere and Business Data Cloud, file-type local tables and data products are held in the object store on SAP HANA Cloud Data Lake Files in Delta format (Parquet files plus a Delta transaction log); in-memory local tables serve hot data for fast reporting. SAP Help Portal, „Creating a Local Table (File)“ (SAP Datasphere object store).
- ABAP CDS views are the first-class S/4HANA source; Change Data Capture provides trigger-based delta, and Replication Flows are SAP’s preferred mechanism for bringing ABAP data into Datasphere. SAP Help Portal, „Replication Flow for CDS views from S/4HANA On-Premise to SAP Datasphere.“
- For ABAP/CDS replication the monitoring transactions split by purpose: DHCDCMON is the CDC monitor (delta logging tables, triggers, subscriptions), DHRDBMON shows buffer-table status, and DHADM covers initial-load partitioning and access-plan calculation. SAP Help Portal, Datasphere ABAP replication monitoring.
- SAP Business Data Cloud unifies Datasphere, SAC and curated content; data products are governed reusable data units built and managed in Data Product Studio (GA H1 2026), managed by Foundation Services and stored in the SAP-managed object store. SAP Learning, „Explaining Foundation Services and Data Products.“
- Running on SAP HANA Cloud, Datasphere exposes SQL and graphical views, imported calculation views with semantics preserved, and multi-model capabilities including spatial, graph, JSON and vector. SAP News, „Unifying AI Workloads: SAP HANA Cloud, One Database.“
- SAP Datasphere provides connections to cloud object stores and warehouses including Amazon S3, Azure Data Lake Storage Gen2, Google Cloud Storage and BigQuery, as federated sources or replication targets. SAP Help Portal, „Microsoft Azure Data Lake Store Gen2 Connections.“
