Odoo Migration Checklist: What 213 Modules and Zero Errors Actually Takes

Most ERP migration write-ups are written by people selling the migration. This one is written from the other side: I led a full Odoo v14 → v18 migration covering 213 modules, finishing with zero errors and a 100% data match.

This is what that actually required — useful whether you are scoping a migration yourself or evaluating someone who says they can do it for you.

The number that matters is not “modules migrated”

213 modules sounds impressive. It is also the least interesting number in the project.

The number that decides whether a migration succeeds is how many records you verify individually after the move. In this case:

Record type	Verified
Partners	3,766
Invoices	4,230
Sales orders	812
Purchase orders	479
Helpdesk tickets	82
User credentials	39

Moving data is straightforward. Proving every invoice carries the same value before and after — that is the work. A migration without a verification plan is not a migration; it is a hopeful copy.

What breaks, in order of likelihood

1. Custom modules written against old APIs

Anything custom is where migrations stall. Core Odoo modules have upgrade paths; your bespoke approval workflow does not. In this project three custom modules had to be ported by hand.

Scope it separately. Custom code is a rewrite estimate, not a migration estimate.

2. Data that was already wrong

Migration exposes every inconsistency the old system tolerated: duplicate partners, invoices without a valid journal, products referencing deleted categories.

You have two options, and only two: clean it before the move, or carry it forward. There is no third option where it fixes itself.

3. Attachments and the filestore

Database rows migrate cleanly. Files sitting in the filestore do not always follow. On one project I had to recover message attachments from an older filestore after the fact — recoverable, but only because the old volume still existed.

Verify file counts, not just row counts.

4. Authentication

Users cannot log in on day one and everyone assumes the migration failed. Plan credential syncing explicitly and test with real accounts before cutover.

A migration checklist that reflects reality

Before you touch anything

Take a full backup and restore it somewhere else to prove it works
Inventory every custom module and mark which are still in use
Run a data-quality audit: duplicates, orphans, broken references
Record baseline counts and totals for every business-critical table
Agree what “done” means with the client, in numbers

During

Migrate to a staging environment first, never straight to production
Port custom modules one at a time, testing each in isolation
Re-run the baseline counts and compare against the originals
Have a named person test each business process end to end

Cutover

Freeze writes on the old system
Run a final delta migration for records created during the work
Sync credentials and verify logins with real accounts
Switch DNS/domain last, once the system is confirmed working
Keep the old system readable — not writable — for at least a month

Database cleanup is part of the job

On a separate engagement I migrated two production Odoo instances from DigitalOcean to AWS. One database went from 21GB to 1.45GB — a 93% reduction.

That reduction was not compression. It was removing accumulated debris: orphaned attachments, log tables that had never been pruned, and snapshot data from an audit that had run in a loop.

The system was materially faster afterwards. In the same project, standardising bot protection cut response time from 58 seconds to 0.8 seconds — a 98% improvement that had nothing to do with hardware.

The lesson generalises: most “we need a bigger server” problems are actually “nobody has looked at this data in three years” problems.

Estimating honestly

Rough scoping ranges, based on work delivered rather than a price list:

Scope	Timeline	Main risk
Version upgrade, no customisation	2–4 weeks	Third-party module compatibility
Upgrade with 3–5 custom modules	6–10 weeks	Custom code rewrites
Cross-platform migration + upgrade	10–16 weeks	Data quality, infrastructure changes
Multi-instance consolidation	3–6 months	Reconciling conflicting master data

If a proposal promises a full migration with custom modules in two weeks, ask specifically which verification steps are being skipped. There is always an answer.

What to ask a migration partner

How will you verify data integrity? Look for record-level counts and totals, not “we will check it works”.
What happens to our custom modules? Vague answers here mean the estimate is wrong.
What is the rollback plan? If there isn’t one, the cutover is a gamble.
Who tests the business processes? Someone who knows your operations must sign off, not just the developer.
How long do we keep the old system? “We deleted it” is the wrong answer.

FAQ

How long does an Odoo migration take? A straightforward version upgrade takes 2–4 weeks. Add custom modules and it becomes 6–10 weeks. Cross-platform moves with infrastructure changes run 10–16 weeks. The variable is almost always custom code and data quality, not module count.

Can we migrate without downtime? Near-zero downtime is achievable with a staged approach: migrate to staging, verify, then run a final delta sync during a short freeze window. True zero downtime needs dual-write architecture, which is rarely worth the cost at SME scale.

Should we upgrade to the newest version? Not always the very newest. Running one version behind the latest release often means better third-party module support. What matters more is staying within the window that still receives security patches.

What does a failed migration look like? Rarely a dramatic crash. Usually it is discovering three months later that historical invoices have the wrong tax treatment, or that a report silently excludes a subset of records. This is exactly why verification counts matter more than a successful import.

If you are scoping a migration and want a second opinion on the estimate or the verification plan, I am happy to look it over.