Odoo Migration Statistics: What the Data Actually Says in 2026

Doodex original measurement

The Doodex Odoo Module Readiness Index

Nobody publishes how ready the Odoo ecosystem is for a new version, so we measure it. The index is the number of modules listed on the Odoo Apps Store for a given version, as a share of the largest catalogue among currently supported versions.

Module readiness by version

Apps Store listings per version, as a share of the largest supported catalogue (Odoo 18.0 = 100%).

Odoo 19.0 — the target most 2026 migrations aim at Other supported and retired versions

Scroll sideways to see the whole chart.

Download PNGDownload SVG

Method

For each version we read the result count returned by the Odoo Apps Store module browser with the version filter applied — apps.odoo.com/apps/modules/browse?series=19.0, changing the series parameter. The index is that count divided by the highest count across supported versions. Measured 6 August 2026 and re-measured monthly; the figures above are the latest reading.

What the Index Does and Does Not Tell You

• It does show how far the third-party and community ecosystem has moved to a new version — a leading indicator of whether a migration to that version will hit missing dependencies.
• It does not tell you whether your specific modules are ready. A catalogue listing is not a compatibility guarantee, and a module absent from the store may still have a maintained fork.
• It is not a rewrite rate. It says nothing about how much of your custom code needs changing — no credible source publishes that figure, as we set out further down this page.
• Above 100% is possible. As a version matures its catalogue can overtake the previous one, since new modules are published that never existed for older releases.

Odoo Migration Budget Benchmarks

Odoo's technical upgrade service is free with an Enterprise subscription. Everything that makes a migration actually land — custom module adaptation, data cleaning, data mapping, validation, retraining — is not. That gap is the migration budget.

What ERP Projects Cost, and How Often the Number Moves

Budget by Scope: What Actually Scales the Number

No credible study publishes a cost-per-module elasticity. Panorama names module count and customisation depth as drivers but never quantifies them. The most defensible public banding is by user count, and it is indicative only. A note on currency: the survey figures above are published in US dollars and the bands below in pounds sterling. We quote each source in its own currency rather than converting at a rate that would date this page.

Indicative budget by deployment size

Plotted on a logarithmic scale, because the top band is two hundred times the bottom one.

Scroll sideways to see the whole chart.

Download PNGDownload SVG

Source is an ERP consultancy's published cost model, not a survey — treat as an order of magnitude. The same model puts implementation at 1–3× the first-year licence fee, five-year total cost of ownership at 3–5× licence, and hidden costs at 15–30% on top. A separate benchmark of 1,384 ERP projects gives roughly $9,000 of budget per user. That model also prices data migration itself at £8k–£20k for a simple move, £20k–£80k mid-market and £120k–£400k at enterprise scale — and notes the cost can double if source data quality is poor.

If you want these bands turned into a figure for your own database rather than a range, that is what a scoping exercise produces — we outline how we price and phase the work under Odoo migration services.

The Migration Risk Register: Failure Modes and Countermeasures

Most failed migrations fail for the same predictable reasons. This is the register we work through on every project — each risk paired with the control that removes it.

The full register is twelve rows — it is a working checklist rather than a read-through.

Data Mapping: The Discipline That Decides Data Integrity

Proper data mapping is the difference between a successful Odoo data migration and eighteen months of reconciling. It is unglamorous, it produces nothing you can demo, and it is the single highest-leverage activity in the entire process.

Data mapping means deciding, field by field, where each piece of data in the existing system lands in Odoo — which model, which field, which format, and what happens when the source is empty or invalid. Incorrect mappings are the most expensive kind of error precisely because they do not throw errors. The import succeeds, the records exist, and the data is quietly wrong. For a smaller worked example of the same exercise on one object, see how field-to-model mapping plays out when moving a CRM database from HubSpot to Odoo.

The mapping document itself, field by field — open it when you are ready to build yours.

Map the Chart of Accounts before Any Accounting Data Moves

