Moving to Odoo, or between Odoo versions: how to plan the migration

An Odoo migration is rarely a single operation. For a UK business it usually means one of two things: moving to Odoo from spreadsheets, an accounts package or an older ERP, or migrating between Odoo versions once you are already live. The tools, the risks and the people involved are different, so this page treats them separately and then covers what they share: data quality, cutover, testing and a way back.

If you are still at the stage of deciding whether to switch, our general guide to ERP migration sets out the wider picture. Here we stay with Odoo.

Moving to Odoo: where are you coming from?

The starting point shapes the whole project.

Passing from Excel to Odoo is often the easiest in technical terms and the hardest in organisational terms: nobody has ever had to define what a "customer" or a "product variant" is. Leaving an older ERP is the opposite, with a structured source but a lot of legacy behaviour to untangle.

What data should you migrate?

Not everything deserves a place in the new system. A useful way to decide is to sort data into three groups.

Master data

These are the records that everything else refers to:

• customers and suppliers, with their contacts and delivery addresses;
• products, categories, units of measure and price lists;
• the chart of accounts, taxes and fiscal positions;
• employees, if you will use the HR applications;
• bills of materials and routings, if you manufacture.

Master data must be migrated, and it must be clean first. A duplicated supplier in the old system becomes a duplicated supplier in Odoo, and then two sets of payments.

Open items and balances

This is what lets the business carry on the day after go-live:

• open sales orders and purchase orders;
• unpaid customer invoices and supplier bills;
• opening stock quantities, by location;
• opening balances in the general ledger, agreed with your accountant.

For the finance side, the way you carry over ledgers and the cut-off date should be settled with your accountant, not by the project team alone. See accounting and finance in Odoo for how the application is structured.

History

Historical transactions are the most tempting to migrate and the least valuable per record. Ask a plain question for each data set: will anyone search, report on or be audited from it inside Odoo? If the answer is "only occasionally", keep it in an archive of the old system or in an export, and bring across summaries or the last period only. You still need to hold the records you are legally required to keep, so check this with your accountant; our guide to ERP legal requirements covers the obligations to keep in mind.

How Odoo imports data

Odoo’s own import tool is the workhorse for most projects. According to Odoo’s documentation, it accepts CSV and Excel (.xlsx) files, and there are preconfigured templates for contacts, products, bank statements, journal entries and sales orders.

Three points from the documentation shape how a project is run:

1. External identifiers prevent duplicates. They let you re-run an import to update records rather than create them again, and they allow you to carry relationships over from the former system, such as which contact belongs to which company.
2. Imports are final. They cannot be undone once they are done, so nothing should be loaded into the production database until the same file has been loaded successfully into a test copy.
3. Order matters. Companies before contacts, products before price lists, accounts before opening entries.

For large volumes, complex mappings or live links to other systems, your integrator may use scripts or connectors rather than manual files. The principle is the same: repeatable, rehearsed, reconciled. See Odoo integrations if the project involves connections to a website, a payment provider or a warehouse system.

Cleaning data before you load it

Most migration delays come from data, not software. Before any load, plan a cleaning pass:

• merge duplicate customers, suppliers and products;
• retire items nobody has sold or bought for a long time;
• standardise addresses, postcodes and country fields;
• check VAT numbers and payment terms on every active account;
• agree product codes and units of measure in one reference file.

Give each data set an owner on your side. Someone in sales owns the customer file; someone in purchasing owns suppliers. An integrator can build the import, but only your team knows which supplier closed three years ago.

UK points to settle before the load

Some topics are specific to running a business in the United Kingdom and should be agreed early:

• VAT and Making Tax Digital. Your VAT return must keep going without a gap through the switch. Confirm with your accountant which period you start in Odoo, and how the first return will be prepared. Our guide to Making Tax Digital and your ERP explains what the system has to support.
• Payroll and RTI. If payroll is not moving at the same time, decide what stays in your payroll software and how journals reach the ledger. If it is moving, plan a parallel run. See payroll and RTI and Odoo payroll and HR.
• Tax year and financial year ends. Starting mid-period is possible but makes reconciliation harder. Many firms choose a month-end, or the start of a financial period, for the cutover.
• Multi-site and multi-nation operations. Customers and suppliers in England, Scotland, Wales and Northern Ireland, or in several currencies, mean tax, currency and address rules to configure before data arrives.

Cutover strategy: big bang or phased?

Once the data is understood, you must decide how to switch.

Big bang

Everything moves on one date. The old system is frozen, final balances are loaded, and the business works in Odoo from the next working day. This is simpler to manage and avoids double entry, but concentrates the risk on a single weekend.

Phased

Modules or entities move in turn: for example finance and sales first, then stock, then manufacturing; or one company or site before the others. The risk is spread out, but you will need temporary interfaces between old and new, and staff will work in two systems for a time.

