The order is the argument
Almost every S/4HANA programme includes data work. The difference between programmes that benefit from it and programmes that do not is almost entirely a question of when it happens.
Reduction before the migration changes the size of everything that follows. Reduction after the migration recovers some ongoing cost and none of the project cost, because by then the infrastructure has been provisioned, the cutover has been rehearsed against the full volume, and the timeline has already absorbed it.
Same work, same tools, materially different return, decided by sequencing alone.
Three costs that scale with volume
Cutover length. The downtime window is largely a function of how much data has to move and be validated. This is the constraint the business feels most directly, because it is negotiated in hours over a weekend and every extra hour is a real conversation with operations.
Target infrastructure. Whether you are sizing a private cloud landscape or committing to a subscription tier, the sizing is based on what actually arrives. Data removed beforehand is capacity never provisioned, and that decision persists for the life of the contract.
Project effort. More data means longer test cycles, longer trial conversions, more validation and more remediation when something does not reconcile. This one is rarely modelled and it is frequently the largest of the three.
What "reduce" actually means
It is worth separating three things that get bundled together, because they carry very different risk.
Archiving moves closed, completed records out of the live database into archive storage, with retrieval still available from inside SAP. Nothing is lost. Reports that need history still run, they simply read from a different place.
Deletion removes data permanently, and it should only ever happen against a documented retention rule with the legal position established beforehand. This is the smallest category and the one that needs the most care.
Exclusion from scope is the migration-specific one: deciding that certain history, certain company codes or certain closed years simply do not travel to the new system, while remaining accessible in the old one until it is decommissioned.
Most of the benefit comes from the first and third. The second is where the compliance conversation lives.
The objection, and the answer
The reasonable objection is that nobody wants to lose access to history during a period when everything else is already changing. That instinct is correct and it is why the sequence includes a validation step.
Before anything is archived, the retrieval path is tested with the people who actually use the data. Finance runs its year-end reports. Audit checks the trail. Operations pulls the lookups they rely on. If a retrieval path does not work, that object stays live and the plan adjusts.
Done this way the risk is genuinely low, and it is far lower than the alternative risk of discovering during a trial conversion that the downtime window does not fit.
What happens after go-live
The sequence has a fifth step that is skipped more often than any of the others: retiring the legacy system.
Estates that go live successfully and then keep ECC running for reference access carry two licences, two support contracts, two audit surfaces and two sets of infrastructure, indefinitely. The reason is almost always that nobody made the data accessible elsewhere, so switching it off would remove a lookup somebody occasionally needs.
Solving that is a small piece of work compared with the migration itself, and it removes a cost that would otherwise run every year for as long as the old system exists.
The practical sequence
Measure the estate at table level. Decide what stays live, what is archived, what is excluded from the migration and what can be destroyed under a documented rule. Reduce and validate retrieval. Migrate the smaller estate. Decommission what you left behind once its data is preserved and reportable.
Five steps, in that order. The order is the entire argument.