Changing your ERP: a practical guide to ERP migration

Most businesses do not wake up one morning and decide to change their ERP. They arrive there gradually, after years of workarounds, painful month-end closes and a growing feeling that the system is dictating how the company works rather than supporting it. An ERP migration is the moment that feeling turns into a project.

It is also one of the riskier things a company can do. The ERP holds your orders, stock, invoices, payroll links and the financial records you are legally required to keep. This guide explains how to decide whether to change ERP, how to choose a cutover strategy, how to approach ERP data migration (cleansing, mapping and trial runs), and how to build a rollback plan you hope never to use.

If you are still at the stage of understanding what these systems do, start with what an ERP is. If you are already comparing products, how to choose an ERP covers selection in detail.

When it makes sense to replace your ERP

Replacing an ERP is rarely justified by one irritation. It is justified by a pattern. The signs below tend to appear together.

Signs that the system is holding the business back

• Key processes run in spreadsheets outside the ERP, because the system cannot handle them.
• Finance cannot produce a reliable view of margin, cash or stock without manual reconciliation.
• Every change to a process requires custom development that nobody dares touch.
• The vendor has announced the end of support for your version, or the hosting platform is ageing.
• You are opening new entities, sites or sales channels and the system cannot follow.
• Compliance requirements, such as digital tax reporting or electronic invoicing, are handled by fragile add-ons.

On that last point, see our guide to ERP and e-invoicing: regulatory change is a common trigger for a migration, and it is worth checking what your target system supports natively.

Signs that you should not replace it yet

Not every difficulty calls for a new system. If users are unhappy because they were never properly trained, a new ERP will reproduce the same frustration with a new logo. If processes are poorly defined, a migration will move the mess to a different database. And if the real issue is a single module, an upgrade or a re-implementation of that module may be more proportionate.

Before committing, be honest about whether the problem is the software, the configuration, the data or the organisation. Only the first justifies a new product.

Replacing your ERP or upgrading it: two different projects

The phrase "ERP migration" covers two quite different situations, and mixing them up leads to wrong budgets and wrong expectations.

A version upgrade can still be demanding when the system carries years of custom code. Customisations written for an old release often need to be rewritten, not just retested. Treat a major upgrade as a project in its own right, with a plan, a test environment and a decision about which customisations are worth keeping.

A full replacement is closer to a fresh implementation with one extra difficulty: you must bring the past with you. For the wider picture of how such a project is run, read our guide to ERP implementation.

Start with the business case, not the software

Before any vendor demonstration, write down what the migration must achieve in operational terms: faster closing, accurate stock, fewer manual entries, support for a new business model. These goals become the acceptance criteria later. Without them, a migration drifts into a technical exercise that is declared a success because the new system turned on.

Then document what you actually need. Do not copy the old system's screens into a specification. Describe the processes as they should work. Our ERP requirements template gives a structure for this. It is tempting to skip this stage when you already have a running system, but the old configuration reflects decisions made years ago, many of them for reasons that no longer apply.

Finally, be realistic about cost. A replacement involves licences or subscriptions, implementation services, data work, training, and internal time, which is the item most often forgotten. See ERP cost for how to build a full budget.

Choosing a cutover strategy

The cutover is the moment users stop working in the old system and start working in the new one. There are three broad approaches.

Big bang

All modules and all entities switch over at once, usually across a weekend or a quiet period.

Advantages: one transition, no temporary interfaces between old and new, a single training wave, and a clear date that everyone can plan around.

Drawbacks: every risk lands on the same day. If stock, invoicing or payments fail, the whole business feels it. It demands rigorous rehearsal and a team able to work flat out during the switch.

A big bang suits businesses with tightly integrated processes, where running two systems in parallel would create more confusion than it removes.

Phased go-live

The new system is introduced by module, by site or by legal entity. A common sequence is finance first, then purchasing and stock, then sales and production. Another is to start with a smaller subsidiary and learn from it before moving the main company.

Advantages: problems are contained and lessons are applied to the next phase. Teams are trained in smaller groups.

Drawbacks: temporary interfaces between old and new systems must be built and then thrown away. Reporting during the transition is harder, because data sits in two places. The project lasts longer, and the organisation lives with change for longer.

Parallel running

Both systems operate on the same transactions for a period, and results are compared. In theory this is the safest route. In practice it doubles the workload for the people involved and tends to exhaust them. It is best reserved for a narrow, critical area, such as a payroll or period-end process, rather than the whole business.

How to decide

Seasonality matters as much as architecture. Avoid peak trading, the end of the financial year and the periods around VAT returns where possible. Your finance team will have a view on the least damaging window, and it should carry weight.

Data migration: where projects are won or lost

The software is only as good as the data in it. Most migration delays trace back to underestimating data work, not to the new product. It helps to think of the process in four stages.

Decide what to migrate

Not everything deserves to move. A sensible split is:

• Master data: customers, suppliers, items, bills of materials, price lists, chart of accounts.
• Open transactions: unpaid invoices, open purchase and sales orders, work in progress, current stock.
• Opening balances: the financial position at the cutover date, reconciled to the old ledger.
• History: past transactions, kept only where there is an operational reason.

For history, consider an archive: a read-only copy of the legacy system or an extract in a reporting tool. It keeps the new system lighter and faster, while still allowing audit queries and responses to HMRC. Confirm retention requirements with your accountant before deciding what can be left behind.

Cleanse the data

Migration is the best opportunity you will have to clean data, and the worst moment to discover it needs cleaning. Typical problems include:

