Odoo Migration Checklist: 8 Steps From Audit to Go-Live

An Odoo migration checklist has eight steps: choose your upgrade path, audit what you run, port your custom modules, test on a copy of your database, validate the numbers, freeze and cut over, keep a rollback ready, and check everything after go-live. Most failed upgrades skip the audit or trust a test copy that never tested email, payments or scheduled jobs.

This checklist works for any version, from Odoo 14 to Odoo 20, on Odoo Online, Odoo.sh or your own server. It follows Odoo's own upgrade documentation, adds the failure points we see in real projects, and says who owns each step. If you are moving to Odoo 20 specifically, use it together with our Odoo 20 upgrade checklist, which has the version-specific test cases and the go/no-go decision. If you would rather have specialists run it, that is what our Odoo migration services do.

The checklist at a glance

Step 1: Choose your upgrade path

The route depends on your edition and hosting, so settle it before you plan anything else. On Odoo Enterprise, Odoo's upgrade service converts your database, and the documentation states that upgrading to the most recent version is free. On Odoo Community, you use OpenUpgrade, the open source project run by the Odoo Community Association (OCA), and you do the work yourself or with a partner.

Two moves are outside this checklist. Switching from Community to Enterprise is not a normal version upgrade; see our Community to Enterprise migration guide. Coming from another system such as Tally is a data migration, not an upgrade. If you are several versions behind, our guide to upgrading old Odoo versions to Odoo 20 explains how many steps sit in between, and the Odoo supported versions guide shows which versions still get bug and security fixes.

Step 2: Pre-migration audit

The audit decides your cost and your risk. Most surprises in an upgrade come from something nobody listed: a module installed years ago, a report edited directly in the database, or a script that reads Odoo every night. Work through each item and write the answer down.

• ☐ Version, edition and hosting. Note the exact version (for example 17.0, not "Odoo 17-ish"), Community or Enterprise, and Odoo Online, Odoo.sh or your own server.
• ☐ Every installed module, sorted by type. Standard Odoo apps, Studio customizations, your own custom modules, third-party apps and OCA modules. For each one, record who maintains it, whether it is still used, and whether a maintenance contract covers it.
• ☐ Remove what you no longer use, in production first. Modules removed only on a test branch can still block the upgrade, because the upgrade starts from a copy of your live database.
• ☐ Anything edited directly in the database. Views, report templates and email templates changed through the settings screens rather than in a module. Upgrades can overwrite or disable them.
• ☐ Integrations. E-commerce, payment gateways, shipping, bank feeds, e-invoicing, BI tools and any script that reads or writes Odoo through its API. Note who owns each one and how you will test it.
• ☐ Things that run on their own. Scheduled actions, automated actions, outgoing email, payment providers, delivery carriers and bank synchronisation. Odoo switches these off in test copies (see step 4), so list them now and plan a separate test.
• ☐ Data health. Duplicate contacts and products, draft entries nobody will post, unreconciled bank lines, and stock moves stuck in odd states. Clean them before the upgrade; Odoo's upgrade service does not cover data cleaning.
• ☐ Backups that include attachments. A database dump plus the filestore (attachments and images), restored once on another machine to prove it works.
• ☐ Users and access rights. Record the current roles so you can compare after the upgrade.
• ☐ Success criteria. Write down what "the upgrade worked" means: which reports must match, which processes must run, and who signs off.

Step 3: Custom modules

Custom code is usually the biggest cost. Odoo's upgrade service covers standard apps, Studio customizations while Studio and its subscription stay active, and customizations under a maintenance of customizations subscription. It does not cover modules built in-house or by third parties without such a contract. Those must be made compatible by whoever maintains them, before production can be upgraded.

• ☐ Freeze development. Odoo recommends "a complete freeze of the codebase when starting the upgrade process", with bug fixes the only exception. New features during an upgrade double the testing.
• ☐ Challenge every module. Some custom features now exist in standard Odoo. Dropping a module is cheaper than porting it.
• ☐ Install each module on an empty database of the target version, one at a time. This catches renamed or removed fields, models, methods and view positions before your data is involved.
• ☐ Write upgrade scripts for renamed fields and models. Without them, the data in a renamed field is lost. Odoo's upgrade-util library helps with this.
• ☐ Check records Odoo will not refresh. Records your modules load with the noupdate flag, often email templates and default settings, are not updated by the upgrade. Update them with a script if the new version needs it.
• ☐ Run the standard tests of the apps your module depends on, and make sure they still pass.

