Odoo migration, with the data checked before anything goes live
Four things get called migration: upgrading an Odoo version, moving into Odoo from another system, changing from Community to Enterprise, and changing where Odoo is hosted. We do all four, and we run each one the same way. A copy first, your team testing on it, your figures reconciled, then a planned cutover.
Which Odoo version are you on?
Pick your version
Odoo supports its three latest major versions. Older ones get no fixes or security patches, and can be upgraded directly to the current release without stepping through each one.
On Enterprise, Odoo’s upgrade service carries the standard database to the new version. Your custom modules, third-party modules and integrations are our part, and that is where the work is.
Status as of October 2026, against Odoo’s published support policy. Odoo 20 was released on 24 September 2026.
Four things people mean by migration
- A version upgrade
- From whichever version you run, 10 upwards, to the current release. Standard Odoo moves with Odoo’s upgrade service or OpenUpgrade; your customisations, third-party modules and integrations are carried across by us and tested against your own data.
- Into Odoo from another system
- From QuickBooks, spreadsheets, a legacy ERP or an accounting package. Customers, suppliers, products, open orders, unpaid invoices, stock and opening balances, mapped, cleaned, loaded to a test database and reconciled before go-live.
- Community to Enterprise
- Often done together with a version upgrade. The database is the same software underneath, but the move brings Enterprise-only apps, features and Odoo’s hosting options, and the finance configuration deserves a review while the system is open.
- A change of hosting
- Your own server to Odoo.sh or Odoo Online, or the reverse. The constraint that decides it: Odoo Online does not run custom code, so a database with custom modules goes to Odoo.sh or your own infrastructure.
Where the versions stand
Odoo supports and fixes its three latest major versions. Everything older runs, but without bug fixes or security patches, and Odoo Online databases are moved to a supported version. The table is as of October 2026.
| Version | Released | End of support | Status now |
|---|---|---|---|
| Odoo 20 | September 2026 | Expected October 2029 | Current release |
| Odoo 19 | September 2025 | Expected October 2028 | Supported |
| Odoo 18 | October 2024 | October 2027 (planned) | Supported |
| Odoo 17 | November 2023 | October 2026 (planned) | Support ending |
| Odoo 16 | October 2022 | October 2025 | Out of support |
| Odoo 15 | October 2021 | October 2024 | Out of support |
| Odoo 10 to 14 | Before 2021 | Before 2024 | Out of support |
Dates marked planned are Odoo’s own. Dates marked expected follow from the three-version policy and are ours. Source: Odoo’s supported versions page. We work on every version from Odoo 10 upwards, Community and Enterprise, and on new releases as they arrive.
How a version upgrade runs
The standard part of an upgrade is Odoo’s. The part that decides whether it goes well is everything that is not standard: your custom modules, the third-party modules you depend on, your integrations, and your data. That is the work, and this is how we run it.
Assessment
We inventory the database: every custom and third-party module, every integration, Studio changes, data volume and hosting. You get a written list of what carries over as is, what needs rework for the new version, and what is worth dropping because standard Odoo now does it.
Your team: Give us access to a copy of the database and tell us which customisations you actually still use.
Test upgrade on a copy
On Enterprise we run Odoo’s upgrade service on a copy of your database. On Community we run OpenUpgrade. Then we migrate your custom code to the new version and fix what the upgrade broke, which is normal and expected.
Your team: Nothing yet. Your live system is untouched throughout.
Your team tests
You run your real work on the upgraded copy with test scripts we prepare: quotations, deliveries, invoices, a payroll run, a month end. Finance checks that the trial balance, receivables and payables and stock valuation agree with the live system.
Your team: This is the step that needs your people. Release them for it.
Production upgrade
On an agreed date we freeze the old system, upgrade it, verify the opening position against what your team signed off, and release it. The downtime is planned and told to you in advance.
Your team: Stop entering data at the agreed time, and verify with us before users go back in.
Hypercare
Thirty days of close support after the upgrade, included at no extra cost. Real volume surfaces things a test does not, and we fix them as they appear.
Your team: Tell us quickly when something is not right.
Moving into Odoo from another system
Data migration is accounting work before it is technical work. Our consultants are chartered accountants, and the method below is the one an auditor would expect.
- Scope what moves
- Masters, open items and opening balances move. History usually stays in an archive of the old system, where it is still searchable, rather than being loaded into Odoo as thousands of posted entries nobody will ever reconcile.
- Map every field
- A mapping document from the old system’s fields to Odoo’s, agreed with you before any load. Where the old system had three ways of recording the same thing, this is where it becomes one.
- Clean before loading
- Duplicates merged, dead records retired, codes and tax settings standardised. Dirty data migrated is dirty data with a new interface.
- Load to a test database
- As many trial loads as it takes. Your team works on the test database and finds what the mapping missed.
- Reconcile
- Trial balance to the old system, receivables and payables ageing to the subledgers, stock quantities and valuation to the count. Signed off by your finance team before cutover, not discovered after it.
- Cut over on a date
- A fixed go-live date, a frozen old system, a verified opening position, then Odoo as the single source of truth.
Where migrations go wrong
Three failures account for most of the migration rescues we are asked to do. None of them is the software.
Custom code copied forward instead of migrated
A module written for Odoo 14 does not run on Odoo 20 by being copied into it. APIs change, fields are renamed, whole models move. Each custom module has to be read, adapted and tested on the new version, and some should be retired because standard Odoo caught up.
No test upgrade with real users
A technical upgrade that boots is not a successful upgrade. The problems live in the workflows: a pricing rule that behaves differently, a report with a missing column, an integration posting to a field that moved. Only your people, running real work on a copy, find those before go-live.
Opening balances nobody reconciled
A system that goes live without its trial balance tied to the old one is a system whose first month end nobody can close. Reconciliation is the step companies try to skip, and it is the one that makes everything after it possible.
Migrations for clients
Needs confirmation
No cards until there are real migrations to put in them. The three implementation projects on the other service pages are rollouts, and under this heading they would read as upgrades or system migrations they were not.
Each card needs
- The client, or a descriptor we can use instead if the name is confidential
- What no standard Odoo app covered
- What we migrated
- Which Odoo apps it works alongside
- The outcome, only where it can be verified
Worth asking about first
- Which clients have we upgraded between Odoo versions, from which version to which, and were they Community or Enterprise?
- Which clients came to Odoo from QuickBooks, spreadsheets or another ERP, and what moved?
- Empower’s live environment is on Odoo 17. Was that an upgrade we ran, and is an upgrade to 20 planned?
- Has any client changed edition or hosting with us, Community to Enterprise or on-premise to Odoo.sh?
Common questions
Can we upgrade straight from an old version, or do we have to go one version at a time?
Straight to the current release. Odoo’s upgrade service takes a database from any version directly to the latest one, in Odoo’s own words: you can always upgrade from any version. The work is in your customisations and data, not in stepping through releases.
Is the upgrade free?
The standard part is included for Odoo Enterprise subscribers: Odoo’s upgrade service migrates the standard database at no extra charge. What costs is the work around it, which is ours: adapting custom and third-party modules to the new version, reconnecting integrations, testing with your team and running the cutover. Community has no Odoo upgrade service, so there the whole migration is project work.
How long does an Odoo upgrade take?
It depends almost entirely on how much is not standard: the number and age of your custom modules, the third-party modules you depend on, and your integrations. A lightly customised database is a different project from one with years of custom code. The assessment at the start gives you the answer with dates, rather than a guess before anyone has looked.
Do we have to upgrade at all?
On Odoo Online, yes: databases on versions that have left support are moved to a supported one. On Odoo.sh or your own servers you can stay where you are, but outside the three-version window there are no bug fixes and no security patches, and every year you wait makes the eventual upgrade larger. If you are on Odoo 17 or older, the time to plan is now.
What happens to our custom modules?
Each one is read, adapted to the new version and tested, or retired if standard Odoo now does what it did. Odoo’s upgrade service does not touch custom code; that is the partner’s job, and it is most of the project. The assessment tells you which modules fall into which group before you commit.
Can we move from Community to Enterprise during the upgrade?
Yes, and it is a sensible time to do it, since the database is already being tested on a copy. The Enterprise licence is between you and Odoo; the migration, configuration of the Enterprise apps you want, and the testing are our work.
Will we lose our history?
No, but it may not all move into Odoo. In a system migration we usually move masters, open items and opening balances, and keep the full history in an archive of the old system. In a version upgrade everything moves, because it is the same database. Which records move is agreed in writing before the first load.
How much downtime is there?
A planned window, agreed with you, usually over a weekend or a night. The production upgrade itself is the shortest part: by the time it runs, the same upgrade has already been done on a copy, tested by your team and signed off, so what remains is repeating a known procedure against a frozen system.
Other Odoo services
Build
Get Odoo in place and shaped to your business
Tell us which version you run, and what is custom
Book a consultation with one of our Odoo consultants. We will look at your database, tell you what carries over and what needs rework, and give you a plan with dates instead of a guess.