Lesson 4 of 5
Mock loads
8 min
Listen to this lesson
A mock load is a full rehearsal of the migration into a non-production system: extract, transform, load and validate, with the real tools and, increasingly with each mock, the real volumes and timing. Mock loads exist for one reason: so that the production load on go-live weekend is the fourth or fifth time the team has done it, not the first.
What a mock load proves
- Technical feasibility: the objects load at all, in the right sequence.
- Data quality: error rates fall from mock to mock as cleansing and rules improve.
- Correctness: counts and values reconcile with the source, and data owners confirm samples.
- Usability: migrated data works in processes, for example a migrated open order can be delivered and billed.
- Timing: the whole sequence fits in the cutover window.
- Repeatability: the run book is complete enough that it works the same way every time.
A typical mock plan
- Mock 1Technical trialMain objects, partial data; find sequence and mapping gaps
- Mock 2Full volumeAll objects, full data; reconciliation and first business validation
- Mock 3Timed rehearsalFull cutover sequence against the clock; full validation and sign-off practice
- Dress rehearsalGo-live simulationRun exactly as planned for go-live, including decision points
- Go-liveFinal loadProduction load, validation and sign-off
Give every mock a written goal and simple pass conditions before it starts, for example "Mock 2: all objects loaded at full volume; error rate per object below 3%; open receivables reconciled by company code". Without them, a mock ends with a long list of observations and no clear answer to the only question that matters: are we ready to move on to the next one?
Measuring mock loads
Each mock produces numbers that should improve: load error rate per object, number of open data quality issues, reconciliation differences, validation findings and total elapsed time. Luis compares elapsed time with the cutover window; Priya tracks errors and findings to closure. If a mock gets worse instead of better, find out why before running the next one.
| Measure | Mock 1 | Mock 2 | Mock 3 | Target for go-live |
|---|---|---|---|---|
| Customer load errors | 9.5% | 2.1% | 0.3% | Below agreed threshold, all explained |
| Open AR reconciliation difference | Not run | MXN 41,200 | MXN 0 | MXN 0 in company code 1910 |
| Open data quality issues | 212 | 47 | 6 | None that block go-live |
| Elapsed load time | – | 61 hours | 38 hours | Within the 40-hour load window |
Mock load measures for the Alternadores del Norte load. Numbers are fictional.
After each mock
Hold a short review: what failed, why, what changes to rules, sequence, cleansing or run book are needed, who owns each action, and by when. Freeze changes to mapping rules as go-live approaches, because every late rule change invalidates part of the earlier testing. Mock 3 and the dress rehearsal should run with the rules that will be used in production.
- What failedLoad errors, reconciliation differences and validation findings per object
- WhyCause: source data, mapping rule, sequence, configuration or run book
- ChangeFix the cause in cleansing, rules, sequence or the run book
- Owner and dateEach action assigned; Priya tracks findings, Luis tracks timing
- FreezeRules frozen before Mock 3 and the dress rehearsal
What would you do?
Mock 2 of the Alternadores del Norte load took 61 hours against a 40-hour load window. The team suggests skipping Mock 3 to give developers more time to optimize. What is the best course?
Mocks feed the rest of the program
Mock loads are also the best source of test data for the rest of the program. Integration and user acceptance testing run far more realistically on migrated customers, products and open orders than on a handful of records typed in by hand, and they often find migration defects that the migration team's own checks missed. Plan the test cycles so that at least the later ones run on data from a recent mock.
- Mock loads rehearse the full migration so the production load is not the first attempt.
- They prove feasibility, quality, correctness, usability, timing and repeatability.
- Measure error rates, reconciliation differences, open issues and elapsed time; they should improve each mock.
- Use production-like systems and fresh extracts; freeze rules before the final rehearsals.
Check your understanding · not graded
Lesson check
1. What is the main purpose of mock loads?
2. What does a timed mock load prove?
3. Why freeze mapping rules before the final rehearsals?
4. Why load mocks into a system built with production transports?