What breaks depends on the versions involved. Our posts on what Odoo 20 changes for custom modules, Odoo 19 to 20, Odoo 18 to 19 and Odoo 17 to 18 list the changes for each step.

Step 4: Test runs on a copy of your database

Never let the first real upgrade be the production one. Request an upgraded test copy, test it with the people who use Odoo every day, report what breaks, fix it, and repeat with a fresh copy until it is clean. Odoo recommends requesting new test copies regularly, because both its upgrade scripts and your data keep changing.

Blind spots in a test copy

Odoo neutralises test databases so they cannot affect your live business. According to its documentation, scheduled actions are disabled, outgoing mail servers are archived and replaced with a fake one, payment providers and delivery carriers are reset to their test environment, and bank synchronisation is disabled. A clean test run therefore proves nothing about those four areas. Test them on purpose: switch a scheduled action on by hand, send email through a test mail server, use sandbox credentials from your bank feed provider, and list anything you could not test for day one after go-live.

Test checklist

• ☐ Restore attachments if you host Odoo yourself. The upgraded copy comes without your filestore. Merge it with the production filestore before testing, or every attachment and image will look broken.
• ☐ Read the upgrade report. If a view causes problems during the upgrade, Odoo disables it and lists it in the report. Each one must be switched back on or removed.
• ☐ Check screens and documents. Usual views, invoices and sales order PDFs, website pages, email templates, saved translations, search filters and data exports.
• ☐ Run real work end to end. Buy a product, receive it, sell it, ship it, invoice it, issue a credit note, and record a payment. Add the flows your business depends on: manufacturing orders, POS sessions, payroll, projects.
• ☐ Test automated and server actions, plus every integration against its sandbox.
• ☐ Have each department test its own work and sign off in writing.
• ☐ Report issues to Odoo through its support page using the option for an upgrade you are testing. Odoo asks you to report every problem before production is upgraded.

For Odoo 20 test cases with pass/fail criteria and a severity scale for defects, use our Odoo 20 upgrade checklist.

Step 5: Data validation

"The upgrade finished without errors" and "the numbers are right" are different results. Pick a cut-off date, run the same reports on the old database and the upgraded copy, and compare them line by line. Finance and operations should own this step, not IT.

Compare amounts, not labels. Versions rename things: in Odoo 20, for example, the payment status "In Process" became "Paid" and "Paid" became "Reconciled", so a report filtered on "Paid" returns a different set of invoices after the upgrade even when nothing is wrong.

Step 6: Cut-over and change freeze

Your production database is unavailable while it is upgraded, so plan the cut-over like a small project. Odoo recommends a quiet time of day and a full rehearsal the day before.

• ☐ Rehearse the day before with a fresh test copy, and time it.
• ☐ Book a low-use window long enough for the upgrade, the checks in step 5 and a rollback if needed.
• ☐ Tell users and customers when Odoo will be offline and what to do meanwhile.
• ☐ Freeze changes. On your own server, anything entered after the database is uploaded will not be in the upgraded version, so stop all use.
• ☐ Pause integrations that write into Odoo, so orders and payments queue up instead of being lost.
• ☐ Take a final backup with attachments immediately before the upgrade.
• ☐ Name one person who decides go-live or rollback, and a deadline for that decision.

Step 7: Rollback plan

A rollback plan is a decision you make before go-live, not during it. Write down which problems trigger it, for example a trial balance that does not match, invoices that cannot be posted, or payroll that will not compute, and agree the time by which you decide.

• ☐ Know what your hosting allows. On Odoo Online, Odoo's documentation says it is impossible to revert to the previous version once the production upgrade has finished, so the test runs in step 4 are your safety net. On Odoo.sh, a failed upgrade is reverted automatically, and a successful one leaves a backup of the database as it was before the upgrade. On your own server, keep the old database, filestore and server untouched until sign-off.
• ☐ Test the restore of your final backup on another machine before cut-over day.
• ☐ Plan for the gap. Decide how transactions entered after go-live would be re-entered if you roll back.

Step 8: After go-live

The first month on a new version is when users find the edge cases. Plan checks for day one, week one and the first month-end.

• ☐ Day one: confirm scheduled actions run, email goes out, payment providers and carriers are live, and bank feeds sync.
• ☐ Day one: switch back on, or remove, every view the upgrade report listed as disabled.
• ☐ Day one: run one real sale, purchase, delivery, invoice and payment, and resume each integration while watching its log.
• ☐ Week one: keep one issue log, check access rights against the audit from step 2, and confirm the new backups actually run.
• ☐ Week one: report upgrade problems to Odoo through its support page using the option for an issue with your production upgrade.
• ☐ Month one: close the first month-end on the new version and compare it with your usual reports.
• ☐ Next upgrade: put the date your new version leaves standard support in the calendar, so the next upgrade is planned rather than forced.

