Skip to content
SAP2Snowflake Book

Lane 1: the estate

SAP BW to Snowflake migration

Most of the difficulty lies in working out which of fifteen years of accumulated logic still matters, then proving the numbers tie out when you switch.

Book an Assessment Compare migration paths

Why the timing changed

BW exit used to be a strategy conversation. Two things turned it into a scheduling problem. SAP began enforcing Note 3255746 on 9 June 2026, which changed how data legitimately leaves SAP systems and broke a category of extraction pipeline along the way. BW mainstream maintenance then ends in 2027, which sets a limit on how long the current estate can be left alone.

A full BW migration covers assessment, conversion, reconciliation, parallel run and cutover. That takes longer than the time most landscapes have left. Starting the assessment this year leaves room to sequence the work and to change course. Starting in 2027 does not.

What has to move

A BW estate holds six categories of asset, and each one converts on different economics. Treating them as a single lift is how migrations lose control of scope.

InfoProviders
ADSOs, DSOs, InfoCubes, MultiProviders and CompositeProviders. Each maps to a different Snowflake construct, and not all of them should be recreated.
Transformations and DTPs
The business logic. This is the bulk of the work, and the part nobody has documented.
ABAP routines
Start, end, expert and field routines, rewritten as SQL or dbt models against the lineage map.
BEx queries
Restricted and calculated key figures, variables and exceptions. These become a semantic layer rather than a one-to-one rebuild.
Authorizations
Analysis authorizations translate to Snowflake roles, row access policies and masking policies.
Source extraction
The feed itself, which after June 2026 usually needs a new path. Covered on the SAP data page.

Scope, and how usage analysis reduces it

The default plan is to inventory BW and migrate it. That prices the migration off the total object count. The number that matters is smaller: the objects that still feed something a person reads.

Our accelerator extracts the estate metadata, catalogs every object and analyzes read activity across it. The output separates what is live from what is dormant and what is demonstrably dead, on evidence rather than in a workshop where nobody wants to be the person who deletes a report. Scope set this way is usually a fraction of the scope set by inventory alone.

Migration scope set by inventory versus scope set by usage Scoping by inventory prices the migration against every object in the estate. Scoping by usage separates live objects from dormant and dead ones, so only the live portion carries conversion cost. The proportions shown are illustrative; the assessment measures the actual split. SCOPED BY INVENTORY Every object in the estate SCOPED BY USAGE Live Dormant Dead, retire in place
Illustrative. The split between live, dormant and dead objects differs by estate, and the assessment measures yours.

What a BW object becomes

There is no one-to-one equivalent for most BW constructs, which is why a like-for-like rebuild costs more than it should. The mapping below is the starting point we work from.

How BW objects map to Snowflake constructs ADSOs and DSOs become tables or dynamic tables. InfoCubes become tables, often collapsed. MultiProviders and CompositeProviders become views. Transformations and DTPs become dbt models. ABAP routines become SQL inside a dbt model. BEx queries become semantic layer objects. Analysis authorizations become roles and row access policies. SAP BW SNOWFLAKE ADSO / DSO Table or dynamic table InfoCube Table, often collapsed MultiProvider / CompositeProvider View Transformation / DTP dbt model ABAP routine SQL inside a dbt model BEx query Semantic layer object Analysis authorization Role and row access policy
Starting-point mapping. Individual objects vary, and the assessment scores each one.

Reconciliation

The second problem arrives late, which is what makes it expensive. The migration is technically complete, finance finds a variance in a margin figure, and nobody can say whether the new number or the old one is right.

We plan reconciliation from the assessment onward rather than from go-live. The lineage map identifies which figures the reporting depends on. Those are reconciled through a parallel run over real periods, at the grain the business reports on, with variances investigated and signed off before cutover. This work is routine and it decides whether the migration holds.

Where SAP BDC fits

SAP Business Data Cloud is an ingestion layer in this architecture rather than the destination. SAP BDC Connect for Snowflake supports governed, zero-copy sharing into an existing Snowflake account, so SAP data reaches Snowflake on a path SAP endorses. Whether BDC is the right route for your landscape, against CDS views, SLT or database-level replication, is a per-source decision we make during the assessment.

Questions we get asked

› Do we have to move everything in BW?
No, and you should not. BW estates accumulate objects that no longer feed anything anyone reads. Usage analysis separates the live estate from the inactive tail before scope is set, which is the largest single lever on migration cost.
› What happens to our ABAP routines?
They are rewritten as SQL or dbt models. Our accelerator maps each routine to the objects it feeds, so the rewrite starts from a specification rather than an investigation. Consultants do the conversion with tooling assistance. We do not claim a one-click translator.
› How do you prove the numbers still tie out?
Parallel run. BW and Snowflake produce the same figures over the same periods, reconciled at the level your business reports on, with variances investigated before cutover rather than after.
› Is SAP Business Data Cloud a competitor to Snowflake here?
Not in this architecture. SAP BDC Connect for Snowflake supports governed, zero-copy sharing between SAP and an existing Snowflake account. We use BDC as an ingestion layer where it is the right path, with Snowflake as the destination.
› Should we go to BW/4HANA instead?
Sometimes. If your reporting is overwhelmingly SAP-sourced, your analytics ambitions are modest and your team is deeply BW-skilled, BW/4HANA is a defensible answer. We say so when it is true. The migration path comparison sets out those cases.
› How long does a BW to Snowflake migration take?
It depends mostly on the live object count, which is what the assessment establishes. The assessment itself takes 3 to 4 weeks and produces a phased wave plan with effort per wave.

Find out what your BW estate contains

The BW Estate Assessment inventories every object, shows you what is dead and returns a costed migration plan. 3 to 4 weeks, $25,000 to $40,000, scoped by landscape size.

Book an Assessment See how we run it