Insight
A customer migration rehearsal should explain every discrepancy
A rehearsal example shows how matching record counts can conceal broken customer history, and how to control cutover and recovery.
- Published
- Author
- Demari Miller
- Series
- Cass & York
- Reading time
- 3 min read
Share this article
The jobs arrived in the new system. Their count matched the old system exactly. Some had no customer attached.
A migration check based only on row counts would miss that loss of context. The records exist, but employees can no longer see them as part of the customer's history.
Rehearse the migration with the relationships and daily work included. The following example shows why.
Reconcile records and their links
Suppose the source contains 12,480 customer records and 48,620 jobs in the agreed migration scope. After a rehearsal import, the results are:
- Customer records. Source: 12,480. Destination: 12,391. Finding: 89 customer records missing
- Job records. Source: 48,620. Destination: 48,620. Finding: Count matches
- Jobs without a resolved customer. Source: 0. Destination: 102. Finding: Relationships require investigation
These are illustrative rehearsal figures. Investigation finds that the customer extraction excluded 89 archived accounts. Those accounts explain 88 of the unlinked jobs. The other 14 jobs used legacy customer identifiers that were missing from the mapping.
The fix is to include the archived records required by the historical scope and resolve the 14 legacy links using source evidence. Repeating the job import without correcting those inputs would reproduce the same gap.
After the correction, the expected result is 12,480 customers, 48,620 jobs, and no unexplained customer links. Preserve the ID mapping so future changes reach the same records.
Test the history an employee retrieves
Open an archived customer's completed job, a renamed account, a multi-location customer, an invoice dispute note, and an attachment associated with service history. Confirm that the appropriate staff member can find the information and see its relationship.
Also inspect transformed fields. Dates, status values, field lengths, and timezone interpretation can change without changing row counts. Reconcile relevant financial values at the agreed scope and explain intentional differences separately.
Set a go or pause decision
For this migration, pause if a customer-to-job link remains unexplained, required financial totals disagree, or essential attachments are inaccessible. The responsible business owner signs off on the checks after affected staff review the records.
An approved archive exclusion is different from a missing record. Document it as a scoped decision with an available retrieval path. Do not treat an unexplained discrepancy as an archive policy after the fact.
Account for edits during the move
Choose a cutover method the sources can support. A change freeze needs a scheduled window and a plan for urgent work. A final delta import needs a dependable way to capture creations, changes, and relevant deletions after the rehearsal boundary.
Record the extraction boundary and the changes applied. Staff should know which application accepts new work at each stage. Two writable systems without a reconciliation plan can create histories that neither contains completely.
Recovery includes the new work
If the team has created customers, jobs, or invoices after switching, restoring the old snapshot alone loses those changes. Keep a record of post-cutover activity and define how it will be reconciled if the old system must resume operation.
Financial records may require application-specific correction rather than a simple reverse import. Assign the recovery decision and the affected record review to the appropriate owners.
The rehearsal should exercise this path before launch. A backup proves that a copy exists. A recovery test establishes whether the business can continue with the work performed since that copy was taken.
Share this article