✦ Legacy systems and migration
Data migration: how to move years of records without losing any
Data migration is the craft of moving years of records from an old system into a new one without losing, duplicating or corrupting any of it. It's slower and more manual than most timelines assume, and it's where most system replacement projects actually go wrong.
Haystak · 12 August 2026 · Updated 12 August 2026 · 9 min read
Data migration means taking the customer, order, stock, financial and historical records held in an old system and moving them accurately into a new one, so the business can operate on day one without a gap in its history.
It sounds mechanical, but the difficulty is almost never technical. It's that source data is inconsistent, duplicated and sometimes simply wrong in ways nobody noticed while the old system was quietly working around them. Migration is where that gets found and fixed, or where it gets carried forward and causes problems for years.
How this is different from replacing the system itself
If you're deciding whether to replace an old system at all - weighing up cost, risk and timing - our guide to legacy system migration covers that decision. This page assumes the decision is made and focuses purely on the craft of moving the data itself: profiling it, cleansing it, mapping it, reconciling it and verifying it landed correctly.
The stages of a proper migration
| Stage | What happens | What goes wrong if it's skipped |
|---|---|---|
| Profiling | Assess what data exists, its quality, and where it lives | Nasty surprises discovered mid-migration instead of before it |
| Mapping | Match every field in the old system to its home in the new one | Data lands in the wrong place, or fields silently get dropped |
| Cleansing | Fix duplicates, inconsistent formats, missing or contradictory values | Bad data moves cleanly into the new system and looks trustworthy |
| Migration (the move itself) | Extract, transform and load the data, usually in stages | Doing it all at once with no rehearsal, and no way back if it fails |
| Reconciliation | Compare totals and record counts between old and new | Missing records go unnoticed until someone needs them |
| Verification | Spot-check individual records for accuracy, not just totals | Records that reconcile in total but are wrong in detail |
| Cutover | Freeze the old system, run the final migration, switch over | Data entered in the gap between final extract and go-live gets lost |
Profiling: knowing what you're actually moving
Before writing a single mapping rule, look properly at the source data. How many customer records are there, really, once duplicates are accounted for? How far back does usable order history go? Are stock counts in the system trustworthy, or has the warehouse been working around known discrepancies for years?
This is the stage most timelines skip or rush, and it's the one that most reliably predicts how long the rest of the migration will actually take. A quick sample of a few hundred records, checked by hand, tells you far more than assuming the data is fine because the old system never complained.
Mapping: where every field ends up
Old and new systems almost never structure data identically. A single 'address' field might need splitting into several; a status field with six legacy values might collapse into three in the new system, and someone has to decide the rule for that collapse. Mapping should be documented explicitly, field by field, and agreed with someone who understands both what the old data means and how the new system will use it.
Cleansing: the stage that takes longest and matters most
Duplicate customers under slightly different names, suppliers with several inconsistent code formats, stock items with descriptions that drifted over years of manual edits - all of this has to be resolved before migration, not after. Cleansing is manual, judgement-heavy work. Software can flag likely duplicates or inconsistencies, but deciding which of two customer records is the correct one usually needs someone who knows the business.
- Deduplicate customers, suppliers and stock items using more than one matching rule - name alone will miss variants and typos.
- Standardise formats for dates, addresses, phone numbers and codes before mapping, not after.
- Decide explicitly what happens to genuinely incomplete records: migrate with gaps flagged, or leave behind and handle manually.
- Keep a log of every cleansing decision, so questions after go-live can be traced back to a reason rather than guessed at.
Migrating in stages, not one leap
A full rehearsal migration into a test environment, well before the real cutover, is what turns a risky one-shot move into a controlled process. Run it, check it, fix what's wrong, and run it again. By the time the real cutover happens, there should be no surprises left, because they've already been found and fixed in rehearsal.
Large or historic datasets are often migrated in phases - recent, actively-used records first, older archival history afterwards - so the business can go live without waiting for every year of history to be perfect.
Reconciliation and verification
Reconciliation checks that nothing was dropped: record counts, financial totals, stock quantities matching between old and new. Verification goes further and checks that individual records are actually correct, by sampling a meaningful number and checking them field by field against the source. Both are needed; neither replaces the other.
Cutover: the moment of highest risk
Cutover is when the old system is frozen, a final extract is taken, and the business switches to the new one. The main risk is the gap between that final extract and go-live - anything entered into the old system during that window can be lost if it isn't accounted for. Planning cutover for a genuinely quiet period, and having a clear process for capturing anything entered during the freeze, closes that gap.
If your migration is part of a wider ERP implementation, the migration timeline needs to sit alongside configuration and testing from the start, not be treated as a separate workstream bolted on at the end. Get in touch if you're planning a migration and want an honest view of how long it will really take.
✦ Where this fits
More on this from us: legacy software modernisation.