Of everything in the mapping document, the chart of accounts has the longest shadow. Accounts mapped to the wrong Odoo account type do not produce an error — they produce a balance sheet that puts figures in the wrong section, and every report built on top inherits the mistake. Map the accounts, print the balance sheet, and get finance to sign it off before a single journal entry follows.

Map onto Odoo's Structure, Not Your Existing System's

This is the rule that separates a database you can maintain from one you cannot. Every field added because "that is how the existing system did it" becomes custom code, and custom code is what blocks the next version jump — as the statistics further down this page make uncomfortably clear. Challenge each deviation once, at mapping time, while changing it is still free.

Five Rules for Proper Data Mapping

Get these right once, at mapping time, while changing them is still free. Hover a segment for the full rule.

Scroll sideways to see the whole diagram.

Download PNGDownload SVG

And the six mistakes that produce a database which looks right and reports wrong:

Three Migration Strategies: Choosing the Right Approach to Your History

Every Odoo data migration resolves to one of three strategies. The industry borrowed the names Greenfield, Greenfield + Cutover and Brownfield from the SAP world — they are not options Odoo sells you, they are choices you make about how much of the old system comes with you. Here is what each one means in practice, and what we call it.

A Phased Rollout Beats a Single Switch

Whichever strategy you pick, sequence the go-live. A phased rollout — module by module, entity by entity, or site by site — reduces operational disruption because a problem in one phase affects one area rather than the whole business. It is the same logic behind our 3-month parallel-run methodology on migrations off SAP Business One and Sage X3: the old system keeps running while Odoo takes over in stages, and the final cut-over happens only after several stable months. No Big Bang. We set out the phased, module-by-module method in full, including how the safety net is kept live.

This matters more than any statistic on this page. Roughly half of organisations report material operational disruption at go-live, and the variables that measurably reduce it are all sequencing and preparation decisions — defined processes, user acceptance testing, training, executive alignment — not the size of the maintenance window.

Part 6 · Validation, security and downtime

Validating Your Data — and Protecting It While You Move It

Validation is not a phase at the end. It runs alongside every import, and it has layers — because matching record counts proves almost nothing about whether the system works.

Testing in Layers: How to Validate Data in the New Database

The validation sieve: four layers, four classes of error

Every record passes all four gates. Each gate catches a class of error the previous one cannot see.

Download PNGDownload SVG

The Tool Matters: Odoo Import, the Odoo API and Integrations

Odoo gives you two ways to move data in, and the choice shapes how repeatable your migration is:

Ensuring Accuracy without Endless Manual Work

The practical rule: if a load has to happen twice, script it. Manual work during a migration is not just slow, it is unrepeatable — and an import you cannot repeat identically is an import you cannot rehearse. Ensuring accuracy at scale is a tooling problem, not a diligence problem: a scripted job that can migrate data into a clean database in twenty minutes lets you validate, fix the mapping, and re-migrate data the same afternoon. The same work done by hand gets one attempt, late, under pressure — which is precisely how projects that had sufficient time on paper end up with none.

And the part that only matters while the migration is running:

Downtime and Go-Live Disruption Statistics

Nobody publishes a cut-over downtime benchmark in hours — not for Odoo, not for any ERP. Any hour figure you see is an estimate. What is measured matters more: how often go-live disrupts the business, and for how long.

How often go-live actually disrupts the business

The dot grid is a share of all organisations. The two bars below are a share of the disrupted ones only — a different base.

Scroll sideways to see the whole chart.

Download PNGDownload SVG

"Material disruption" is defined narrowly in this research: being unable to ship product or unable to close the books. Employee frustration and short-term inefficiency are excluded. Across roughly 1,000 transformations studied, the 51–54% disruption rate was described as the most consistent metric of all.

What Disruption to Operations Actually Means

