Data migration: account for every record
Plan mapping, rehearsals, reconciliation and cutover so each in-scope record has an explained destination and the business can verify the result.
A migration is ready when the business can account for its records and use them correctly in the new system. A successful import job, or even a matching row count, does not establish that balances, relationships and open transactions survived the move.
Start migration planning while the new system is being designed. Old fields often carry business rules that are absent from the documentation. Those rules need a decision before they become a transformation script.
Decide what moves and who accepts it
List the entities in scope: customers, suppliers, transactions, products, assets, documents and any required history. Decide what will move, what will remain in an accessible archive and what can be excluded. Give each decision a business owner.
Include downstream dependencies. A weekly export, an external partner file or an operational spreadsheet may rely on the old system even when it is absent from the official architecture. Ask the people who use the information to demonstrate their ordinary work.
Agree the evidence needed for acceptance before setting a final cutover date. Finance may need control totals and open-item checks; operations may need a complete order or service request to work with migrated data.
Make mapping a business decision
For each field, record its source, destination, transformation, owner and validation method. Preserve identifiers as text where leading zeros matter. Resolve differences in codes, status values, dates and units explicitly.
| Illustrative source | Target | Decision | Acceptance check |
|---|---|---|---|
| Customer number 004512 | Legacy account ID | Preserve the original text | Check exact value and uniqueness |
| Status A, I or H | Account status | Map each source code to an agreed status | Explain every source value |
| Open invoice balance | Amount outstanding | Move the agreed open items at cutover | Reconcile totals by account |
| Site name | Standard location | Match to the approved location register | Resolve unmatched locations |
These are example mappings, not instructions for a particular financial system. Data owners need to approve the rules for their own records.
Rehearse a repeatable process
Run the migration through scripts or controlled import steps that can be repeated. Keep rejected records in an exception log with an owner and resolution. Silent omissions make a clean-looking result unreliable.
Use a full-volume rehearsal to establish timing and expose performance limits. Test documents, linked records and changes made during the migration window. Decide whether the final load needs a freeze, change capture or another controlled synchronisation method.
AWS's data validation guidance describes source-to-target comparison and its limitations. Automated validation helps, but business tests still need to establish that the migrated information supports the intended work.
Reconcile meaning as well as volume
- Explain differences in record counts, including approved exclusions and archives.
- Compare agreed totals, such as balances and quantities within consistent units.
- Check relationships between accounts, orders, invoices and supporting documents.
- Ask users to complete representative workflows with migrated records.
- Compare important reports for the same period and definitions.
Keep the reconciliation results and the acceptance decision together. A difference may be valid, but it needs an explanation that someone authorised has accepted.
Use a readiness check at each stage
Keep the check with the migration plan and record the evidence and approver against each stage. An approved exception should explain its effect and the action still required.
| Stage | Evidence needed before proceeding |
|---|---|
| Scope | A named sponsor, data owners, agreed entities and a clear archive decision |
| Inventory | Sources, volumes, attachments and downstream dependencies identified |
| Mapping | Approved transformations, matching rules, code mappings and relationships |
| Rehearsal | A repeatable full-volume run, timing and an owned exception log |
| Reconciliation | Counts, control totals, samples and complete workflow tests |
| Cutover | A rehearsed runbook, final update method and an authorised go/no-go decision |
| Retirement | Accepted operations, usable archive access and removal of redundant access |
For the final reconciliation record, use one row per entity with source count, target count, explained differences, relevant control totals, reviewer and acceptance date. Keep financial totals within the project's approved access controls.
If a material acceptance condition remains unmet, the sponsor needs to decide whether to pause or accept a defined limitation. Do not let a deadline silently make that decision.
Control cutover and retirement
The cutover runbook should name tasks, owners, checkpoints, communications and the conditions for stopping. Rehearse recovery as well as the successful switch. Once the new system accepts transactions, returning to the old one may require data reconciliation rather than simply restoring a backup.
Protect temporary exports, staging databases and test copies. Confirm retention obligations before retiring history, and remove copies when they are no longer required and lawful to retain.
Keep the old system available under an agreed fallback or archive arrangement until the relevant acceptance conditions are met. Google Cloud's migration principles provide further technical context. The practical standard is a result that the business can explain and operate, with every material exception accounted for.