Legacy Data Migration Plan: What to Clean, Move, Archive and Verify

A legacy data migration should decide what to move, transform, archive or delete before building the final import. Profile real data, preserve stable identifiers, run repeatable trial migrations and reconcile business totals and relationships. The new system should not inherit every historical inconsistency by default.

This guide applies beyond CRM to operational databases, case systems, portals and line-of-business applications.

Define the migration outcome

State which new workflows require which historical data. Identify legal, contractual and reporting needs with appropriate advisers. Set the cut-off date and success evidence.

Do not define success as “all rows imported”. A useful result may move active records and essential history while providing controlled archive access to older material.

Inventory every source

Legacy information may exist in databases, spreadsheets, document shares, exports, email and hidden scripts. Record owner, format, volume, encoding, identifiers, update frequency and access.

Keep immutable source extracts and document how they were produced. If the old system remains active, plan delta changes.

Profile before mapping

Measure missing fields, duplicates, invalid values, orphan relationships, unexpected encodings, dates and volumes. Sample with people who understand the data.

Profile attachments and large objects separately. They often determine transfer time and failure behaviour.

Classify data

Mark data:

• required for live operation;
• useful historical context;
• required in a controlled archive;
• duplicated or obsolete;
• sensitive and access-restricted; or
• pending a business/adviser decision.

Never delete based on a technical assumption alone. Record approvals.

Design the target model

Map entities, relationships, statuses and ownership. Use stable keys and constraints. Define which old fields split, combine, normalise or remain only in archive.

The guide to Database Design Mistakes helps avoid reproducing weak names-as-keys, free-text categories and missing history.

Create a mapping specification

For each field, record source, target, transformation, allowed values, default policy, owner and exception handling. Version it with the migration code.

Avoid manual spreadsheet edits that cannot be repeated. Create an exception report for business resolution.

Preserve relationships and lineage

Keep source identifiers in controlled target fields or a crosswalk. Load parent records before children and validate associations.

Record the source extract, transformation version and target ID. This makes reconciliation and later support possible.

Rehearse with representative data

Run trial migrations into a safe environment. Include awkward records, international characters, large attachments, duplicates, departed owners and incomplete states.

Measure extraction, transformation, load and reconciliation time. Refine the cut-over estimate from full-volume evidence where possible.

Reconcile at several levels

Use:

• source/eligible/imported/skipped/failed counts;
• control totals and date ranges;
• relationship counts;
• required-field completeness;
• attachment/file checks;
• business reports; and
• user workflow samples.

Have named business owners sign off critical areas. A technically successful import can still change the meaning of a status or amount.

Plan cut-over and rollback

Define freeze, final extract, transformation, load order, reconciliation, approval, go-live and communication. State rollback conditions and authority.

Back up source and target. Understand what happens to new records created after go-live if rollback occurs.

Provide archive access

An archive should be searchable enough for its purpose, permissioned, retained and supported. A hard drive in a cupboard is not a controlled archive.

Document how authorised users retrieve evidence and how export/deletion requests are handled.

Secure the migration

Use least-privilege access, encrypted transfer and controlled workspaces. Avoid personal data in logs and ad hoc copies. Remove temporary credentials and files after verified completion according to policy.

Post-launch closure

Monitor user corrections, missing data and integration failures. Keep scripts, mappings and crosswalk until formal closure. Make the old system read-only where appropriate, then decommission only after dependency and archive checks.

The CRM Data Migration Checklist provides product-specific detail, while Legacy System Modernisation helps choose the broader route.

Close with measurable evidence

Keep the migration team and source environment available for an agreed stabilisation period. Track rejected records, user-reported discrepancies and integration mismatches in one triage queue. Apply corrections through controlled scripts or application workflows rather than undocumented database edits.

After business sign-off, archive the mapping, transformation code, reconciliation evidence, approvals and final source extract according to retention policy. Revoke temporary elevated access and destroy intermediate files securely. Record which legacy system remains accessible, for how long and who can approve retrieval.

Report more than a completion percentage. Useful measures include records accepted and rejected, unmatched references, duplicate resolution, mandatory-field completeness and reconciled financial or operational totals. Sample complex records with business owners and verify that priority journeys work in the target system.

The final question is not “did every row move?” It is “can the new process operate correctly, can discrepancies be explained and can authorised historical information still be found?”

That evidence should remain available to operations, audit and future improvement teams after the delivery project closes.

Frequently asked questions

Should all historical data move?

Usually not. Move what the new workflow, reporting and obligations require; archive the rest responsibly. Carrying obsolete data increases cost and risk.

Can the migration be performed once?

The production cut-over may be once, but the process should be rehearsed repeatedly. Repeatability exposes manual gaps and gives realistic timing.

Who signs off data?

Technical teams verify transformations and integrity; business owners verify meaning and usability. Both are required.

AUZtec Innovations delivers legacy modernisation, databases and business integrations. We treat mapping, code and reconciliation as durable project assets so the migration can be explained rather than merely declared complete.