SAP S/4HANA data migration
The programme succeeds or fails on whether trusted data arrives in the new system. We have been delivering that outcome on SAP programmes for over two decades.
Scope: what moves, and what should not
The first S/4HANA data decision is not technical. It is editorial: which data earns a place in the new system. Operational master data and open items move. Decades of closed transactions usually should not, and dragging them along inflates every subsequent activity, from mock loads to reconciliation.
The historical data still matters, for audit, for reference, for the tax authority. It needs a retention and decommissioning strategy, not a migration. Separating those two questions early is the cheapest scope reduction available to any programme.
Discovery and source analysis
In migration programmes, one of the first things we look for is the distance between what the design workshops believe about the source data and what profiling shows. That distance is the real project risk. We profile the source objects before mapping starts, because a data assessment at this stage changes the scope rather than the schedule.
Objects, and the Business Partner question
Most ECC structures carry into S/4HANA more gently than the market fear suggests. The Business Partner model is the genuine exception: customers and vendors converge, and every unresolved duplicate becomes a conversion decision. We resolve duplicates before CVI strategy is fixed, define the merge and survivorship rules with the business, and treat customer, vendor and material objects to rule-based quality gates from the first cycle.
Mapping, transformation and cleansing
Mapping is where business meaning either survives or quietly dies. Every mapping decision gets a named business owner, transformation logic is built as repeatable ETL rather than one-off scripts, and cleansing runs in the source wherever possible so the improvement outlives the go-live. Fixes buried in migration code are invisible, unauditable and lost the day the programme ends.
Migration cycles and mock conversions
We run migrations as rehearsed cycles: each mock conversion executes the full sequence at real volume and produces a reconciliation pack the business can read. Cycle by cycle, open issues trend towards zero and the cutover stops being a leap. On one retail programme that discipline carried 450 stores live in a single weekend, inside a sequence of 11 go-lives in nine months.
Reconciliation, assurance and cutover
Loading is not migrating. Every cycle reconciles to value level, not record counts, and the evidence follows the disciplines we describe under data migration reconciliation and migration assurance. Cutover itself is sequencing, timing and validation run with the business in the room, against a runbook already proven in rehearsal.
Source
Discovery and scope
Profile
Evidence before mapping
Map
Business meaning, owned
Transform
Repeatable ETL
Validate
Business rules as gates
Load
Rehearsed at volume
Reconcile
Values, not counts
Sign-off
Named owners, real evidence
Delivered
- Stores migrated to SAP Retail
- 2,400+
- Rows handled on one programme
- 50bn+
- Post-load corrections, mainframe retirement
- 0
