How do you know if your SAP data is ready for an S/4HANA migration?

Why data, not code, is usually what slips the date

Custom code gets the attention in an ECC to S/4HANA program because it is visible, countable, and easy to argue about. Data is the quieter risk, and it is the one that more often forces a second or third conversion cycle. The reason is structural: a conversion is a one-shot event against a copy of your production data, and every defect in that data surfaces at exactly the worst moment — mid-cycle, on a weekend, with a technical team that cannot fix a business data problem without the business.

The analogy that lands with executives is a house move. Custom code is the furniture: you can see it, measure it, and decide in advance what goes in the truck and what goes to the curb. Data is the plumbing behind the walls. Nobody inspects it until the water is turned on in the new house, and by then the moving truck has already left. The whole point of a readiness check is to open the walls while you still have time and leverage.

The checks that actually decide readiness

S/4HANA is not a re-skinned ECC; it changes the data model in specific, knowable ways. Readiness is therefore a finite set of checks tied to those changes, not an open-ended quality crusade. The ones that decide whether a conversion cycle succeeds are:

• Business Partner conversion (CVI) — S/4 requires customers and vendors to exist as business partners. Every customer or vendor without a valid, synchronized BP counterpart is a hard stop, and duplicates across the two masters have to be resolved by the business, not by IT.
• Changed field and length rules — the material number length, extended address and tax fields, and other simplified-table changes reject records that ECC tolerated for years. These fail late and in volume if they are not counted early.
• FI/CO reconciliation under the Universal Journal — ACDOCA merges what used to be separate FI, CO, ML, and AA tables. Ledgers, sub-ledgers, and open items that do not reconcile in ECC will not reconcile themselves in S/4; they will simply stop the conversion.
• Orphans, duplicates, and non-converting document states — open deliveries with missing references, partially billed orders, blocked or inconsistent documents. Each one is small; in aggregate they are the runtime of your conversion weekend.
• Obsolete volume — data you are carrying but no longer need. Archiving before conversion is the cheapest performance and runtime improvement available, and it is almost always deferred until it is too late to help.

Readiness is a count, not an opinion

The difference between a readiness assessment that helps and one that does not is whether the output is a number traceable to your system. "Master data quality is a concern" is not actionable. "You have N customers without a business-partner counterpart, of which M are duplicates across customer and vendor" is a work package with an owner and an end date.

This is the same discipline we apply on the code side. In one reference estate — a live ECC system we analyze end to end; a customer's numbers come from their own system — the analysis reads real objects and real business documents, including roughly 8,360 sales orders, and every figure on screen traces back to a specific read rather than a rule of thumb. Data readiness deserves identical treatment: aggregate counts pulled from your live system, with the query behind each number available for your team to inspect. Anything you cannot trace, you should not plan against.

What to do when the number comes back bad

A poor readiness number is information, not a verdict. There are only three responses, and mature programs use all three. Remediate at the source, so the defect stops being recreated by the process that caused it. Archive or exclude what has no business reason to move. And sequence the remainder, so that the checks that gate the conversion technically are cleared first and the merely desirable cleanup happens after go-live.

The one response to avoid is the open-ended data quality program that runs in parallel with the migration and is never done. Scope it to the conversion-blocking checks, finish those, and treat the rest as continuous improvement in the new system. The clock imposed by ECC end of mainstream maintenance is a planning constraint, and readiness work is the part of the plan most often underestimated.

Where agents help, and where they do not

An agent connected read-only to your live system is very good at exactly this problem, because the work is high-volume, rule-based, and evidence-driven. It can compute the readiness counts, group them by object and by root cause, and keep the numbers current as remediation progresses — turning a one-time assessment into a live scoreboard. Reads are aggregate by design: counts and sums over business documents, never row-level customer records pulled out of the system.

Where agents stop is equally important to state plainly. Deciding which of two duplicate customers survives is a business decision, not an inference. Configuration changes are drafted as a governed customizing transport in a development system — your change board decides whether it ever lands, and nothing touches production on its own. And the functional-testing agent that would validate a remediated process end to end is in build and design preview, not shipped; until it is, validation stays a human step. An agent that gives you an honest, traceable count and stops there is worth more than one that claims to have fixed your data.