15 Things to Check Before Migrating to a New Odoo Version

Most Odoo upgrades don't fail during the migration. They fail two weeks before it, in a step nobody bothered to check.

That's what this Odoo migration checklist fixes. 15 concrete things to check before you touch your production database, plus a quick way to score how ready you actually are.

Quick answer: Before migrating to a new Odoo version, confirm your current and target version, audit every custom and third-party module, back up your full database and filestore, test everything in a sandbox, and lock down a rollback plan with clear trigger conditions.

The 15 checks below walk through each of these in detail, so you know exactly what to verify before you set a go-live date.

Why This Checklist Matters

Here's something most teams don't know. Odoo now covers every version indefinitely, but only the three most recent releases are covered for free. Anything older gets a 25% surcharge on the annual license.

Right now that cutoff sits at Odoo 16. Once Odoo 20 launches at Odoo Experience this September, that line moves. Odoo 17 slides out of free coverage too.

That's not a scare tactic. It's just math that makes putting off your Odoo version upgrade more expensive every year you wait.

But rushing in is worse. Most migration failures don't come from Odoo's upgrade tool itself. They come from something nobody bothered to check beforehand, like a custom module nobody remembered existed.

This pre migration checklist for Odoo exists to close that gap, one item at a time.

The 15 Things to Check Before You Migrate

These are the checks that decide whether your Odoo upgrade goes smoothly or turns into a mess. Work through them in order, since some build on the ones before.

1. Your Current Odoo Version and Edition

Get specific here. Not "Odoo 15 or 16," but the exact version and whether you're on Community or Enterprise.

This gets skipped constantly, and it affects everything else on this list.

Community and Enterprise don't upgrade the same way. Some modules only exist on one side, and licensing terms differ too.

Check these before moving forward:

• Exact version number, down to the point release
• Community or Enterprise edition
• Self-hosted, Odoo.sh, or Odoo Online
• Current contract renewal date, since that affects surcharge timing

Get this wrong early, and everything else in your Odoo migration checklist gets built on shaky ground.

2. Your Target Version and How Far You're Jumping

Once you know your starting point, figure out how big the jump to your target version really is.

One version up is usually simple. Three or four versions up is a different project entirely.

Odoo doesn't just add features between releases. It also removes old code and deprecated APIs. Skip several versions, and those changes stack fast.

If you're on Odoo Online with few customizations, the in-app upgrade prompt can handle a lot of this automatically.

• One or two versions up: standard upgrade, manageable timeline
• Three or more versions up: treat it like a re-implementation
• Odoo Online, light customization: check if the in-app upgrade path fits

Let Softhealer Handle the Checklist for You

Get Migration Assessment

3. Every Installed Module, Standard, Custom, and Third Party

Most teams remember their big custom modules. It's the small ones that cause problems, the ones nobody's touched in two years.

Pull a full list of every installed module first, not just the ones you remember building.

Then sort each one into a bucket based on what happens to it during the upgrade:

• Retain: still needed, still compatible, no changes required
• Replace: a newer standard Odoo feature now covers the same need
• Reconfigure: needed, but settings or fields changed
• Rebuild: needed, but the code won't survive the jump as is
• Retire: nobody uses it, so drop it instead of migrating dead weight

This turns "check our modules" from a fuzzy task into an actual plan you can hand to someone.

4. Custom Code Compatibility With the Target Version

Once you've sorted your modules, look closer at what actually breaks inside the ones marked for rebuild.

Odoo changes its code with almost every release. Fields get renamed, models get restructured, and some methods disappear.

Newer versions also moved the frontend to OWL components, replacing the older widget system. Code built on that old system usually needs a real rewrite.

• Check the target version's changelog for renamed fields or removed methods
• Flag any frontend code still using the old widget system
• Budget extra time for modules with no remaining documentation

This is usually where migration timelines quietly double, so it pays to find out early.

5. Third Party and OCA Module Availability

Your own custom modules aren't the only risk. Anything installed from the Odoo Apps Store or from OCA needs checking too.

