Direct answer
A data migration is a set of decisions, and the loading itself is the smallest part. The work lies in deciding what to move, what to leave behind, how old fields map to new ones, which quality problems to fix on the way and how you will prove that nothing was lost. A plan that answers these before any data is copied is what separates a controlled move from a scramble. What is feasible depends on what the old system can export and on how it stores its data, so we do not claim that any particular system can be migrated; that is established by inspecting it. The sections below give the plan structure to fill in. If your source is a set of spreadsheets, see spreadsheet to database migration; for a CRM source, CRM data mapping for migration.
1. Source inventory
List everything the old system holds and everything that feeds it or reads from it. For each item, note where it lives, who owns it, how it can be exported and how tidy it is. Include the parts people forget:
- Attachments, documents and images stored outside the main database
- Reports and exports that other people rely on
- Scheduled jobs and automatic emails
- Spreadsheets kept alongside the system as a workaround
- Connections to other systems, in both directions
2. What moves and what stays
Not everything deserves to move. For each data set, decide whether it is migrated in full, migrated in part, archived in a readable form or left behind. A rule such as 'only active customers and open orders' is easier to reconcile than 'whatever looks useful'. Write the rule and its owner. Moving everything out of habit brings old clutter into a new system and makes every later step harder.
3. Mapping
Produce a mapping table with one row per source field: where it goes, the format change, whether the target requires it and what to do when it is empty. Include lookup values, statuses and identifiers. Note fields that have no home in the new system and decide their fate explicitly. Have the people who use the data review the mapping, because they know what a field is really used for, which is often different from its name.
4. Cleansing rules
Decide which problems are fixed before the load and who fixes them. Typical rules cover duplicates, inconsistent spellings, missing owners, invalid dates and free-text values that should be from a list. Write each rule so that two people applying it get the same result. Keep the original data untouched and do the cleaning on a copy, so any decision can be reversed. Rules that need business judgement belong with a business owner, not a developer.
5. Trial loads
Load a sample first, then a full rehearsal into a non-production target. Review the result with the people who know the records. Every trial should produce a list of problems and a fix for each, and the rehearsal should be repeated until the list is short and understood. A rehearsal also shows how the process behaves on real volume and what the cutover will involve.
6. Reconciliation
Reconciliation is how you prove the migration worked. Agree the checks before loading:
- Counts: the number of records in each set, source against target, with every difference explained
- Totals: values that should add up, such as balances or quantities, compared on both sides
- Keys: every source identifier is present in the target, or listed as intentionally excluded
- Samples: a set of records chosen by the business, compared field by field
- Relationships: records still point to the right parents and children
7. Cutover
The cutover plan says how you switch from old to new. Decide whether it is a single moment or in stages, when the old system stops accepting changes, how changes made during the switch are captured, who is on hand and what the criteria are for proceeding or reversing. Agree the rollback option in advance and know what it would cost you to use it. A switch with no way back is a bet, not a plan.
8. Keeping the old system
Decide how long the old system stays readable after the switch and what is checked before it is retired. Read-only access is a common safeguard. Note who may access it, how its data will be preserved if a licence ends and how any legal retention requirement is handled; have a qualified adviser confirm what you must keep. Do not retire it until reconciliation is signed off and people have worked real cases in the new system.
Questions
Can you migrate any legacy system?+
We do not claim that. Feasibility depends on how the system stores data and what it can export, which we establish by inspecting it before agreeing scope.
Should we migrate all historical data?+
Usually not. Decide what people actually use, migrate that, and archive the rest in a readable form. A clear rule is easier to check than a broad one.
How do we know the migration worked?+
By reconciliation agreed before the load: counts, totals, keys, sampled records and relationships, with every difference explained and signed off.
What if something goes wrong at cutover?+
That is what the rollback plan is for. Agree it in advance, along with the criteria that would trigger it.
Who should own the cleansing decisions?+
A business owner of the data. A developer can apply the rules, but should not have to invent them.