Switching ERP software without losing data is possible, provided you treat the migration as a project in its own right and not as the last chore before go-live. If you are considering switching ERP software, the short answer is this: take an inventory of your data, clean it before moving it, test the migration in a test environment, compare totals between the old and new system and keep a plan ready for going back.

The rest of this article explains how to do that in practice. It is written for the owner of a small or mid-sized company who knows the current system can't cope any more but has one specific fear: ending up with years of customers, orders, invoices and price lists gone or wrong. The fear is well founded, but it almost always applies to improvised migrations, done with an Excel export on Friday and an import on Monday.

When switching business software makes sense: the signs not to ignore

Before talking about data migration, it's worth asking whether you really need to change systems. Sometimes it's enough to configure the tool you already have better. Other times it isn't, and the signs are easy to recognise.

The first is that data lives outside the system: important information sits in parallel Excel sheets, in emails, in paper diaries, and the software records only part of what happens. The second is double entry. The technical office writes up a job, accounts re-types it to invoice it, and every step is an opportunity for error.

Then there is software that no longer fits the way you work. You've added a service, a sales channel or a site, and the system forces you into workarounds to handle them. Or it doesn't talk to anything else: e-commerce, CRM, app for technicians, and every connection is a manual export. It also happens that the vendor has stopped developing the product, or that every change takes disproportionate time and money. The last sign is the most telling: to get a reliable figure you have to ask one person, the only one who knows how it really works.

If you recognise yourself in two or three of these points, the problem is no longer configuration. We covered this in more depth in 5 signs your company needs custom business software.

A concrete example. Before the Dabe Connect project, Dabe Service, an Italian building services company working on residential and industrial systems with dozens of field technicians, scheduled jobs through phone calls, emails and Excel sheets, while technicians filled in paper reports to bring back to the office. Information was duplicated between the technical office and accounts. It's the typical case where changing systems pays off, and also the one where data migration needs the most care, because the data is scattered across many different places. The full story is in the Dabe Connect building services case study.

How to prepare the switch

Preparation is the least visible part and the one that matters most. A successful data migration is decided here, weeks before switchover day.

Data inventory: what you have and where it is

Start with the list of sources. The old system is the first, but rarely the only one. Usually there are also:

shared Excel files, and the ones on someone's desktop;
the accounting software, if separate;
the CRM or the sales contact list;
folders with documents, technical data sheets, photos, PDFs;
any vertical software for warehouse, workshop or after-sales service.

For each source, note who uses it, how up to date it is and whether it is the "source of truth" for that data. It's common to discover that the same price list exists in three different versions.

Master data: the heart of the ERP data migration

Customers, suppliers, items, equipment or vehicles: everything else rests on master data. If it's wrong, the orders and invoices linked to it will be wrong too. Check in particular:

missing or mistyped VAT numbers and tax IDs;
incomplete addresses, especially delivery addresses and operating sites;
contacts for people who no longer work for the customer;
customers inactive for years who don't need to be carried over as active.

Duplicate codes: the problem nobody sees until it blows up

Duplicate codes are the error that surfaces after go-live. The same customer entered twice ("Smith Plumbing Ltd" and "SMITH PLUMBING LIMITED"), the same item with two codes because a colleague couldn't find it. In the old system they coexisted; in the new one they produce split balances, distorted statistics and wrong stock levels.

Before the migration you need a clear rule: which code survives, how histories are merged, what happens to documents linked to the deleted code. It should be decided by the people who use the data every day, together with whoever handles the technical side. Leaving it to the IT person alone is a mistake.

Cleaning: better before than after

The temptation is to bring everything over and fix it later. That never happens, because after go-live nobody has time. Cleaning is done beforehand: consistent date formats, consistent units of measure, mandatory fields filled in, non-standard values corrected. Much of the work can be automated with check scripts that flag anomalies. The decisions remain yours.

Field mapping

The last piece of preparation is the map: for each field in the old system, where it ends up in the new one. "Company name" in the Excel file becomes "Business name" in the Customers table; the notes field where the office wrote payment terms becomes a structured field. Every field without a destination is a decision to make: archive it, discard it or create a new place for it.

Data migration checklist

You can copy this checklist and use it as an outline for your own project.

Preparation

List of all data sources (business software, Excel, accounting, CRM, folders)
For each piece of data, the designated source of truth
Decision on how much history to bring over (all of it, the last few years, open documents only)
Internal contact person for each area (sales, purchasing, warehouse, accounts)

Data quality

Customer and supplier records verified (VAT number, tax ID, addresses)
Duplicate codes identified and merge rule agreed
Obsolete items marked as inactive or excluded
Formats standardised (dates, amounts, units of measure)

Mapping and testing

Field-by-field map approved by the contact people
At least one full trial migration on a staging environment
Comparison of totals between old and new system
Spot checks by users on real cases

Switchover

Go-live date chosen in a low-workload period
Old system read-only from the moment of switchover
Full, verified backup before the final migration
Written rollback plan, stating who decides and by when
User training completed before go-live

Phased migration: staging and comparing totals

A well-run data migration is a sequence of rehearsals, each one closer to the real thing. Planning it as a single leap is an unnecessary risk.

Rehearsals on a staging environment

Staging is a copy of the new system, separate from the one you'll actually use, where you load real data without risk. This is where you run the full trial migration, with the same scripts, the same data and the same order as the final one. It serves three purposes:

finding mapping errors before they affect day-to-day work;
measuring how long the switchover really takes, so you can choose the right day;
letting your staff try the new system with their own customers and items, not with dummy data.