OCA modules often lag behind the newest Odoo release by weeks or months, since they rely on community volunteers to update them.

Paid third-party apps aren't automatically safer either. The vendor might not support your target version yet or might have dropped it entirely.

• Check each third-party app's listing for target version support
• Contact vendors directly instead of assuming compatibility
• Search OCA's repository for an updated branch before assuming a module is stuck

Don't find this out after going live, when a vendor tells you support is still "in progress."

6. A Full Backup, Database, and Filestore Both

This is the one people think they've already covered. Most have backed up the database. Fewer have backed up the filestore too.

The filestore holds your attachments, product images, and uploaded documents. It lives separately from the database itself.

Restore just the database, and it'll look successful. Then someone opens a product page, and the image is gone.

• Back up the full database, not just specific tables
• Back up the filestore directory separately
• Confirm both backups actually restore, not just that the backup file exists
• Store a copy off the server itself, not just alongside it

A backup you haven't tested restoring isn't really a backup yet.

7. Data Quality, Before You Migrate Bad Data Too

An upgrade doesn't fix messy data. It just carries the mess into your new version.

Duplicate contacts, discontinued products still marked active, and old cancelled orders all make the jump if nobody cleans them out first.

This is also your cheapest opportunity to clean up. Fixing this after migration means doing it inside a bigger, less familiar system.

• Merge or remove duplicate contacts and customers
• Archive discontinued products instead of migrating them as active
• Clear out old, cancelled, or test orders sitting in the database

A smaller, cleaner database also makes every later testing step faster.

8. Financial Data Integrity and Reconciliation

Money data deserves its own check, separate from general cleanup. Migrations expose accounting mismatches that everyday use tends to hide.

Before you migrate, reconcile your books against what's actually in Odoo, not what you assume is there.

• Confirm the trial balance matches your accounting records
• Reconcile accounts receivable and accounts payable
• Check that tax settings and fiscal positions are correct for your target version

Catch a mismatch after going live, and it's much harder to trace back to its source.

9. Integration and API Compatibility

If Odoo talks to anything else, payment gateways, shipping carriers, e-commerce platforms, or accounting sync tools, each one needs its own check.

An integration that works fine today can break silently after an upgrade, since the API on Odoo's side may have changed.

Always test with sandbox credentials, never live ones. A failed test against a live payment gateway is not a mistake you want to make twice.

• List every external system connected to Odoo
• Confirm each vendor supports your target version
• Test each integration with sandbox credentials, not production data

A quiet integration failure is often worse than an obvious one, since nobody notices until orders start piling up.

10. A Sandbox Environment That Mirrors Production

Never test an upgrade directly in production. This should go without saying, but it still happens.

A proper sandbox copies your real data, your real modules, and your real settings, just in an environment where mistakes cost nothing.

Odoo itself recommends testing the upgrade in a staging copy before touching your live database. That's not just good practice, it's their own guidance.

• Create a sandbox using a recent copy of production data
• Install the same modules and integrations as your live system
• Run the actual migration process here first, before touching production

If something breaks, you want it to break here, not in front of your team on go-live day.

11. User Access Rights and Security Settings

Migrations can quietly reset or misalign permissions, even when nothing else seems wrong.

Someone who used to see only their own sales data might suddenly see everyone's. Someone who needed edit access might lose it.

Check this before going live, and check it again right after, since some settings only reveal problems once real users log in.

• Document current access rights and roles before migrating
• Compare user permissions after migration against that original list
• Test login and access with a few real accounts, not just the admin account

A permissions mistake often isn't loud. It just sits there until the wrong person sees the wrong number.

12. A Testing Plan That Covers Every Department

IT testing a migration alone will miss things. Sales, inventory, and accounting all use Odoo differently, and each can catch problems IT wouldn't think to check.

Pull in one person from each department to test their own daily tasks in the new version.

