The Same Six QuestionsComing Up in Every SAP BW Migration
1. "How much of our BW landscape do we actually need?"
This is the question with perhaps the highest financial impact, and one of the most uncomfortable to answer.
Because answering it means acknowledging that a significant part of what was built over the last 10 to 20 years may no longer serve a purpose.
In every BW environment we have mapped, a substantial share of objects turned out to be dormant or barely used. Queries that have not been accessed in a full fiscal year. DataStore Objects orphaned by reports retired years ago. MultiProviders superseded and never removed.
Across large, grown SAP BW landscapes, it is not unusual to find 40–70% of objects with little or no recent usage.
On-premises, this may not immediately affect the infrastructure bill because costs are largely fixed. In a cloud environment however, it matters much more. Every migrated object can consume storage, compute, and operational capacity whether anyone uses it or not.
That means carrying legacy redundancy into a consumption-based cloud model does not just add migration effort. It can create a recurring cost that continues long after the project is finished.
The cheapest object to migrate is the one you confidently decide not to.
2. "What happens to all the ABAP code?"
This is where the technical conversation really starts, and where the gap between a smooth migration and a painful one often opens up.
ABAP routines in BW transformations, including start routines, end routines, and field-level rules, encode business logic that turns raw data into the numbers people use to make decisions.
That logic cannot simply be lifted and dropped into a modern target architecture. Depending on the target, it may need to be translated into SQL, PySpark, Python, or another form of transformation logic.
And that is where the real challenge begins.
Every routine needs to be understood, connected to the business logic it implements, and then rebuilt in a way that preserves the intended result.
Done manually, this can be slow and expensive. A common rule of thumb puts ABAP translation costs at roughly €20 per code line, and a typical BW landscape can contain a lot of lines.
But the deeper problem is not the translation cost. It is what gets lost in translation.
If you translate ABAP syntax without understanding the business intent behind it, you can produce code that runs perfectly but produces the wrong numbers.
Nobody notices until the CFO asks why the KPI no longer matches.
The distinction between translating syntax and translating meaning is the difference between preserving your KPIs and silently changing them.
3. "Can't we just copy everything into Snowflake?"
This one also comes up more often than you might expect. And the answer is more nuanced than a simple yes or no.
A blind copy is risky for reasons that go beyond technical architecture. Modern cloud platforms are designed around different data models and processing paradigms than the highly structured, pre-aggregated world BW was built for.
But there are also two traps that catch migration teams off guard.
First: ODP.
SAP’s Operational Data Provisioning framework has historically been a key mechanism for extracting data from SAP environments. As organizations move toward modern, non-SAP cloud architectures, existing ODP-based extraction patterns may need to be reassessed and redesigned around approaches such as CDS views and modern APIs.
That effort is often underestimated or simply missing from the original migration budget.
Second: SAP licensing.
SAP’s digital access model can trigger fees when SAP-generated data is read by or copied to a non-SAP system. The volume of data you replicate outside SAP directly affects your exposure. This is a significant hidden cost that does not appear in most migration project plans.
Both risks are manageable. But only if they are considered early.
This is another reason why rationalizing and selectively migrating high-value data matters. The question is not simply “How do we move our BW data?” but “Which data should move, where should it live, and what will it cost us to operate there?”
4. "Which platform should we pick?"
This is the question that consumes the most meeting time relative to its actual impact on project success.
BW/4HANA, SAP Datasphere, SAP Business Data Cloud, Snowflake, Databricks, Microsoft Fabric – they are all viable target platforms. Most organizations end up with a hybrid, which is honestly the most common architecture in practice: SAP-adjacent processes stay in the SAP ecosystem while analytical and AI-heavy workloads run on open platforms.
What matters more than the platform is whether the business logic you migrate is captured in platform-independent terms. When it is, the choice of destination becomes a deployment decision. When it is not, switching platforms later means rebuilding from scratch.
Too often, teams spend months on platform evaluation and days on governance planning. The sequence should be the other way around.
5. "Why are we talking about AI in a migration project?"
Because AI models and agents are only as reliable as the data they consume, and the migration is the single best opportunity most organizations will have to fix that data.
BARC’s 2026 Trend Monitor confirms the priority order: data quality management leads the enterprise priority list at 7.9 out of 10. Data warehouse modernization sits at 6.1. Generative AI at 5.5. Agentic AI at 4.5. The industry knows what comes first. The question is whether organizations act on that knowledge before the migration or discover it afterward.
ISG research points to the same underlying dependency: the value organizations expect from AI after an SAP migration depends on well-governed data and on integrating SAP with non-SAP sources. A migration that produces governed data products, assets with defined meaning, clear ownership, traceable lineage, and enforced quality contracts, is not just a faster migration. It creates the foundation that every AI initiative downstream depends on.
6. "Where do migrations actually go wrong?"
Not where most people expect. The five most common mistakes are made in the planning phase, not during technical execution.
- Migrating without reducing the scope, so 40 to 70 percent of unused objects are carried forward at full cost.
- Deferring ABAP logic translation until “later”, only to discover at go-live that KPIs no longer match.
- Choosing a target platform without a data strategy, resulting in something technically elegant but misaligned with the business.
- Planning migration waves around technical dependencies rather than business value, making it harder to maintain stakeholder support.
- Launching without a governance operating model, recreating the same transparency problems in the cloud, just at a higher cost.
Every one of these is avoidable. But only if you ask the right questions early enough.
What’s next?
These are the patterns we see again and again. Our team has spent the better part of the last year compiling everything we have learned across these projects, from strategic questions and the technical traps to the ABAP challenges, platform trade-offs, governance decisions, and cost pitfalls, into a single structured resource.
If you are planning a migration, already in the middle of one, or questioning your current approach, this may be worth a look: SAP BW Migration, Explained.
We will keep updating it as we learn more. Because in our experience, the teams that ask the best questions before the migration are the ones that navigate it with the fewest surprises.
Ready to go beyond the questions?
Our new Intelligent SAP BW Migration → paper shows how a meaning-first approach can take you from landscape assessment and scope reduction through ABAP translation, governance, and target design.