De-risking an SAP S/4HANA finance migration

A leading Swiss private bank was moving its core finance from SAP ECC to S/4HANA (new S/4HANA core, Fiori front end), with the go-live locked to the narrow break around the year-end close. Copying the data was never the risk. The risk was proving it had arrived correctly: every asset, every balance, every custom record, to a standard the business and the auditors would sign. We owned that proof: the automated data-migration validation, built on Tricentis Tosca: Tricentis Data Integrity (Tosca DI) for the data reconciliation, classic Tosca for the GUI-level checks.

A move to S/4HANA doesn't just re-house finance data: it restructures it (the Universal Journal consolidates what used to sit in separate tables), and the migration reformats, remaps and merges records on the way across. Add real-world scale (hundreds of standard and custom objects, billions of records across many legal entities) and an accounting go-live that is locked to the year-end and cannot slip without waiting a full year. Verification has to be fast, trustworthy and auditable, all at once.

A naive field-for-field compare fails immediately, because the data is supposed to change. A meaningful reconciliation embeds the same business rules the migration applied, so expected differences never surface as false failures. In practice that means comparing source to target at table and transaction level, applying the transformation logic (company-code remapping, account renumbering under a new scheme, accounting-principle mapping, scope filters by date and status, and per-object field exclusions), then classifying every remaining delta as expected/explained or a genuine defect. That distinction is the whole game: it lets the team confidently accept the 'failed-but-expected' cases instead of chasing thousands of legitimate deltas.

Regulated finance reports are produced per legal entity, so validation must run per booking entity, not just at group level. Rebuilding tests for each would be unaffordable. Instead, reusable templates (a Header/Item validation with a substitution mechanism) iterate the same logic across every entity without rebuilding a single test: the difference between a validation that scales to dozens of company codes and one that doesn't.

Every object produces an automated evidence report. Discrepancies are triaged with the business and the migration team, root-caused, and either fixed or explained. Acceptance is structured per company code (a group-level pass isn't enough when reports are signed per entity), with a full trail from migration run to per-entity sign-off. In a regulated bank, reconciliation isn't finished when the numbers match; it's finished when someone accountable has signed that they match, with the evidence to back it.

The approach is rehearsed, not improvised: successive migration runs and UAT cycles, with later rounds run against production-like data as dress rehearsals. Even so, the windows are brutal: for some objects the entire reconciliation, sign-off included, has to be finished in around 30 minutes, worked overnight as loads complete, often from around 10pm into the early hours. Automated checks and instant evidence are the only way a timetable like that is survivable.

The source systems held billions of records; scope filters cut that down to what mattered, and millions of records were compared one-to-one per object, across 25 company codes, 40-plus staged runs and 150-plus objects. Every in-scope object reached a per-company-code business sign-off, including many that failed the raw compare but were validated as expected deviations. The principles transfer to any ECC→S/4HANA finance migration: mirror the migration's logic, scale with reusable templates, and make evidence and per-entity sign-off first-class.