• Have sales test quotes, orders, and pricing rules
• Have inventory test stock moves and reordering
• Have accounting test invoices, payments, and reports
• Log every issue found, even small ones, before going live

A bug found in testing is an easy fix. The same bug found in production is a fire drill.

13. Team Training Before Go Live

Even a flawless migration fails if nobody knows how to use the new version. Interfaces shift, buttons move, and old habits stop working.

Training doesn't need to be one size fits all. Different departments only need to know what affects their own work.

• Walk each department through the changes specific to their daily tasks
• Pick one person per department as the go-to contact for questions
• Schedule training close to go live, so it's still fresh when the switch happens

A quiet migration on the backend still needs a loud, clear heads-up for everyone using it.

14. A Go Live Window and a Rollback Plan With Real Triggers

Pick a go-live time when the business can absorb some disruption, usually a slow period or a weekend.

The rollback plan matters more than most teams realize. "We'll roll back if something goes wrong" isn't a plan, it's a hope.

Set specific, measurable conditions ahead of time. And know this going in: in practice, rolling back a completed upgrade is rarely realistic, so treat go-live as the real decision point.

• Choose a go-live window with the least business impact
• Write down exact conditions that would trigger a rollback
• Confirm rollback is only realistic before the migration is finalized, not after

Deciding this in the moment, under pressure, is how good teams make bad calls.

15. A Post-Migration Monitoring Plan for the First 30 Days

Going live isn't the finish line. The first month after migration is when smaller issues actually surface.

Check in daily for the first week, then shift to weekly as things stabilize.

• Track system performance and error logs
• Confirm integrations are still running correctly
• Watch for user-reported bugs and unusual behavior
• Reconcile financial data again after the first full week

A migration that looks clean on day one can still have small cracks that only show up under real, everyday use.

Ready to Move to Your New Odoo Version?

View Migration Services

Your Odoo Migration Readiness Scorecard

Here's a quick way to use everything above. Go back through the 15 checks and count how many you can honestly mark as done.

• 12 to 15 checked: You're ready to set a go-live date
• 8 to 11 checked: Close, but close the remaining gaps first
• Under 8 checked: Treat this list as your project plan, not a final check

This isn't about perfection. It's about knowing where you actually stand before you commit to a date.

Common Mistakes That Break Good Migrations

A few mistakes show up again and again, even in migrations that were otherwise well planned.

• Treating a small version bump as risk-free, without checking what changed underneath
• Backing up the database but forgetting the filestore
• Skipping the sandbox because production seemed stable
• Going live without a clear, specific rollback trigger

None of these feel serious on their own. Together, they're how a well-planned migration still goes wrong.

Why a Migration Partner Like Softhealer Is Worth It

An Odoo migration touches your entire business, from accounting to inventory to every custom workflow your team runs on. Getting it wrong is expensive.

Softhealer is an Odoo Gold Partner, and every migration we run is built on 99% uptime and zero data loss. Your team keeps working, and your data stays exactly where it should be.

That comes from doing this across dozens of setups, versions, and industries. Knowing the 15 things to check matters less than knowing what to do when three go wrong at once.

Planning an upgrade? Explore our Odoo migration services and let's map out your move to the new version.

FAQs

1. How long does an Odoo migration take?

It depends on how many custom modules and integrations you have. A simple setup might take a week or two. A heavily customized system can take a few months.

2. Should I clean my data before upgrading Odoo?

Yes. Cleaning duplicates and outdated records before migration is far easier than doing it inside a new, unfamiliar version afterward.

3. Why is a sandbox environment important?

It lets you find problems before they reach your real data. Testing in production risks breaking things your whole team depends on.

4. Do I need to migrate every custom module?

No. Some modules can be replaced by newer standard Odoo features, and others may no longer be needed at all.

5. Can I lose data during an Odoo migration?

It's possible if backups aren't tested properly beforehand. A verified backup, database, and filestore are all your safety nets.

6. How do I know if my company is ready to migrate?

Run through the 15 checks above. If you can honestly check off most of them, you're in good shape to set a date.