There is usually more than one rehearsal. The first brings out the big problems, the second the details, the third confirms everything is in order. Selli applies the same principle to every project: each two-week sprint is released to staging first, the client tests and approves, and only then does it go to production.

Comparing totals

Opening a few records at random proves nothing. To know that all the data has arrived and is correct, you compare totals between the old and new system:

number of active customers and suppliers;
number of items and stock value at the switchover date;
revenue by year and by customer across the migrated history;
open balances: receivables from customers, payables to suppliers, due dates;
open documents: orders to fulfil, quotes in progress, scheduled jobs.

If a total doesn't match, you find the cause before moving on. Often it's a duplicate code that slipped through or a document with an unusual format. Better to find it in staging than at month end, when accounts are closing the books.

How much history to bring over

Migrating everything isn't always worthwhile. A common choice is to bring complete master data, open documents and the last few years of history into the new system, and leave the rest available in a read-only archive. This cuts both the cleaning work and the risk. For tax documents already issued, check with your accountant how retention and access should be handled.

Parallel running and the rollback plan

On switchover day the old system isn't turned off. It is made read-only: you can look things up, but nobody writes to it any more. That way nobody enters an order in the wrong place and you always have a reference for checks.

Running side by side

In the first weeks after go-live someone will go back to double-check a figure in the old system. That's fine, as long as everyone is clear that work happens only in the new one. In some cases it makes sense to roll out the new system one department or function at a time, for example master data and scheduling first, then invoicing. The process takes longer, but each individual step weighs less on operations.

The rollback plan

Rollback is plan B for when something goes seriously wrong. It's almost never needed, but it has to be written before go-live. It should state:

which problems justify going back to the old system and which get fixed on the fly;
who makes the decision;
how long after go-live it's still possible to go back;
how data entered in the new system in the meantime will be recovered.

Having it in writing also changes the mood in the company: people face go-live with less anxiety when they know there is a way out.

User training: the part people forget

You can migrate perfect data into a system nobody knows how to use and the project will still fail. Training happens before go-live, on staging, with the company's real data.

It works better by role than with everyone in the same room, because the people who write quotes, schedule jobs and invoice need different things. Key users should be involved early: they're the ones who notice during testing that "that customer never had that discount". Instead of hundred-page manuals you need short guides on everyday tasks, and in the first days after go-live there must be a go-to person for questions.

Workshops show this clearly. Velmotor 2000, a Honda dealership and workshop in Florence, managed bookings through phone calls, emails and paper diaries, with customer data spread across unconnected tools. The new system brought customer records, vehicle history and workshop scheduling together in one place. A change like that only holds if reception, mechanics and team leaders know from day one where to find the information that used to be on paper. The project is described in the Velmotor workshop management system case study.

How long does switching ERP software take

There is no number that fits everyone, and anyone who gives you one without seeing your data deserves some suspicion. The timeline depends on factors you can assess yourself.

First, how many sources need to be merged: replacing a single system is much simpler than merging a system, three Excel files and a CRM. The state of the data matters, because tidy master data shortens the cleaning considerably, and so does how much history you decide to bring over. Then there is the availability of internal staff, who have to make decisions on codes, mappings and checks, and there is the calendar: year-end closing, seasonal peaks and tax deadlines are periods to avoid.

One rule we always apply: preparation and rehearsals take longer than the switchover itself. If the plan allows one day for preparation and a week for go-live, it's written the wrong way round. To think about project costs as well, see the guide on how much custom business software costs and how to calculate ROI.

The most common mistakes when changing systems

The most frequent mistake is postponing data cleaning: "we'll sort it out later" means carrying the same problems into the new system. Close behind comes the migration tested only once, or never. The first rehearsal always finds something, and those who skip it find out in production.

Many check by eye instead of with totals, but a hundred correct records don't prove the other thousand are right. Others leave the project in the hands of the IT person alone, when decisions on codes and history are business decisions that belong to whoever manages customers, purchasing and the warehouse.

Then there are mistakes of timing and caution: going live right before year-end closing, switching off the old system immediately and losing the ability to check and go back, starting without a written rollback plan. The last one is underestimating training and discovering at go-live that half your colleagues are still working in the Excel file.

Data migration FAQs

Can I change systems without losing my history?

Yes. You can migrate all of your history or part of it, leaving the rest in an archive you can still consult. The choice depends on how much you actually use it and how clean it is. It has to be made beforehand, not discovered afterwards.

Do I have to stop the business during data migration?

Normally not. Rehearsals happen on staging while you work as usual. The final switchover is planned for a quiet moment, such as a weekend, with the old system set to read-only.

Who should handle data cleaning?

The technical work (check scripts, merges, conversions) belongs to the partner developing or configuring the new system. The decisions, such as which code to keep or which customers to archive, belong to the people in the company who know the data.

Is standard or custom software the better choice?

It depends on how specific your processes are. A standard product asks you to adapt to its model; custom business software is built around your data and the way you work, which also simplifies mapping during migration. If there are only a few of you and your processes are common ones, a well-configured standard product is usually enough. The full comparison is in the guide on custom versus off-the-shelf software.

Let's talk before you touch the data

If you're thinking about switching ERP software and data migration is what's holding you back, it's worth talking now, before setting dates and choosing suppliers. At Selli we start with an analysis of your data and processes, work in two-week sprints with releases on staging that you can test with your real data, and the source code of the system remains yours. You'll find how we set up projects in our working method.

Book a call with us: we'll look at where your data starts from, what's worth bringing into the new system and how to organise the switchover without stopping the business.

Switching ERP Software Without Losing Data: A Migration Guide