Most mock loads are designed to pass
A mock load that finishes inside its window with a green report has usually been built to do exactly that. The extract was cleaned before anyone handed it over, the sample was a tenth of production, the window was a whole weekend for work that gets four hours at go-live, and the counts were checked by the people who wrote the mapping. That run proved the loader works. It said nothing about your cutover.
I have sat in the review where a programme called mock two a success and then lost most of a weekend at go-live. The failures were never exotic. Load routines that behaved at 200,000 records stopped behaving at four million. A sequencing dependency nobody had written down decided whether half the open items posted. Records that passed validation alone failed once they met each other in the target.
So build the rehearsal so it can fail. Every choice that makes it easier to pass takes away a reason for running it. Each decision that follows costs money or political capital.
A sample proves the mechanism and nothing else
Volume is the first thing programmes trade away and it hides the most. Load throughput rarely scales in a straight line. Index maintenance, staging table growth, log volume and lock contention all get worse faster than the record count, so a run that handles a tenth of production in forty minutes will not finish in seven hours. On S/4HANA the migration cockpit staging tables behave differently once they are genuinely large, and on Fusion Cloud the file based loaders queue behind scheduled jobs that sat idle during your quiet test.
The clearest case I have seen was a building products manufacturer moving three legal entities off ECC, with a fifty eight hour window agreed with the plants over a bank holiday. Mock two loaded a twenty percent sample of open receivables in fifty minutes and everyone signed it off. Mock three ran the full 1.4 million open items and took nine hours and twenty minutes, because tax determination ran per line and the unfiltered extract carried far more lines per document.
Full volume also changes what your people have to do. Somebody has to watch a nine hour load overnight, and the rehearsal is where you find out that nobody was rostered for it and that the one person who could restart a failed job was asleep.
Leave the awkward records in
The second trade is filtering. Extracts get cleaned before a mock load because failed records make the run look bad, so the vendor who is also a customer, the material with two units of measure and the credit memo against an invoice archived in 2019 all quietly leave the scope. Every one of them exists in production and every one of them arrives at go-live.
Some records fail only in combination. A cost centre that validates on its own fails when the profit centre it points at loads in a later wave. A payment term that exists in the target fails for one company code because the calendar variant behind it was never created there. Filtering removes exactly the combinations that produce these. Business keys that stay stable and master data with real owners are what keep the count down.
Then there are open transactions with no clean representation in the target. Purchase orders with a partial goods receipt and no invoice. Down payments against contracts being restructured. Parked documents, intercompany stock in transit, sales orders half delivered with a rebate accrual behind them. Each one needs a business decision about migrating it, closing it in the legacy system before cutover, or re-entering it by hand. Filter them out and you defer every one of those conversations to the week you can least afford them.
Run the clock, not the target
Start the rehearsal at the hour the real cutover starts, on the same day of the week, and let the clock run through the night. No pausing while someone fixes a mapping. No restarting a failed load at nine the next morning and recording the elapsed time as twelve hours. If a step fails at two in the morning, the time until somebody notices belongs in the measurement.
Sequencing shows up here more than anywhere. Almost every programme has a load order in a spreadsheet and almost none have tested it under time pressure. Bank details have to exist before the first payment proposal. Assets need their cost centres. Open items need the customers and tax codes that determination will ask for. When one wave slips two hours, the rehearsal tells you which later waves can start anyway and which sit idle waiting.
The clock also produces the decision points you need at go-live. By the end you should know what time the business sign off has to happen, the latest safe start for the final delta load, and the last step you can abandon without rolling back.
Finance signs the reconciliation, not the data team
Reconciliation in a rehearsal is usually a row count comparison produced by the migration team. At go-live it is a controller signing a trial balance under a deadline with the auditors waiting. Different activity, different people, so put the controller in the rehearsal and let them do the version that counts.
That means finance pulling their own reports out of the target rather than reading a spreadsheet the data workstream prepared. Trial balance by company code. Subledger agreement to the general ledger. Open receivables ageing against the legacy ageing on the same key date. When they do it themselves you find out that the report they rely on does not exist yet in the target, or that it groups by something the new chart of accounts no longer carries.
Budget real hours for this. On the building products programme the finance reconciliation took eleven hours the first time and four the second, once the team had built their own comparison queries. Eleven hours had never been in the cutover plan. The discipline behind a payroll parallel run applies here, and the questions raised by cutover reconciliation are the ones your controllers will ask.
Rollback gets executed, not documented
Ask how the rollback works and you usually get a slide. Restore the database, reverse the interface switches, tell the plants to carry on with the old system. Nobody has timed it, and several of the steps are owned by people who have never performed them together.
Execute it once, at the end of a rehearsal, against the loaded system, with the clock still running. What it reveals most often is that the real point of no return sits much earlier than the plan claims. Once the bank has the new file format and the tax engine has issued numbers in the new sequence, a database restore no longer puts you back where you started. Knowing that hour turns an open ended judgement call into a deadline.
A long defect list means the rehearsal worked
Here is the awkward part. A rehearsal that raises 240 defects reads worse in a status pack than one that raises nine, and the manager reporting 240 is the one having the difficult meeting. So people round down, close findings as observations and park the ugly ones.
Report it the other way and defend it. Every defect found in a rehearsal is one that would otherwise have been found with the plants stopped and finance waiting. Give the count, give the breakdown by what has to change, and name the ones that will still be open at the next mock. Findings that change the cutover plan matter more than findings that change a mapping, and a steering group can follow that if you draw it for them.
Before your next steering meeting, ask what the last mock load was allowed to fail at. If the answer is nothing, what went in the calendar was a demonstration, and the rehearsal is still ahead of you.
