A new system is only as useful as the data inside it. Customers without correct contact details, products with wrong prices, assets without service history or open orders that never made it across can undermine a well-built system in its first week. Data migration — moving information from spreadsheets or old software into the new system — is often underestimated, started late and rushed at the end. This guide explains how to plan it properly.
Why migration deserves its own plan
Migration is not a one-click export and import. Old data is often incomplete, duplicated or inconsistent. Field formats differ between systems. Some information lives only in notes, file names or people's heads. And the business keeps running during the project, so data changes up to the last moment. Treat migration as a workstream with an owner, a timeline and acceptance criteria, starting early in the project.
Step 1: Inventory your data
List every type of data the new system needs and where it lives today:
- Master data — customers, sites, contacts, suppliers, products, prices, assets, employees.
- Open transactions — open orders, jobs in progress, unpaid invoices, active contracts, stock on hand.
- History — past jobs, orders, invoices, service records, inspections.
- Documents — certificates, drawings, photos, signed reports.
For each, note the source (which system, spreadsheet or folder), the approximate volume and who knows it best.
Step 2: Decide what to move
Moving everything is rarely necessary and often harmful. Ask for each data type: will users need it in the new system, and how often? Common decisions:
- Migrate all active master data and open transactions.
- Migrate recent history (for example, the last two or three years) where users need it for service, warranty or analysis.
- Keep older history in a read-only archive or export, searchable if needed.
- Leave behind inactive customers, obsolete products and test records.
Write these decisions down and agree them with the business owners of the data.
Step 3: Clean before you move
Migration is the best chance you will get to fix years of accumulated problems. Typical cleaning tasks:
- Merging duplicate customers, suppliers and products.
- Standardising names, addresses, phone numbers and units.
- Filling missing mandatory fields, such as tax details or asset locations.
- Correcting obviously wrong values, like negative stock or impossible dates.
- Marking inactive records so they are not migrated.
Cleaning takes business time, not just technical time. Assign people and deadlines. Clean in the source where possible, so trial migrations pick up the improvements automatically.
Step 4: Map old to new
For every field in the new system, define where its value comes from: which source field, with what transformation. Categories, statuses, tax codes and units usually need lookup tables to translate old values to new ones. Decide what happens to values that do not fit — a default, a flag for review or rejection. The mapping document becomes the specification for the migration scripts and the checklist for validation.
Step 5: Run trial migrations
Never migrate for the first time on go-live day. Run at least two or three trial migrations into a test copy of the new system. Each trial reveals problems — mapping gaps, bad data, performance issues — which are fixed before the next. By the final trial, the process should be repeatable, timed and documented.
Step 6: Validate thoroughly
Validation has two layers:
- Technical checks — record counts per type, totals (such as outstanding balances and stock quantities) compared between old and new, mandatory fields filled, links between records intact.
- Business checks — users open a sample of records they know well and confirm they are correct and complete; they run their daily tasks on migrated data; key reports match the old system's figures.
Agree acceptance criteria in advance, such as "outstanding receivables match exactly" or "all active assets have a location and next service date".
Step 7: Plan the cut-over
The cut-over is the moment you switch from old to new. Plan it like a small project:
- Choose a quiet period — a weekend, month-end close, or a low season.
- Freeze changes in the old system at an agreed time.
- Run the final migration, validation and sign-off.
- Enter any transactions made during the freeze into the new system.
- Switch users over, with support people available.
- Keep the old system available read-only for reference.
Have a fallback plan: what you will do if validation fails, and who decides.
Documents and attachments
Files such as certificates, photos and drawings are often scattered across folders with inconsistent names. Decide which files must be linked to records in the new system, define a naming or matching rule, and test the matching on a sample. Large volumes of files take time to transfer; plan for it.
Common mistakes
- Starting migration planning only weeks before go-live.
- Assuming data is cleaner than it is.
- Migrating everything, including years of irrelevant history.
- Skipping trial runs and validation.
- Leaving data checks only to the technical team.
- Switching off the old system immediately, with no read-only access.
Example
An equipment service company moved from an old desktop application and several spreadsheets to a new web-based service system. The inventory showed 9,000 customer records, but after merging duplicates and removing customers inactive for five years, 4,200 were migrated. Asset and service history for the last three years was migrated; older records were exported to a searchable archive. Three trial migrations exposed missing site addresses and inconsistent product codes, which the service coordinators fixed in the source data. The final cut-over happened over a weekend, and the open AMC visits, outstanding invoices and spare-part stock matched the old figures exactly.
Summary
Successful data migration starts early, moves only what is needed, cleans data before moving it, maps every field carefully and proves the result through trial runs and validation by the people who use the data. A planned cut-over and read-only access to the old system complete the job. Done this way, users trust the new system from day one.
Frequently asked questions
Do we need to migrate all our historical data?
Not always. Active master data and open transactions are essential. For older history, you might migrate a summary, keep a read-only archive, or migrate only the last few years.
How long does data migration take?
It depends on the number of data types, data quality and how many trial runs are needed. Cleaning and validation usually take longer than the technical transfer itself.
Can data be extracted from very old software?
Usually, through exports, reports, database access or, as a last resort, structured copying. Feasibility depends on the old system and the access available.
Who should check the migrated data?
The people who use it every day. Technical checks confirm counts and totals; users confirm that records make sense and that they can do their work.
What if we find errors after go-live?
Plan for it. Keep the old system or archive available read-only for a period, log corrections, and have a quick process to fix issues as users report them.