• duplicate customers and suppliers under slightly different names;
• inactive items and accounts that still clutter lists;
• inconsistent units of measure and product codes;
• incomplete addresses, missing VAT numbers or outdated bank details;
• negative stock and unreconciled balances.

Cleansing should start early, be owned by the business and not by the integrator alone, and have named people accountable. The integrator can supply tools and rules, but only your staff know which supplier is dormant or which product was discontinued.

Map the data

Mapping defines how each field in the old system corresponds to a field in the new one. It is rarely one to one. Account structures differ, address formats differ, and some concepts exist in one product and not the other. A good mapping document records the source, the target, any transformation rule and the person who approved it.

Mapping is also where you reveal decisions that were never taken. For example, how should you represent the many ways a customer can be set up in the old system? Settling this early saves painful discussions during testing.

Run trial migrations

Do not migrate once. Migrate several times, each time against a test environment, and compare the results with the source.

1. An early trial reveals structural problems: missing fields, rejected records, format errors.
2. Later trials are reconciled in detail: customer balances, supplier balances, stock value, trial balance.
3. A final rehearsal replicates the real cutover in sequence and under timing, with the people who will do it.

Finance should sign off the reconciliation, not just IT. A migration where the trial balance matches at the first attempt is usually one where nobody checked properly.

Testing and training

Data is only one side of readiness. The system must also behave correctly under real conditions.

Process testing. Walk complete business scenarios from end to end: quote to cash, procure to pay, production order to finished goods, month-end close. Use real examples, not clean demo data.

Integration testing. Check every connection to other tools such as payroll, banking, e-commerce platforms, carriers, customer portals and reporting. Interfaces are a leading cause of failed go-lives because they are tested late.

User acceptance. Staff from the business, not the project team, run the tests and confirm that the system supports their daily work.

Training. People learn when they use the system on their own tasks, not in generic demonstrations. Plan training close enough to go-live that it is fresh, with support available afterwards. Adoption is a leading indicator of whether the benefits arrive, which is why so many failed projects have working software and unhappy users. Our overview of ERP project mistakes lists the traps worth avoiding.

Risks to manage and how

Building a rollback plan

A rollback plan is not pessimism. It is what allows the team to make a calm decision when something unexpected happens at an inconvenient hour.

A usable plan includes:

• Go/no-go criteria defined in advance: which checks must pass before the new system opens for business, and who has the authority to call it off.
• A frozen legacy system. Do not decommission the old ERP at go-live. Keep it available, read-only at minimum, for an agreed period, so that questions can be answered and a return remains possible.
• A verified backup of the legacy data taken at the cutover point, with a restore procedure that has actually been tested.
• A defined point of no return. Once real transactions have been posted in the new system, going back means re-entering them. Know when that moment arrives and what it would cost.
• A communication plan for staff, customers and suppliers, so that a delay or reversal is handled in an orderly way.
• A hypercare period after go-live, with the project team and the integrator available to resolve issues quickly.

Rehearse the rollback as seriously as the go-live. A plan that has never been tried is only a document.

What changes depending on the target ERP

The migration approach is broadly the same whatever the product, but the starting point and tooling differ. Each of these platforms is covered on this site, and none is better in every case.

• Odoo is modular, which makes a phased introduction natural: you can begin with finance or sales and add applications later. Open-source flexibility also means more scope for customisation, which needs discipline. See open-source ERP for the trade-offs.
• Microsoft Dynamics 365 Business Central suits businesses that already live in the Microsoft ecosystem, and its cloud model changes the upgrade rhythm compared with older on-premise systems.
• Sage is a familiar name for many UK finance teams, so migrations from or between Sage products often involve users who know the vendor well but are moving to a different architecture.
• Oracle NetSuite is a cloud-native platform aimed at growing and multi-entity businesses, which usually makes consolidation and group reporting part of the migration brief.
• SAP Business One targets smaller companies within a larger vendor's range, and is often considered by businesses with strong stock and production needs.

If you are weighing two candidates directly, the comparisons of Odoo and Business Central and Odoo and Sage show how the products differ in practice. Where you run the system also matters: cloud versus on-premise ERP explains the consequences for upgrades and hosting.

Choosing who will carry out the migration

Whoever leads the migration should be able to explain, in plain terms, how they approach data cleansing, mapping, trial runs, cutover and rollback for a business like yours. Be wary of anyone who treats data migration as a minor technical task, or who promises a seamless transition without describing the rehearsals.

Ask to see how they have handled comparable situations, who will actually do the work, how they will involve your staff, and what happens if the go-live is postponed. Our guide to choosing an ERP integrator lists the questions worth asking.

ERP Integrator is a free service that puts you in touch with an integrator suited to your project; we are not affiliated with any software vendor, and the integrator, not us, delivers the work. You can read how the introduction works before you submit a request.

A practical migration checklist

1. Define the business goals and acceptance criteria.
2. Decide between upgrading and replacing, and document why.
3. Describe the target processes and requirements.
4. Shortlist products and integrators, then confirm the budget including internal time.
5. Choose a cutover strategy and a date that avoids critical business periods.
6. Start data cleansing immediately, with named owners.
7. Write and approve the mapping documentation.
8. Run trial migrations and reconcile each one with finance.
9. Test processes, integrations and user acceptance.
10. Train users on their own tasks, close to go-live.
11. Agree go/no-go criteria and rehearse the rollback.
12. Go live, keep the legacy system frozen and provide hypercare.
13. Review the results against the original goals.

A migration is judged less by the weekend of go-live than by the months that follow: whether the books close faster, stock is trusted, and staff stop reaching for spreadsheets. Plan for those outcomes from the start, and the cutover becomes an event you control rather than one you endure.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.