Data Migration Checklist for Legacy Systems: How to Move Off Old Software Safely
Last updated: August 7, 2026 · By Joseph Olivas, Founder, MEAN Consultors · 9 min read
Nobody buys new software because they’re excited about moving their data. They buy it to escape a legacy system — and then discover that fifteen years of customer records, invoices, and half-documented custom fields are the real project. I’ve seen more modernization timelines blown up by data migration than by any amount of new-feature development. This checklist is the process we use at MEAN Consultors to make the move boring, which is exactly what a migration should be.
Why data migrations go wrong so often
Data migration has one of the worst track records in enterprise IT. Bloor Research’s well-known study of migration projects found that the majority run over time or budget — a finding that has been replicated in various forms for two decades. The causes are remarkably consistent, and almost none of them are technical exotica. Projects fail because nobody profiled the source data before committing to a timeline; because “we’ll clean it up during the migration” turned three weeks into four months; because the legacy system allowed things the new system forbids (duplicate emails, orphaned orders, free-text dates); and because reconciliation was an afterthought, so nobody could prove the migration was complete.
The pattern beneath all of these is the same: treating migration as a copy-paste operation instead of a data quality project with a copy step at the end. If your legacy platform is showing the strain — I’ve written about the warning signals in signs your legacy software is costing you more than a rebuild would — the time to start understanding your data is before you sign a contract for the new system, not after.
The seven phases of a safe migration
Figure 1: The seven-phase migration sequence — most failures trace back to skipping phases 1–3.
Each phase exists because skipping it has a specific, predictable cost. Here’s what each one involves and the checklist items that matter most.
Phase 1 — Audit and profile the source data
- Inventory every data store: the main database, spreadsheets living beside it, email attachments acting as records, and any shadow systems departments built.
- Profile each table: record counts, null rates per field, distinct values, date ranges, and formats. Automated profiling surfaces the surprises early.
- Identify which data is actually used. Legacy systems accumulate dead tables — migrating everything “just in case” multiplies cost for no benefit.
- Flag regulated data (PII, health, payment) that needs special handling in transit and at rest.
Phase 2 — Map fields and define transformation rules
- Build a field-by-field mapping document: source field → destination field → transformation rule → owner. This document becomes the migration’s single source of truth.
- Decide explicitly what happens to data with no destination — archive it queryably; don’t silently drop it.
- Define the rules for conflicts: which record wins when two sources disagree about the same customer.
- Get a business owner — not just IT — to sign off on every mapping decision that changes meaning.
Phase 3 — Cleanse at the source
- Deduplicate customers and vendors before the move; matching is far easier while you still know the legacy system’s quirks.
- Standardize formats — dates, phone numbers, state codes, currencies — according to the destination’s validation rules.
- Fix or quarantine records that will fail the new system’s constraints, and log every quarantined record for review.
Phases 4 and 5 — Pilot, then full dry run
- Pilot with a meaningful real subset (one branch, one year, one entity) end to end, and have actual users validate the result in the new system.
- Then rehearse the full migration against a production copy, timed. The dry run tells you whether your cutover window is realistic — and turns cutover weekend from an experiment into a rerun.
Phases 6 and 7 — Cutover and reconciliation
- Freeze changes in the legacy system (or capture deltas), run the migration, and validate before opening the new system to users.
- Reconcile programmatically: record counts by table, financial totals by period, and spot checks of high-value accounts. “It looks right” is not reconciliation.
- Keep the legacy system in read-only mode for an agreed retention period — it’s your audit trail and your safety net.
Where the effort actually goes
The most useful thing I can tell a business owner budgeting a migration is where the hours land. The cutover everyone worries about is a rounding error; the data quality work everyone skips is the majority of the project.
Figure 2: Typical effort distribution across MEAN Consultors migration projects — the cutover event itself is the smallest slice.
| Work stream | Typical share | What happens if you shortchange it |
|---|---|---|
| Data profiling & cleansing | 30% | Bad data imports as bad data; users lose trust in the new system in week one |
| Mapping & transformation rules | 25% | Meaning changes silently; reports disagree with the old system forever |
| Testing & validation | 20% | Errors surface in production, where they’re 10x more expensive |
| Pilot & dry runs | 10% | Cutover window blows out; weekend migration becomes a week of downtime |
| Post-migration reconciliation | 10% | Nobody can prove completeness; finance finds the gaps at quarter close |
| Cutover event | 5% | Rarely the problem — if the rehearsals happened |
- Roughly 55% of migration effort is profiling, cleansing, and mapping — work that happens before a single record moves.
- The cutover event is ~5% of the project; if it feels risky, the problem is missing rehearsal, not the event itself.
- Reconciliation must be programmatic — counts and totals, not visual spot checks.
Big-bang vs. phased migration: choosing your cutover strategy
The checklist above works for either cutover style, but choose deliberately. A big-bang migration — everything moves in one window — is simpler to reason about and avoids running two systems, but it concentrates all risk in one weekend. A phased migration moves one module, entity, or region at a time, which spreads the risk but requires the old and new systems to coexist, usually with temporary integrations between them.
Our rule of thumb: big-bang for smaller datasets with clean dependencies and a tolerant downtime window; phased for anything where a failed weekend would halt operations. Phased migration pairs naturally with the strangler fig approach to modernization, where the new system takes over one capability at a time — I’ve detailed that pattern in Strangler Fig Pattern: modernizing software without a risky big-bang rewrite. Either way, the migration plan should slot into a broader modernization sequence like the one in my legacy system modernization roadmap.
Frequently Asked Questions
How long does a legacy data migration take?
For a typical small-to-mid-size business system — tens to hundreds of thousands of records across a few dozen tables — plan for 6 to 16 weeks end to end, with most of that spent on profiling, cleansing, and testing rather than the move itself. Large ERP migrations run considerably longer. The honest answer requires profiling your data first; that’s why it’s phase one.
Should we clean our data before or during migration?
Before, at the source, wherever possible. Cleansing at the source lets you validate fixes in a system users already understand, keeps the migration scripts simple, and means a delayed migration still leaves you with cleaner data. Cleaning “in flight” inside transformation scripts hides business decisions in code nobody reviews.
What data should we not migrate?
Dead tables, abandoned modules, and records past their retention requirements are usually better archived than migrated. A good default: migrate what the business actively uses plus what regulation requires; archive the rest in a queryable format (even a read-only database copy) so nothing is truly lost.
What is the difference between a pilot migration and a dry run?
A pilot moves a real subset of data end to end so users can validate results in the new system — it tests correctness. A dry run executes the complete migration against a copy of production, timed — it tests completeness and whether your cutover window is realistic. You need both; they catch different failures.
How do we verify a migration was successful?
Programmatic reconciliation: compare record counts per table, financial totals per period, and key aggregates (open orders, account balances) between source and destination, plus manual spot checks of your highest-value accounts. Define the acceptance thresholds and the rollback triggers in writing before cutover night.
MEAN Consultors’ software development team handles profiling, migration, and modernization as one engineered project — so cutover weekend is a rerun, not a gamble.