Post Go-Live Data Validation: What Business Users Check in the First 30 Days

The short answer. Post go-live data validation is what business users do in the first weeks on S/4HANA to confirm the migrated data holds up under real work: orders, purchases, invoices and payment runs at real volume. It catches the problems no rehearsal could, because real transactions exercise combinations no test script covered. The first 30 days work best with a short list of checks per team, a fast route for reporting issues, and a clear handover of data ownership from the project to the people who will maintain it.

Go-live is not the finish line for data. It is the first day the data meets real work at full volume, and that is when a certain class of problem finally shows itself. Here is what business users should watch in the first month, and how to handle what they find.

Why problems appear after go-live

However thorough the mock migrations, rehearsals test known scenarios. Real operations do not stick to the script. A customer with an unusual combination of terms places an order; a supplier with a rarely used setting is paid for the first time; a material with an odd unit of measure is received at a plant. These combinations reveal data problems that were always there but never exercised. They are usually small and fixable, provided someone notices quickly and knows where to report them.

What each team should watch

Team	Watch for
Sales and order management	Orders blocked or priced wrongly, missing customer settings, delivery or billing errors
Procurement	Purchase orders with wrong terms, supplier details that fail at payment, open PO quantities that do not match
Supply chain	Planning runs producing unexpected proposals, stock that does not match, unit of measure errors
Finance	Postings to unexpected accounts, payment run failures, balances that drift from the opening position

Make reporting easy and fast

An issue noticed and not reported is the most expensive kind.

In the first weeks, business users will notice odd things and wonder whether they matter. The single most useful step is a fast, low-friction way to report them, with someone triaging daily to separate data problems from training questions and genuine defects. Data issues found early are usually single records or small patterns. Left to accumulate, they become workarounds, and workarounds become permanent.

Monitor, do not just react

Waiting for users to report problems is necessary but not sufficient. Running the same quality rules used during the migration against the live system in the first weeks catches issues before anyone trips over them: a field that is filling incorrectly, duplicates being created again, records drifting from the standard. The rules already exist from the migration; turning them into ongoing monitoring costs little and turns the first month from reactive firefighting into managed stabilisation.

Hand over ownership deliberately

During the project, the migration team owns the data. After go-live, the business does, and that transfer is easy to leave implicit. The first 30 days are the natural moment to make it explicit: named owners per data domain, the standards and rules they are responsible for, and the scorecards they will use to watch them. Organisations that skip this find, a year later, that the data has degraded back towards where it started, because the project that cleaned it has gone and nobody inherited the job.

Closing out the first month

1. Review the issue log. Group what was found by cause, so recurring problems get fixed at source rather than record by record.
2. Re-run reconciliation. Confirm the opening position still ties after a month of real activity.
3. Confirm owners and monitoring. Every domain has an owner, a set of rules and a scorecard someone reads.
4. Record what you learned. Useful for the next wave or the next migration.

The first week matters most

Data problems tend to cluster in the first week, because that is when the most new combinations are exercised for the first time: the first payment run, the first month-end steps, the first orders for unusual customers. Concentrating extra attention on that week, with stewards and key users available to look at issues quickly, catches most of what will appear. By the end of the first month the rate of new data issues usually falls sharply, which is itself a useful signal that the migrated data is holding up.

Data issue, training issue or defect?

Not every problem reported after go-live is a data problem. Some are training gaps, where a user does something the new way is not designed for, and some are genuine system defects. Triage that separates the three quickly saves effort: data issues go to the steward for the domain, training issues to the trainers, defects to the project team. Mixing them in one queue slows everything down and frustrates users who simply wanted an answer.

Measure the stabilisation

Tracking the number of new data issues per week, and how quickly they are resolved, gives a clear picture of whether the system is stabilising. It also provides evidence for closing out hypercare, rather than ending it on a fixed date regardless of how things are going.

Volume reveals what samples hide

Some data problems only appear at real volume. A rule that works on a few records may slow down or fail under a full day's postings; a duplicate that never mattered in a test becomes visible when two users order from the same supplier under different records on the same morning. The first weeks at full volume are the real test of the migrated data, which is why monitoring should be at its most active then rather than winding down.

Keep the stewards and key users who knew the migration available through this period. They understand why the data looks the way it does, which makes their triage far faster than anyone coming to it fresh.

How deKorvai helps

deKorvai carries the migration's data rules into live operation. The same configurable business and technical rules used to validate the migration can run as continuous monitoring after go-live, with real-time scorecards showing quality by domain and trend. Anomaly and drift detection flag data moving away from the standard, reconciliation confirms the opening position still holds, and full audit trails record what changed. deKorvai's documented migration flow also covers post-go-live validation and automation of repetitive checks, so stabilisation does not depend on people remembering to look.

Key takeaways

• Real work exposes problems rehearsals cannot.
• Give each team a short watch list and a fast way to report issues.
• Turn migration rules into monitoring, so problems surface before users hit them.
• Hand over data ownership explicitly in the first 30 days.

Frequently asked questions

Why do data problems appear after go-live?

Because rehearsals test known scenarios while real operations produce combinations nobody scripted, such as unusual customer terms or rarely used supplier settings. Those expose data problems that were always present but never exercised.

What should business users check after go-live?

Sales should watch for blocked or mispriced orders, procurement for purchase orders and payments that fail, supply chain for unexpected planning results and stock differences, and finance for unexpected postings, payment run failures and drifting balances.

How should post go-live data issues be handled?

Through a fast, low-friction reporting route with daily triage that separates data problems from training questions and defects. Grouping issues by cause means recurring problems get fixed at source rather than record by record.

Who owns the data after go-live?

The business, but the handover from the project needs to be made explicit: named owners per domain, the standards and rules they are responsible for, and scorecards they actually use. Without it, data tends to degrade again.