Odoo 20 readiness checklist: the work you can do now

You can prepare for Odoo 20 now without knowing a single new feature. The work that decides how an upgrade goes is the same every year: know your custom modules and Studio changes, clean your data, keep a test database, map your integrations, plan training and set a budget. Do these six things and the Odoo 20 decision becomes a question of timing, not a scramble.

This checklist applies whether you move to Odoo 20 soon after release or a year later, and whether you are on Odoo 19 already or several versions behind. None of it depends on what Odoo announces at Odoo Experience. For what is actually known about Odoo 20 so far, see what we know before the release.

Inventory your custom modules and Studio customisations

This is the item that drives cost. Odoo's upgrade service converts standard apps and data. It does not port third-party or in-house modules unless they are covered by a maintenance-of-customisations subscription. Odoo's documentation is explicit: a database with custom modules cannot be upgraded until those modules exist for the target version.

Start with a list of every installed module that Odoo didn't write. On a self-hosted or Odoo.sh database, a read-only query gives you a first draft:

SELECT name, author, latest_version
  FROM ir_module_module
 WHERE state = 'installed'
   AND author NOT IN ('Odoo S.A.', 'Odoo', 'Odoo SA')
 ORDER BY author, name;

For each module, record four things: who maintains it, whether the source is in your own repository, what business process it supports, and whether anyone still uses it. Modules nobody can explain are candidates for removal before the upgrade, not after.

Studio customisations are stored in a generated module called studio_customization. Under Odoo's upgrade SLA they are upgraded as long as Studio is still installed and the subscription is active. That is good news, but don't skip them. Automations, computed fields and report edits made in Studio still need testing. Our Studio guide covers where those changes live.

Clean your data before it is converted

Odoo's SLA says plainly that cleaning pre-existing data and configuration is not part of the upgrade service. Whatever mess is in the database today will be converted faithfully into Odoo 20.

• Contacts: merge duplicates, and archive customers and vendors you no longer deal with.
• Products: archive dead products and variants. For Indian companies, fill in the HSN/SAC code on every product you sell, because GST reporting depends on it.
• Accounting: post or delete old draft entries, reconcile what can be reconciled, and close past periods properly.
• Inventory: resolve negative stock and old unreserved moves, so the valuation you carry forward is one you trust.
• Users: archive people who have left, and review who holds Administration / Settings rights.

If you came from Tally or another system and imported opening balances in a hurry, this is the moment to check that those balances still tie to your books.

Set up a test database you can rebuild on demand

Every upgrade we run goes through several test upgrades before production. Odoo recommends the same: request an upgraded test database, test it, report issues, and request a fresh one again close to go-live, because both the standard upgrade scripts and your data keep changing.

Odoo neutralises test databases: scheduled actions are disabled, outgoing mail servers are replaced with a fake one, payment providers and carriers go to test mode, and bank synchronisation is turned off. Make sure your team knows this, or someone will report missing emails as an upgrade bug.

On Odoo.sh a staging branch already gives you this. On-premise, you need a server that can restore last night's backup in one command. If that takes a day of manual work today, fix it first.

Map every integration

Integrations break quietly. Write down every system that talks to Odoo: payment gateways, bank feeds, shipping carriers, e-commerce connectors, BI tools, and, in India, GST e-invoicing and e-way bill. For each, record the endpoint it uses, the user or API key it logs in with, and who owns it on the other side.

Look at the protocol too. Odoo 19 introduced the external JSON-2 API at /json/2. Odoo's documentation states that the XML-RPC and JSON-RPC endpoints (/xmlrpc, /xmlrpc/2, /jsonrpc) are deprecated and scheduled for removal in Odoo 22 (fall 2028). Moving to Odoo 20 won't force the change, but any integration you rebuild now should use JSON-2.

Plan user training around the changes

Odoo's upgrade service does not include training on the new version. Users will notice changes in screens and workflows even when your processes stay the same. Plan three things:

• A short list of key users per app, who test the upgraded database and then train their teams.
• Test scripts written in your own terms ("raise a GST invoice for an interstate customer"), not Odoo's.
• Time in the calendar. Avoid month-end, GST filing dates, payroll runs and your busy season.

Budget for the upgrade

The budget has four lines. Odoo Enterprise includes the upgrade of standard apps and Studio customisations. Custom and third-party modules are ported by whoever maintains them, or by a partner. Testing takes your own staff's time, which is usually the line people forget. Training comes on top. For licence changes, check Odoo's pricing page. We don't quote prices here because they change.

The biggest variable is the custom module list from the first section, so do that first. Once you have it, upgrade effort can be estimated module by module instead of guessed.

If your inventory shows you are more than one version behind, read planning a multi-version jump to Odoo 20. For the Odoo 19 upgrade path specifically, see upgrading to Odoo 19 from 16, 17 or 18. When you are ready for a test upgrade, start one with us.