This is Part 6 of our SAP Business Data Cloud for Data Engineers series. In Parts 1 to 5 we covered what BDC is, the architecture, Databricks integration, Data Product design, and Azure integration. Now we tackle the question every organisation faces when BDC appears on the agenda — do we migrate, and if so, how?
The question nobody answers honestly
Every vendor presentation about SAP Business Data Cloud shows the same slide. Your current state is a mess of disconnected systems, fragile pipelines, and governance gaps. The future state is a clean unified BDC platform where data flows seamlessly, AI works perfectly, and business users are happy.
The slide does not show you how long the journey between those two states takes. It does not show you what happens to your existing SAP BW investment. It does not tell you which parts of your current Azure and Databricks stack you actually need to replace versus which parts continue working alongside BDC. And it definitely does not tell you what happens if you get the migration sequencing wrong.
This post does all of those things. Based on real migration projects in 2026 — not vendor presentations.
Marie’s RetailCo project moved from a standalone SAC and Azure implementation to a full BDC architecture over eight months. The migration decisions the team made — some right, some wrong — form the backbone of what follows.
First — understand what you are actually migrating from
The migration question looks different depending on your starting point. There are four common starting points in 2026 and each has a different recommended path to BDC.
Starting point 1 — SAP BW on-premise
BW 7.5 mainstream maintenance ends in 2027. Private Cloud Edition extends that runway to 2030 — but that is barely four years away, and four years moves fast when you are carrying years of accumulated business logic, custom transformations, and deeply embedded reporting dependencies. (SAP Community)
If you are running SAP BW on-premise you are not choosing between migrating and not migrating. You are choosing between different migration paths and different timelines. The maintenance deadline makes staying where you are increasingly untenable.
Starting point 2 — SAP BW/4HANA on-premise or PCE
More modern than classic BW but still facing the same strategic direction question. SAP BW/4HANA PCE systems can remain as data sources and be gradually transitioned into the BDC architecture — using BDC as the foundation for advanced analytics, generative AI, and an open multi-cloud strategy. This is the most common starting point for organisations already on the cloud journey. (Pikon)
Starting point 3 — SAC standalone without Datasphere
SAC’s dual-storage model is in active transition. Organisations that delay their BDC readiness risk broken analytics pipelines as SAP migrates the underlying architecture. If you implemented SAC without Datasphere in the last two or three years — BDC migration is less a choice and more an architectural inevitability as SAP transitions SAC’s storage layer to Datasphere. (SAVIC Technologies)
Starting point 4 — Modern cloud data stack alongside SAP
Azure plus Databricks plus SAC, or Azure plus Power BI with SAP data extracted into a lakehouse. This is Marie’s starting point. The migration question here is not replacing your existing stack but integrating BDC alongside it in the right architectural pattern.
The three BW migration paths — and the honest trade-offs
The optimal path depends on factors such as the size and complexity of the existing BW, the volume of custom development, the level of transformation considered, and the number of existing and additional systems to be integrated. (Acbaltica)
Path 1 — Lift, Shift and Innovate
Lift, shift and innovate refers to the gradual transformation of legacy BW systems through migration to the cloud. The current BW system is migrated to BW Private Cloud Edition. BW is not changed and lifted as is. (Acbaltica)
In plain English — you move your BW system to SAP’s managed cloud without changing anything. Same models, same transformations, same logic. SAP manages the infrastructure. You stop worrying about servers and patching.
Then gradually — over months or years — you use the BW Data Product Generator to convert BW objects into BDC Data Products. You do not do it all at once. You start with the highest-value BW content, convert it, validate it, retire the BW version. Repeat until BW is empty and decommissioned.
The BW Data Product Generator, available since early 2025, migrates classic BW models into the BDC environment, transforming SAP BW and SAP BW/4HANA platforms into a modern data product architecture while preserving existing business logic. (BARC)
The trade-off — this is the lowest risk path and the slowest path. You are running two systems simultaneously during the transition. You are paying for both. The transition could take two to four years for complex BW landscapes.
Best for — organisations with large, complex BW landscapes where the risk of rapid migration outweighs the cost of running parallel systems.
Path 2 — Selective Migration
You analyse your BW content and divide it into three buckets.
Bucket one — content that maps cleanly to SAP-delivered BDC Data Products. Migrate this first using the BW Data Product Generator. Financial reporting content that maps to the Financial Statement Data Product. HR analytics that maps to the Headcount Data Product. These migrations are low risk because the target state is well-defined by SAP’s standard content.
Bucket two — custom BW content with significant business logic that has no direct BDC equivalent. Rebuild this as Customer Data Products in the Data Product Studio. This takes longer but results in modern governed Data Products rather than converted legacy objects.
Bucket three — BW content that nobody uses anymore. Decommission without migrating. Every BW landscape has this content — models built for a requirement that changed, reports that stopped being used three years ago, transformations that feed datasets nobody queries. Discovery workshops almost always reveal that 20 to 30 percent of BW content falls into this bucket.
Best for — organisations with medium complexity BW landscapes who want to use the BDC migration as an opportunity to modernise their data architecture rather than just lift and shift legacy content into a new platform.
Path 3 — Full Redesign
Start fresh in BDC. Connect your SAP source systems to BDC natively. Install SAP-delivered Data Products for your business processes. Build Customer Data Products for organisation-specific requirements. Retire BW entirely without migrating its content.
The Spark Engine enables custom coding options to replace existing ABAP code. For BW content that was built on custom ABAP transformations — the redesign path replaces that ABAP with Spark-based transformation logic in SAP Databricks or Databricks Enterprise. More maintainable, more scalable, no SAP-specific language dependency. (Sap)
The trade-off — highest risk, fastest result if successful, requires strong governance to prevent scope creep. Without careful management the full redesign becomes a multi-year programme that delivers value late and costs significantly more than estimated.
Best for — organisations with relatively simple BW landscapes, organisations starting S/4HANA migration simultaneously where existing BW content will need rebuilding anyway, and organisations with strong data engineering teams comfortable with the blank-canvas approach.
The migration decision matrix
Before choosing a path answer these six questions honestly. The answers determine your path more reliably than any vendor recommendation.
Question 1 — How complex is your existing BW landscape?
Count your InfoProviders, DSOs, transformation routines, and process chains. A BW landscape with 50 InfoProviders and 200 transformation routines is genuinely different from one with 500 InfoProviders and 2000 transformation routines. Complexity determines how much the BW Data Product Generator can automate versus how much manual rebuild is required.
Question 2 — How much custom ABAP transformation logic exists?
Standard BW transformations with minimal custom code migrate more cleanly than heavily customised ABAP logic. If your BW team built significant custom ABAP over years — that logic needs to be understood, documented, and rebuilt rather than converted. Budget time for that discovery and rebuild.
Question 3 — Are you also migrating to S/4HANA?
Many organisations are simultaneously facing a BW migration and an S/4HANA transformation. Without a coordinated roadmap, there is a risk that both initiatives will hinder each other. Analytical structures may be built on legacy ECC tables that need to be redesigned after the S/4HANA migration. (Pikon)
If the answer is yes — coordinate your BDC and S/4HANA migration roadmaps from the start. Building BDC Data Products on top of ECC data structures that will change when S/4HANA goes live creates rework. Build on S/4HANA CDS Views from the beginning even if ECC is still running during the transition period.
Question 4 — What is your existing modern data platform investment?
If you have two years of investment in a Databricks and Azure Data Lake architecture that is working well — BDC does not replace that. It integrates with it. The migration question is not replacing Databricks but extending BDC alongside it using BDC Connect.
Question 5 — What is your AI ambition timeline?
If you are planning your analytics modernisation, S/4HANA migration, or AI rollout in 2026, understanding how BDC fits your architecture is a critical first step. (SAVIC Technologies)
Organisations that want to use Joule AI capabilities on their SAP data in the next 12 months have a stronger reason to accelerate BDC adoption. Joule works best with governed, semantically rich BDC Data Products. The earlier you build that governed data layer, the earlier Joule delivers value.
Question 6 — What is your risk tolerance?
Path 1 is lowest risk, slowest, most expensive to run during transition. Path 3 is highest risk, potentially fastest, lowest long-term cost. Path 2 sits in the middle on all three dimensions. Risk tolerance is an organisational characteristic, not a technical one. Be honest about it before choosing a path.
What BDC does not replace — the honest list
The most valuable thing a data engineer can do for their organisation at the start of a BDC conversation is be clear about what BDC is not replacing.
BDC does not replace your Databricks investment
As covered in Part 3 — Databricks and BDC are partners. BDC Connect enables Databricks to consume SAP Data Products without extraction. Your existing Databricks pipelines, ML models, Unity Catalog configurations, and Delta Lake tables remain. You add BDC as a governed SAP data source alongside your existing Databricks data assets.
BDC does not replace Azure Data Lake for non-SAP data
Your e-commerce data, IoT data, third-party feeds, and custom application data belong in your Azure Data Lake under your governance model. BDC is designed for SAP-origin data where preserving SAP business semantics is the value. Non-SAP data without SAP-specific business context does not benefit from BDC’s semantics preservation — it belongs in your existing data platform.
BDC does not replace Power BI for Microsoft-first users
BusinessObjects BI 2025 continues to be part of a hybrid analytics stack. SAP is realistic about the fact that organisations do not rip out all their reporting tools when they adopt BDC. Users who are deeply embedded in Power BI continue using Power BI — now consuming SAP data via Microsoft Fabric’s BDC Connect integration rather than via a fragile extraction pipeline. (BARC)
BDC does not replace your data governance processes
BDC provides a governance platform — Data Product catalogue, lineage tracking, access controls, quality monitoring. But it does not provide the organisational processes that make governance work. Who owns each Data Product, how changes are approved, how data quality issues are escalated, how SLA breaches are resolved — these are organisational decisions that BDC supports but cannot make for you.
The migration sequencing that works
Based on current BDC implementations the migration sequencing that consistently delivers value earliest while managing risk effectively follows five phases.
Phase 1 — Foundation (months 1 to 3)
Set up the BDC environment. Configure connections to SAP source systems. Install SAP-delivered Data Products for your highest-priority business processes. Set up identity integration with Microsoft Entra ID. Connect BDC to your existing Azure Data Lake via Datasphere Replication Flows.
By the end of Phase 1 you have a working BDC environment with SAP data flowing in via native connections and your existing Azure data accessible via federation. No migration of existing content yet. The foundation is in place.
Phase 2 — Quick wins (months 3 to 6)
Build your first two or three Customer Data Products combining SAP-delivered Data Products with your most valuable non-SAP data. Publish them to BDC’s catalogue. Build the first SAC Stories consuming from BDC Datasphere rather than direct SAP connections.
The goal of Phase 2 is demonstrating value quickly. A unified revenue report combining SAP financial actuals with e-commerce data that previously required a complex pipeline — delivered in weeks rather than months — builds organisational confidence in the BDC approach.
Phase 3 — BW migration (months 6 to 18)
Begin the BW content migration using whichever path fits your landscape. Start with content that maps to SAP-delivered Data Products — these migrations are fastest and lowest risk. Use the BW Data Product Generator for compatible objects. Rebuild complex custom content as Customer Data Products in the Data Product Studio.
Run BW and BDC in parallel during this phase. Validate that BDC Data Products produce identical results to the BW content they are replacing before decommissioning BW objects. Finance teams who have relied on BW content for years will want to see side-by-side comparisons before they trust the new platform.
Phase 4 — Databricks integration (months 6 to 12, parallel with Phase 3)
Connect your Enterprise Databricks workspace to BDC via BDC Connect. Migrate the SAP data extraction pipelines that currently feed your Databricks gold layer — replace them with BDC Data Product consumption via Delta Sharing. Rebuild the ML pipelines that were consuming extracted SAP data to consume BDC Data Products instead.
The pipelines you retire in this phase represent some of your most significant technical debt — fragile extraction jobs, ABAP-to-Python context reconstruction logic, maintenance burden that has been accumulating since you first connected Databricks to SAP. Their retirement is one of the highest-value outcomes of BDC adoption.
Phase 5 — AI and innovation (months 12 onwards)
With governed Data Products in place, Joule configured, and the data foundation trustworthy — start building the AI use cases that motivated the BDC investment. Joule-powered natural language queries on SAP data. Intelligent Applications for supply chain and finance. Agent-to-agent integration between Joule and Microsoft 365 Copilot as that capability matures.
The AI ambitions come last not because they are least important but because they depend on everything that comes before. Joule on poorly governed data gives wrong answers. Joule on well-governed BDC Data Products gives answers that finance directors and supply chain managers act on.
The honest migration risks — and how to manage them
Risk 1 — Scope creep during BW migration
BW migration projects have a well-documented tendency to expand. The initial scope is 200 BW objects. Discovery reveals that 150 of them have downstream dependencies that were not documented. Managing those dependencies adds three months and 40 percent cost to the project.
Mitigation — do a thorough BW content inventory before starting migration. Understand every InfoProvider, every transformation chain, every report that consumes from each object. Use that inventory to prioritise ruthlessly — decommission unused content, migrate critical content, rebuild valuable custom content. The inventory takes two to four weeks but saves significantly more than that during migration.
Risk 2 — Data quality issues discovered during migration
BW content that has been running for years often has data quality issues that nobody noticed because the same errors were consistent across reports — wrong was consistently wrong so comparisons still made sense. When BDC Data Products are built on cleaner data — inconsistencies with existing BW reports appear and finance teams initially interpret them as BDC being wrong rather than BW having been slightly wrong for years.
Mitigation — build reconciliation reports into your UAT process. Run BW and BDC Data Products side by side for at least one complete financial period. Document every difference. Investigate every difference. Most will be genuine data quality improvements. Some will be bugs in the BDC implementation. Fixing them before go-live is significantly less painful than fixing them after.
Risk 3 — Organisational resistance to Data Product ownership
New data platforms change the way people work, redefine responsibilities, and influence decision-making processes. This cultural dimension is often underestimated in technology-driven projects. Pikon
The shift from centralised data engineering owning all data assets to domain teams owning their Data Products is a significant organisational change. Data engineers who have owned the finance data domain for five years do not automatically hand that ownership to the finance team because BDC says domains should own their Data Products.
Mitigation — involve domain teams in Data Product design from the start. Do not present them with a finished Data Product and ask them to take ownership. Have them participate in defining the consumer contract, the SLAs, the quality rules. Ownership that is built through participation is more durable than ownership that is assigned.
Risk 4 — Parallel system costs during transition
Running BW and BDC simultaneously during a migration that takes 12 to 18 months is expensive. Two platform licences. Two sets of infrastructure costs. Two teams maintaining two systems.
Mitigation — set explicit decommissioning milestones for BW objects as their BDC equivalents go live. Do not let BW linger after its content has been migrated. Every BW object that is successfully replaced by a BDC Data Product and validated in production should be retired within 30 days. Discipline on decommissioning is the difference between a migration that reduces long-term costs and one that adds a new platform cost on top of the old one.
The decision framework — should you start BDC migration now?
Three scenarios where starting now is clearly right:
Your BW maintenance deadline creates urgency. BW 7.5 mainstream maintenance ends in 2027. If you are running BW 7.5 you need a plan and 2026 is the year to execute it. Waiting until 2027 to start a 12 to 18 month migration means you will be migrating under deadline pressure with insufficient runway.
Your AI ambitions require governed SAP data. If your organisation is investing in Joule or building AI capabilities that need SAP financial, supply chain, or HR data — BDC is the foundation that makes those AI investments work correctly. Starting BDC now means your AI use cases have trustworthy data in 12 months.
Your SAP data extraction pipelines are becoming a maintenance liability. If your data engineering team is spending significant time maintaining pipelines that extract SAP data, reconstruct business context, and debug synchronisation issues — BDC Connect eliminates that maintenance burden. The ROI is real and measurable.
One scenario where waiting is the right answer:
You are mid-implementation on a major S/4HANA migration that completes in the next 12 months. Starting BDC migration simultaneously creates coordination complexity that neither initiative needs. Complete the S/4HANA migration first. Then build BDC on top of a stable S/4HANA foundation using native CDS View connections rather than building on ECC data structures that will change.
What Part 7 covers
Part 6 gave you the honest migration picture — the starting points, the BW migration paths and trade-offs, the decision matrix, what BDC does not replace, the migration sequencing that works, the real risks and how to manage them, and the decision framework for timing.
Part 7 covers governance and security in depth — the data quality framework, access control design for large organisations, audit and compliance requirements, and the governance decisions that determine whether a BDC implementation becomes a trusted data platform or another data silo with a new name.
The complete BDC for Data Engineers series:
- Part 1 — What is SAP Business Data Cloud? (published)
- Part 2 — BDC Architecture translation guide (published)
- Part 3 — BDC and Databricks (published)
- Part 4 — Data Products design and governance (published)
- Part 5 — BDC and Azure integration (published)
- Part 6 — BDC vs your current stack — honest migration guide (you are here)
- Part 7 — BDC governance and security (coming soon)
- Part 8 — BDC certification guide
Subscribe below to get notified when Part 7 publishes.
Published by the Data Cloud Insights team — SAP data professionals with hands-on implementation experience across Europe.
