Lesson 5 of 5
Sign-off per mock and final load
12 min
Listen to this lesson
Every mock load ends with a decision: are we good enough to move on? The final load ends with a bigger one: can the business start transacting on the migrated data, for Contoso's Wave 2 in company code 1910? Both decisions need agreed exit criteria and a sign-off record. This lesson also covers how migration defects and data-quality issues are tracked to closure between loads.
Defects and data-quality issues
Not every migration finding is a defect in the usual sense. Distinguish the cause, because it decides who fixes it and how:
| Category | Example | Fixed by | Fixed where |
|---|---|---|---|
| Source data quality | Supplier missing tax number | Data steward, approved by owner | Source system, before next extract |
| Mapping or rule defect | Unknown payment term silently defaulted | Migration specialist; owner approves rule | Mapping specification and transformation |
| Extraction defect | Partially received POs not selected | Migration specialist | Extraction logic |
| Configuration gap | Payment term missing in target configuration | Functional consultant | Configuration, transported |
| Load or sequence issue | Orders loaded before customers | Migration specialist and cutover manager | Run book and sequence |
Classifying migration findings so they reach the right fixer.
- Is the record wrong in the source system?Yes → source data quality: the data steward fixes it before the next extract · No → next question
- Was it selected or extracted wrongly?Yes → extraction defect: fix the extraction logic · No → next question
- Did a rule or mapping transform it wrongly?Yes → mapping defect: fix the specification and transformation · No → next question
- Is a target setting missing?Yes → configuration gap: the functional consultant fixes and transports it · No → load or sequence issue: fix the run book
Track all of them in the defect tool with object, mock, category, severity, owner and target mock for the fix. Measure closure between mocks: a data-quality issue fixed in the source shows its effect only in the next extract, so confirm closure in the next mock's reconciliation and validation, not on the strength of a status change.
Exit criteria per mock
Exit criteria get stricter with each mock. A sensible progression for the Alternadores del Norte load:
- Mock 1Technical exitAll in-scope objects attempted; sequence issues known; rule tests passed for core objects
- Mock 2Completeness exitFull volume loaded; reconciliation run for all objects; differences explained; no critical defects without a fix plan
- Mock 3Quality and timing exitFinancial reconciliation at zero difference; business validation passed by owners; load within the cutover window
- Final loadGo-live exitSame criteria as Mock 3 met in production; owner sign-offs per object; business go decision
The migration sign-off record
For each mock and for the final load, keep one record per migration object, summarized into a migration sign-off for the cycle. Each object record holds:
- Object, mock or final load, specification version and the date and time of the extract (the key date).
- Load result: records in scope, loaded, rejected, with explanations for rejects.
- Reconciliation results: counts, sums and key attributes, with differences and approvals.
- Business validation result: records inspected, usability tests run, findings.
- Open defects and data-quality issues with severity, owner and plan.
- Data owner's decision (accepted, accepted with conditions, rejected) with name and timestamp.
When the final load is not clean
Plan the "what if" before the weekend. For each object, decide in advance what can be fixed in place after go-live (for example a handful of records corrected manually under an approved procedure, with evidence) and what would stop go-live (for example unreconciled G/L balances). Agree the latest time on the weekend at which a fallback to the old system (for Alternadores del Norte, its legacy ERP) is still possible. A good cutover plan makes this decision faster and less emotional, because the criteria were set when everyone was calm.
- Is the difference explained and inside the agreed tolerance?Yes → owner signs the object · No → next question
- Is it on the pre-agreed fix-in-place list?Yes → sign with conditions; correct records after go-live under the approved procedure, with evidence · No → next question
- Can it be fixed before the fallback deadline?Yes → fix, reconcile again and return to the decision point · No → go-live stops and the fallback plan applies
What would you do?
At 03:00 on the Alternadores del Norte go-live Sunday, all objects are loaded and reconciled, except that open payables differ by MXN 2,150 across three supplier items. The migration specialist believes it is a currency rounding issue. Dan must sign the supplier objects. What is the best course?
Carrying migration evidence forward
The migration sign-off from the last mock and the final load feeds directly into the program's go/no-go evidence pack: the reconciliation log, the owners' validation results, open migration defects with workarounds, and the final decision record. Keep the Migration Cockpit's message logs and the reconciliation reports with them, because in the first weeks after go-live, questions such as "was this customer's balance migrated or posted later?" are answered fastest from that evidence. After go-live, hold a short lessons-learned review on the migration, since many programs face further rollouts with new plants or company codes, as Contoso did with Alternadores del Norte, and the next migration will reuse the same method.
- Classify findings by cause: source data, mapping rule, extraction, configuration, load or sequence.
- Confirm closure in the next mock's reconciliation and validation, not by status alone.
- Exit criteria tighten from mock to mock; the final load meets the strictest set.
- Keep a sign-off record per object with load, reconciliation, validation, open issues and the owner's decision.
- Plan the final-load decision point and fallback criteria before the weekend.
Check your understanding · not graded
Lesson check
1. A supplier lacks a tax number in the source. Which category is this?
2. How is closure of a source data-quality fix confirmed?
3. Which exit criterion fits Mock 3 rather than Mock 1?
4. Who signs each migration object at the final load?