Parallel run

For high-risk processes such as payroll or month-end close, you run both systems side by side for a defined period and compare the results. It is costly in staff time, so reserve it for what really needs it.

There is no universally right answer. A small trading company with one site is usually fine with a big bang. A group with several entities and a warehouse often does better phased. The implementation page describes how these choices fit into the broader project.

Testing before go-live

Testing is where an Odoo migration is won or lost. A reasonable sequence is:

1. Trial migration. Run the complete load into a test database, measure how long it takes and list every error.
2. Reconciliation. Compare totals: ledger balances, receivables, payables, stock valuation, number of open orders. Differences must be explained, not rounded away.
3. Process testing. Key users run real scenarios from quotation to payment, from purchase to receipt, from production order to delivery.
4. Rehearsal of the cutover. Repeat the whole sequence on the timetable you will actually use, including the freeze, the final export and the load.
5. User acceptance. Someone from the business, not the project team, signs off.

Train people on the test database with their own data. They learn faster, and they will spot data problems you would not. See Odoo training for how to organise this.

Rollback: plan the way back before you need it

Few firms ever roll back, but every cutover should be designed as if it might. A workable plan contains:

• a full backup of the old system and of the Odoo database taken just before go-live;
• a defined decision point, with a named person who can call it off and the conditions that would trigger it;
• a record of what was entered in Odoo after go-live, so it can be re-keyed if the business reverts;
• the old system kept available, ideally read-only, until the first period close in Odoo is done and reconciled.

Rollback gets harder with every hour of live trading. That is why the decision point should be early and the criteria agreed in advance, not improvised under pressure.

Migrating between Odoo versions

If you already run Odoo, a migration means an upgrade. Several points in Odoo’s documentation are worth knowing.

• Every major version receives three years of standard support after release, then paid extended support that is available only on Odoo.sh (for limited versions) and on-premise. Security fixes are provided only during standard support.
• Intermediate "SaaS" versions come out every two to three months, exist only on Odoo Online and do not qualify for extended support.
• On Odoo Online and Odoo.sh, a major upgrade is mandatory every two years, and intermediate versions must be upgraded within weeks of the next release. Odoo sends notice beforehand.
• Before moving production, the procedure provides for an upgraded test database so that you can validate the new version. Some services fall outside the scope of the upgrade service level, so check what is covered.

The supported-versions page shows the calendar. Odoo 17.0 reached the end of standard support in September 2026, Odoo 18.0 is supported until September 2027 and Odoo 19.0 until September 2028; Odoo 20.0 was announced for September 2026. If you are on an older release, plan the upgrade now rather than when support lapses. Our page on Odoo versions and editions gives more context on how to choose.

What makes an upgrade hard

The standard applications usually upgrade smoothly. The trouble comes from what you added:

• custom modules written for an earlier version, which need to be reviewed and often rewritten (see Odoo customisation);
• third-party apps that are not yet available on the target version;
• integrations that depend on specific fields or interfaces;
• reports, automated actions and views that changed.

A good integrator starts by inventorying all of these, deciding which to keep, replace with standard features or drop. If a previous project has left you with a fragile system, an Odoo audit or project rescue can be the first step before upgrading.

Hosting also changes the work: Odoo Online, Odoo.sh and on-premise differ in who runs the upgrade, and in what support applies afterwards. See Odoo hosting and cloud.

Mistakes to avoid

• Loading dirty data "to clean it later". Later never comes, and reports are wrong from day one.
• Migrating everything. More history means more load time, more errors and more reconciliation, for little daily value.
• Skipping the rehearsal. A first-time load on go-live weekend is a gamble.
• Leaving the accountant out. Opening balances, VAT and year-end are not a technical detail.
• Underestimating the people side. Staff who were not trained on their own data will revert to spreadsheets.
• Having no rollback. A plan that cannot be reversed puts all the risk on one night.
• Customising to copy the old system. Replicating every old quirk makes future upgrades costlier. Question each one.

Choosing who runs your migration

Migration is as much about method as about tools, and it depends on an experienced team. When you compare integrators, ask how they handle trial loads, reconciliation and rollback, and how they approach upgrades for the version you are on. Our page on choosing an Odoo partner lists useful questions, and how the matching works explains how we introduce you to an integrator suited to your project. The service is free for you, and the project itself is carried out and priced by the integrator.

Costs vary with the scope of data, the number of users and the amount of customisation. Odoo pricing covers the licensing side, and the wider ERP cost guide puts it in context.

Next steps

Start by writing down where your data lives today, who owns it and what you would like to see in the new system on the first morning. With that, an integrator can scope the migration properly. Describe your situation through the request form and we will connect you with an Odoo integrator who has handled a similar move.

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.