Migrating data to new software: a practical guide

Switching software is a strategic decision. But the real complexity isn't in choosing the right tool — it's in what you're going to do with your existing data. Years of customers, orders, histories and stock records: if the data migration is poorly prepared, you arrive in the new system with incomplete, duplicated or outright lost data.

Direct answer: a successful data migration is won before the cutover, not on the day itself. Audit, cleanup and a mapping validated with your business teams are the three conditions that make the difference between a smooth launch and weeks of painful corrections.

The key takeaways

Data migration is often the most underestimated phase of a software change. It isn't a simple copy-paste: it's a project in its own right, with its own steps, its own risks and its own owner. Most projects that go off the rails do so here — not in configuration, not in training.

The good news: the errors are predictable. They almost always come back to the same causes — degraded data, rushed mapping, a hasty cutover. Preparing for each one, in the right order, is enough to avoid most problems.

Why data causes problems during migration

When a business changes software, attention naturally turns to the new tool's features. Data moves to the background — until the team realises its true condition.

The sources of complexity are the same in almost every project:

• Heterogeneous data: the old software, Excel exports, local files, sometimes paper notes.
• Degraded data: duplicates, empty fields, inconsistent formats, outdated addresses and contacts.
• Non-obvious mapping: fields in the old system don't always correspond to fields in the new one — and two identically labelled fields don't necessarily cover the same reality.
• History to arbitrate: taking everything over creates noise; taking only the recent past loses traceability. That boundary is a business decision, not a technical one.

The longer the company has operated with its previous tool, the heavier this phase becomes. That's structural — and it's no reason to skip over it.

The 6 steps of a successful migration

1. Audit your existing data

Before talking about migration, export a representative sample of your data and assess its condition: completeness, consistency, duplicates, critical empty fields. This audit determines everything that follows — and often reveals surprises.

Questions to ask: which data is actually used? How far back does the active history go? Do you have data spread across several sources — software, Excel, email, paper?

2. Clean and improve data quality

This is the longest and least glamorous step — but the most decisive. Migrating dirty data means starting the new software with the same problems as before, only worse.

Cleaning priorities: removing duplicates, normalising formats (postcodes, phone numbers, dates), filling in missing mandatory fields, archiving or deleting genuinely obsolete data.

This work can often be partially automated. A processing script or ETL (Extract, Transform, Load) tool saves you considerable time if your volumes are significant.

3. Field mapping

Mapping is the correspondence table between the old system and the new one: which field comes from where, with whatever transformation rules apply.

This work must be done with key users — not just the technical team. They are the ones who know how data is actually used, and therefore which equivalences are valid or not.

Document the mapping in a shared spreadsheet before starting the import: it's your reference in case of disputes or anomalies discovered after cutover.

4. Dry-run migration and acceptance testing

Before the definitive migration, import a representative dataset into the new system and verify the result: did the data land in the right places? Are calculations consistent? Are the relationships between objects (customers ↔ orders, items ↔ suppliers) intact?

This step reveals mapping errors before they affect your real operations. Involve future users in testing: they will spot the business anomalies that purely technical testing will miss.

5. Cutover

The cutover is the moment when you stop entering data in the old system and start in the new one. It's the point of no return.

Two approaches exist:

• Hard cutover: on a fixed date, everyone switches to the new system. Simple to organise, but risky if problems arise.
• Transitional parallel running: for a few weeks, both systems coexist. Energy-intensive, but a genuine safety net.

For most SMEs, a parallel running period limited to 2 to 4 weeks is the right compromise. It lets you detect and fix residual errors without exposing operations to total risk.

6. Post-migration validation

In the first few weeks, organise regular check-in points with user teams. Anomalies at this stage are normal — the challenge is to address them quickly, before they affect critical data (invoicing, stock, payroll).

Designate one validation owner per module. Without a clear designation, corrections are delayed and errors accumulate silently.

Reference table — Pitfalls and how to avoid them

Common pitfall	What it costs	How to avoid it
Migrating without cleaning	Duplicates and calculation errors from day one	Audit + cleanup before any import
Mapping done without users	Mis-transposed fields, loss of business meaning	Involve operational staff from the start
No dry-run migration	Errors discovered in production	Test on real data before cutover
Hard cutover with no safety net	Operations blocked if a problem arises	Parallel running for 2 to 4 weeks
Full history migrated	Data noise, slowness, confusion	Define a historical cutoff date
No designated owner	Unresolved anomalies, late escalation	One point of contact per module from day one
Old system shut down too quickly	Loss of safety net	Keep read access for at least 3 months

What migration reveals about your data

A migration is often the moment you see your data's true condition — and it can be a shock. Customer records never updated for years, obsolete product references, duplicates nobody had noticed.

It's uncomfortable, but useful. If you treat migration as a foundational project — rather than a simple copy-paste — you arrive in the new system with a clean, reliable base ready to support the business process automation you plan to implement next.

Questions to ask your provider before migrating

Data migration isn't something to improvise on the software publisher's side either. Before signing, ask these questions:

• Does the new tool have a native import facility? In what format (CSV, XML, API)?
• Is data migration included in the offer, or charged separately?
• What data can the tool receive, and under what format or volume constraints?
• Has the provider already migrated from your current tool? Can they provide references?

These questions sometimes change the decision. A functionally excellent tool that creates problems on import can turn out more expensive than a slightly less feature-rich tool that's better suited to your context.

To choose the right software beforehand, see our guide CRM, ERP or EOS: choosing based on your SME's main constraint. If you're at the kickoff stage of an industrial ERP project, our article ERP for industrial SMEs: where to start gives you a step-by-step method. And if you're weighing a market solution against custom development, the decision framework is here: off-the-shelf or custom software.

Frequently asked questions (FAQ)

How long does a data migration take?

The timeframe depends on volume, initial data quality and mapping complexity. For an SME of 20 to 50 people, count anywhere from a few weeks — simple migration, clean data — to several months, if the history is large, sources are multiple and the cleanup workload is heavy. Software configuration and training add to this timeline.

Should you migrate everything or start from scratch?

Both options are valid depending on the context. Starting from scratch is tempting but risky if you lose traceability of historical records (invoicing, warranties, customer history). In most cases, you migrate the current data — active records — and archive older history in read-only rather than deleting it.

Who should lead the migration inside the business?

Migration isn't a purely IT project. It must be led by a business owner — someone who knows your data in its real usage — supported by the technical provider or IT team. Without a business anchor, mapping errors go unnoticed until they cause a production problem.

What if data is lost during migration?

Keep a complete backup of your source data until the migration is fully validated — at minimum three months after cutover. Never shut down the old system immediately after switching. It's your safety net, and it has saved many a project.

Does the software provider handle the migration?

It depends. Some publishers include import tools or support services in their offer. Others charge data migration as an add-on. Ask the question explicitly before signing — and request a test import using a sample of your own data before committing to anything.