Skip to content
Ixia Consulting

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.

The migration spine
  1. Source

    Discovery and scope

  2. Profile

    Evidence before mapping

  3. Map

    Business meaning, owned

  4. Transform

    Repeatable ETL

  5. Validate

    Business rules as gates

  6. Load

    Rehearsed at volume

  7. Reconcile

    Values, not counts

  8. 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