Our method
Six phases, the deliverables each one produces, and an account of what goes wrong on these projects.
Establish what the estate is for: which reports drive decisions, who owns them, what the S/4 and BDC roadmap looks like, and what your license position permits.
Deliverables
What we need from you
Two to three hours each from the BW owner, the reporting owner and whoever holds the SAP license agreement.
Establish what the estate contains. Every object cataloged, usage analyzed, lineage mapped and complexity scored, so scope is set on evidence rather than on the inventory count.
Deliverables
What we need from you
Read access to BW metadata and statistics tables. No production business data leaves your environment.
Design the Snowflake landing zone, the modeling approach, the ingestion route per source system and the security model that replaces BW analysis authorizations.
Deliverables
What we need from you
Snowflake account access or a decision on provisioning, plus security and data governance stakeholders.
Build the pipelines and convert the BW transformation logic into Snowflake SQL and dbt models, wave by wave, working from the lineage map as the specification.
Deliverables
What we need from you
A named business owner per wave who can answer "should this number look like this?" within a day.
Prove the numbers. BW and Snowflake produce the same figures over the same periods, at the grain the business reports on, with every variance explained before anyone signs it off.
Deliverables
What we need from you
Business users to review the parallel-run output. This phase fails on people being available, rather than on technology.
Move reporting onto Snowflake, decommission the retired BW objects and leave your team able to run and extend what we built.
Deliverables
What we need from you
A decision on BW decommissioning scope and timing, which is usually a license-cost conversation.
Four problems account for most of the trouble on BW migrations. None of them are surprises, and all of them cost less to plan for than to discover.
A margin figure differs by a fraction of a percent and nobody can prove which number is right. We plan reconciliation from phase 2 rather than phase 5, and we reconcile at the grain the business reports on rather than at row counts. Sometimes a variance turns out to be a long-standing BW defect. We document those and let the business decide which behavior to keep.
Every BW estate has routines whose author has left and whose logic nobody will confirm. We do not guess at these. They are flagged in the assessment, scoped separately and converted against observed behavior, with the business signing off on the resulting figures. This is slower than assuming the logic is understood, and it is why the estimate holds.
Basis teams are busy, and read access to BW metadata is a change request like any other. We ask for it in phase 1 rather than phase 2, specify exactly what we need and why, and plan for the access conversation to take weeks. Projects that slip before they start usually slip here.
If an S/4 migration is running in parallel, the source landscape changes underneath the target design. That is workable when it is known up front, because it changes the ingestion design, the sequencing and sometimes the decision about which waves to run at all. We ask about it in the first meeting.
We own delivery end to end and report against the wave plan. This suits organizations without spare data engineering capacity, or where the people who knew BW have already left.
We run the assessment, set the architecture and standards, and work alongside your engineers on the waves. This suits teams who intend to own the Snowflake estate afterwards and want to build that capability while the migration happens.
Both models start with the same assessment, so you do not have to choose between them before you know what is in your estate.
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.
