How to reconcile a legacy-system migration without losing business relationships
A historical-data migration should preserve record identity, relationships, meaning and usability. Matching row counts is only a starting point: each order must still lead to the correct customer, lines, files and processing history.
On this page5 sections
Use a complete business record and its relationships as the acceptance unit for a legacy-system migration. An order must remain connected to its own lines, customer, attachments and processing history, with historical meaning intact. In a software development scope (Chinese), specify migration coverage, old-to-new identities, discrepancy handling and cutover conditions separately. A successful database import does not establish that historical business records are usable.
Identify the objects and their dependencies
Start with a representative record that the team is authorized to examine. Follow its customer, contract, order, lines, fulfillment records, files and approval trail to their actual storage locations. Use the objects that exist in this business rather than imposing this entire list. Separate records that must remain actionable from read-only history and excluded archives. For exclusions, record the reason, retention location and retrieval method.
| Object | Relationship to retain | Suggested evidence |
|---|---|---|
| Orders and lines | Old order and line identities mapped to new records | Line ownership, grouped quantities and amounts |
| Customers and documents | Distinct customers with identical names remain distinct | Business-entity codes and historical names |
| Attachments and versions | Files linked to the right record and version | File inventory, content verification and opening checks |
| Processing history | Original action, actor, time and state | A readable timeline and an explicit missing-item list |
Explain transformations instead of silently rewriting history
When the replacement allocates new internal identifiers, retain the source system, original key and destination key. Two legacy systems may contain the same order number, so an identifier also needs its original scope. An inactive customer or former employee should not automatically become a current entity with the same name. Keep historical display identity separate from the permissions of current user accounts.
Document every status consolidation, unit conversion, time-zone treatment and empty-value substitution. If the old state was partially completed and the new system lacks that state, preserve the original value or obtain an explicit business mapping; do not silently mark it completed. Check file content and relationships as well as counts. Matching filenames do not prove that files are identical. Database and runtime compatibility belong in a separate deployment adaptation review; passing that review does not validate the historical content.
Reconcile at three levels during a trial migration
First compare counts and applicable amount or quantity totals by organization, year and business state. Then check parent-child links, orphaned lines and duplicate mappings. Finally, have business users open representative records and either retrieve their history or continue the permitted work. Equal totals can hide offsetting mistakes in two different orders. Fix the currency, precision and rounding rules before using financial amounts as comparison evidence.
The AWS DMS validation documentation describes comparing corresponding source and target rows and reporting mismatches, with primary-key or unique-index requirements. Such results can support a migration review. The additional relationship and file checks recommended here require their own design; a tool's validated status does not establish that they passed.
For each discrepancy, record source and target identities, compared fields, both values, cause, owner and retest outcome. Label pre-existing data defects rather than quietly correcting them during transfer. Keep unverified records outside the passed count. This makes an exception review actionable: the reviewer can inspect the affected business record instead of accepting a general explanation that some legacy data was inconsistent.
Give the final change set a traceable boundary
A completed trial does not freeze the source. Orders may still be created, amended or cancelled. Before cutover, agree either a stop-write point for the relevant operations or a verifiable change watermark. Apply changes through that boundary, then repeat the critical comparisons. Retain the source snapshot, transformation-rule version, migration batch and validation report so another reviewer can reproduce the meaning of the result.
This establishes completeness of historical transfer. Ownership of ongoing writes during parallel operation is a separate decision. If the replacement has already accepted new business, a rollback must address those new records before traffic returns to the old system. An entry-point switch alone cannot settle their ownership. The rehearsal should identify when to pause and the actual actions assigned to the responsible people.
Define blocking discrepancies and the future of archived records
- A critical record is missing, duplicated or attached to the wrong parent, without an explained resolution.
- A batch contains unverified records whose scope is not separately identified.
- Files cannot be opened, point to the wrong record, or expose historical material to an unauthorized user.
- The final increment has no clear boundary, leaving new or cancelled records around cutover unexplained.
These are suggested blocking conditions; the business owner should confirm their impact and applicability. Retained legacy defects need a searchable exception list and an agreed handling plan. For history that becomes read-only, decide whether later corrections, supplementary files or links to new documents are still required, and preserve references to the original record. Include mappings, scripts and retest evidence in the source-code and project handover so the next team can explain where a historical transaction came from.