The research defines it narrowly and usefully: being unable to ship product, or unable to close the books. Not inconvenience — a halt in operations that the business feels commercially. That is the risk a rehearsed cut-over and a real test phase are buying down, and it is why the mitigations that work are all scheduled weeks before go-live rather than on the night.

What Odoo Documents about the Cut-Over Itself

• Your production database is unavailable for the duration of the upgrade. Odoo publishes no estimate of how long that is, and recommends scheduling it when database use is minimal.
• On Odoo.sh, a failed upgrade auto-reverts and a pre-upgrade backup is created on success. On Odoo Online, once the upgrade completes it is impossible to revert to the previous version.
• Databases are submitted without the filestore, which has to be merged back into production manually.
• The risks Odoo itself names for skipping the test phase: users failing to adjust to changes, business interruptions such as no longer being able to validate an action, and poor customer experience such as an eCommerce site that stops working correctly.

Part 7 · How we run it

Professional Odoo Migration Services: The Doodex Process, in Five Phases

The statistics above describe what goes wrong across the industry. This is the process we run to keep those outcomes off your project — a 30-person in-house team, nothing outsourced, and the same people from the audit through to Odoo support services two years later.

1. Assessment and planning. We audit your existing system, data volume, modules and integrations. A thorough data audit before migration is the cheapest hour of the entire process: it is where we find the duplicate records, the dead accounts and the data nobody can explain a use for. Scope and pricing are fixed after this audit, so the budget does not drift mid-project.
2. Data backup and extraction. Backups in two separate locations before, during and after the move. We standardise data formats at extraction — consistent dates, decimals, encodings, identifiers — because standardising formats is what actually eliminates duplicate and outdated records before they reach Odoo, rather than after.
3. Data mapping and module migration. Field by field, written down and signed off by the people who own the data. Careful mapping is what protects data integrity in Odoo; incorrect mappings do not throw errors, they produce a database that looks right and reports wrong. Custom modules are rebuilt as custom code, never Studio patches, so they survive the next version.
4. Testing and deployment. Incremental testing throughout the project, not one test phase at the end — testing early and often is the single practice most associated with implementation success. Every migration test runs in a staging environment before anything touches production. Then performance testing, user acceptance testing, and a staged cut-over.
5. Support and handover. Go-live, monitor, optimise, ongoing support. Role-based user training and clear documentation, plus skills transfer to your own IT team so you are not dependent on us. We document the migration process itself — mappings, decisions, exceptions — so the next upgrade starts from a record rather than from memory.

Automation: Use the Odoo API for Secure, Repeatable Imports

Anything that has to run more than once gets scripted against the Odoo API (XML-RPC or JSON-RPC) rather than clicked through by hand. Three reasons, all practical: a scripted import is testable, it is repeatable so the cut-over can be rehearsed and timed, and it uses external IDs so a correction updates a record instead of creating a duplicate; that kind of automation in testing, imports, and follow-up checks reduces manual effort and makes the migration process more repeatable. Manual work during a migration is not just slow — it is unrepeatable, and an import you cannot repeat identically is an import you cannot rehearse.

Monitor Continuously after Go-Live

Migration does not end at cut-over. We monitor system performance continuously afterwards, because the failures that surface in week three are different from the ones testing catches. Unoptimised databases cause severe lag during report generation under real data volumes. External connectors that passed a functional test fail under production load. Both are cheap to fix when someone is watching and expensive when nobody is. Monthly health checks for the first 90 days, then ongoing support.

More on how we phase and price this work in our Odoo migration services, the full methodology in the Doodex method, and the parallel run in practice on our SAP Business One to Odoo and Sage X3 to Odoo pages. For one project start to finish — extraction, de-duplication, mapping files, staging tests and a phased go-live — read our DBS to Odoo migration case study.

Sources

Every figure on this page is traceable to a source below. Where a statistic comes from a self-selected survey or a consultancy's own cost model rather than primary research, we say so at the point of use. Process guidance is our own practice, marked as such.