Common failure points and how to avoid them

These patterns come up again and again in Odoo forum threads about failed upgrades, and in our own projects. Each one is caught by a step above.

Real example: Odoo 17 to Odoo 18 with Indian payroll

A mid-sized IT services company in India ran HRMS, Indian payroll, attendance, leave and a customised recruitment system on Odoo 17 Community. The hardest parts were custom payroll rules for PF, ESI, PT and TDS, and deprecated code in bespoke modules. Payroll cycles could not be interrupted.

We followed the same sequence as this checklist: an assessment of every custom module and deprecated API, a full migration to a staging environment where historical payroll was checked, refactoring of the payroll rules and reports for Odoo 18, parallel testing by the HR, payroll and recruitment teams, and a go-live in a low-use window with a full backup and rollback plan ready. Employee, payroll, attendance, leave and recruitment data all came across, and monthly payroll ran without disruption. Read the full Odoo 17 to 18 migration case study.

Timeline and cost

For a straightforward environment, Odiware typically completes an Odoo migration in 2 to 4 weeks. Complex environments with many custom modules, integrations or large data volumes take 2 to 3 months. The version gap, the amount of custom code and the state of your data matter more than company size, and testing usually takes longer than the upgrade itself. For what drives the price, see our Odoo migration cost guide, and for the difference between the two terms, Odoo migration vs Odoo upgrade.

Want the working version? Get the checklist kit: a printable PDF with owner and date columns, a tracking spreadsheet for every task, and an appendix of what changes between Odoo versions.

Frequently asked questions

Is the Odoo upgrade free?

For Odoo Enterprise customers, Odoo states that upgrading the database to the most recent version is free, including standard apps and Studio customizations. Custom and third-party modules without a maintenance contract, data cleaning and training are not included, and these usually make up most of the cost of a real project.

Can I skip versions when I upgrade Odoo?

In one project, yes, but the database still passes through every version's changes. On Enterprise, Odoo's upgrade service handles the in-between versions for you. On Community, OpenUpgrade must be run one version at a time, in order. Custom modules only need to be rewritten once, for the version you are moving to.

How long does an Odoo migration take?

For a straightforward environment, Odiware typically completes an Odoo migration in 2 to 4 weeks. Complex environments with many custom modules, integrations or large data volumes take 2 to 3 months. Testing and fixing usually take longer than the upgrade itself, so plan more time for steps 4 and 5 than for the cut-over.

Can Odoo Community be upgraded to Odoo 20 yet?

Not with OpenUpgrade yet. On 19 October 2026, the OpenUpgrade project had no Odoo 20 branch, and its newest coverage page was for Odoo 18 to 19. Check the coverage page for every app you use, including your country localisation, before planning a Community upgrade, or price a fresh Odoo 20 setup instead.

What does an Odoo test database not test?

Odoo disables scheduled actions, replaces outgoing mail servers with a fake one, resets payment providers and delivery carriers to their test environment, and disables bank synchronisation in test databases. A clean test run does not prove those work, so test each of them on purpose and check them again on the first day after go-live.

What happens to custom views that break during the upgrade?

If a view causes a problem during the upgrade, Odoo disables it and lists it in the upgrade report. The screen may then miss fields or fail to open. Each disabled view must be fixed and switched back on, or removed if you no longer need it, ideally through an upgrade script so the fix is repeatable.

Do I need to stop using Odoo during the upgrade?

Yes. Odoo's documentation says the production database is unavailable while it is being upgraded, and on your own server anything entered after the database is uploaded will not appear in the upgraded version. Plan a quiet window, tell users in advance, and pause integrations that write into Odoo until the upgrade is confirmed.

Should I clean my data before upgrading Odoo?

Yes. Odoo's upgrade service does not cover cleaning existing data or configuration, so duplicates, stuck drafts and unreconciled lines come across as they are. Cleaning them first makes the test runs faster to check, makes the before-and-after comparison in step 5 meaningful, and stops old problems moving into the new version.

Sources: Odoo's upgrade documentation and guide to upgrading a customized database, the Odoo 20 release notes, and the OpenUpgrade documentation from the Odoo Community Association, all checked on 19 October 2026. Odoo's policies and OpenUpgrade's coverage change, so confirm the details for your edition before you plan an upgrade.