Odoo 20 Readiness Checklist: Release Date, Features and Upgrade Planning

Figure out where you stand

• Check your exact Odoo version. The major number alone hides too much. Are you on 17.0, 18.0, 19.0, or one of the Odoo Online releases from 19.1 to 19.4? Online databases on those releases already carry part of what Odoo 20 brings. Odoo.sh and on-premise databases run major versions only and meet those changes for the first time in Odoo 20. Each starting point has a different upgrade path, and jumping multiple versions (say, 17 to 20) is doable with more planning and testing than a single-version hop.
• List every installed module. Include core, OCA, marketplace, and custom modules. Third-party modules can block an upgrade when a compatible release, maintainer, dependency path, or test result is unavailable.
• Document your custom code. Inventory Python overrides, JavaScript widgets, QWeb report templates, and API integrations. Undocumented custom code can materially increase review and test effort. Flag JavaScript separately, because custom front-end widgets are the code most likely to need porting between major versions.
• Map every integration, then check how it authenticates. Payment gateways, shipping carriers, eCommerce platforms, banking feeds, EDI connections, custom APIs. For each one, find out whether it talks to Odoo over XML-RPC or JSON-RPC, because those endpoints are formally deprecated and Odoo has now published removal dates. Anything using the db service is already out of road in Odoo 20.
• Record database and filestore size. Run SELECT pg_size_pretty(pg_database_size('your_db')) in PostgreSQL and measure the filestore separately. Use timed staging rehearsals, backup and restore tests, hosting limits, and the approved downtime window to estimate cutover duration.
• Review your server specs. Write down your CPU, RAM, storage, PostgreSQL version, and Python version now so you have a baseline. Those last two decide how much work Phase 2 is, since Odoo 20 raises both minimums.

Get your tech stack ready

• Confirm the supported upgrade path. A direct multi-version upgrade may be possible, but it needs more compatibility, migration, and regression testing than a single-version path. Compare a direct route with an intermediate upgrade using Odoo's current upgrade guidance, hosting model, custom modules, integrations, and staging evidence.
• Move PostgreSQL to 16. This is settled. Odoo's 20.0 install documentation records the change: the minimum goes from PostgreSQL 13 to 16. Run psql --version to check where you are. A major PostgreSQL upgrade deserves its own change window, its own dump-and-restore rehearsal, and its own rollback plan, all separate from the Odoo upgrade.
• Move Python to 3.12. Also settled and also documented: Odoo 20 raises the minimum from Python 3.10 to 3.12. Check with python3 --version. On older LTS distributions this can mean a base image change or an OS upgrade. That is exactly the kind of surprise you want to find in July, because finding it in October is how cutover dates slip.
• Inventory anything speaking XML-RPC, then plan its exit. Odoo's documentation is now explicit. The db service is removed in Odoo 20. The common and object services are scheduled for removal in Odoo 22 (fall 2028). The replacement is the External JSON-2 API at /json/2/<model>/<method>, using a bearer API key. You do not need to rewrite everything this year, though you do need to know what breaks in 20 and what has a 2028 deadline. Note that external API access needs the Custom plan, since One App Free and Standard exclude it.
• Contact your third-party module vendors now. Ask every OCA module maintainer and marketplace app vendor whether an Odoo 20 version is published and tested, and when it will be if it is not. If something critical has no Odoo 20 release yet, plan around it before you set a cutover date.
• Build a staging environment. Clone your production system completely: same version, same modules, same data volume, same integrations. This is your test bed for everything that follows.
• Run the upgrade script on staging. As soon as Odoo's official upgrade platform offers Odoo 20 as a target for your database, request a test upgrade of a production copy into staging. Write down every error and warning.
• Port your custom modules. Expect changes in ORM methods, the web framework, and QWeb templates. Estimate the work only after inventorying each module, dependency, test path, maintainer, and JavaScript surface; custom widgets can materially change the effort.
• Test every integration against staging. Run each API connection against your Odoo 20 staging instance. Watch for authentication changes, the deprecated RPC endpoints above, and anything that quietly depends on the removed db service.

Clean your data

• Merge duplicate records. Duplicate contacts, products, and vendors confuse AI agents because the system can't tell which record is the real one. Clean these up before the upgrade starts.
• Standardize your naming. Product names, customer categories, warehouse locations, chart of accounts. If your team has been naming things inconsistently for years, now is the time to fix it. AI pattern recognition breaks when "Widget A" and "widget-a" and "Widget Type A" are all the same product.
• Archive old records. Products you stopped selling two years ago, contacts who never responded, completed projects from 2023. Archiving reduces your database size (faster upgrades) and keeps the AI focused on current data.
• Verify your financials. Run a trial balance. Make sure open invoices match bank statements. Check your chart of accounts for orphaned entries. Anything Odoo 20's AI agents read or report on is only as reliable as the historical data behind it.
• Back everything up. Full database backup including filestore, stored offsite. Test restoring it. This is non-negotiable before any upgrade work starts.
• Document custom fields and relations. Every custom field, computed field, and relational override needs to be checked against Odoo 20's updated data model. If you don't have a list, make one now.

Prepare your team

• Pick one upgrade champion. One person who owns the project from start to finish. They coordinate between departments, track progress on this checklist, and are the main contact for your Odoo partner.
• Document how people actually use Odoo today. Not the process documentation from your original implementation. How your team actually works. This becomes your baseline for measuring what Odoo 20's AI can take off their plates.
• Identify what the AI should handle. Go through your workflows and flag the repetitive stuff: PO generation, lead assignment, inventory reordering, invoice matching, customer follow-ups. These are candidates for Odoo 20's agentic AI.
• Schedule training time. Set the training plan by role, workflow risk, permissions, and acceptance criteria. The focus should include when to trust AI-assisted actions, when to override them, and how exceptions are reviewed.
• Tell everyone what's happening. Share the upgrade timeline with affected owners. Include expected downtime, workflow changes, acceptance responsibilities, and the named support and escalation route for the approved stabilization period.
• Write a rollback plan. Define what would trigger a rollback to the previous version. Include the procedure, who's responsible, and how you'd communicate it. You probably won't need it, but having it written down means you won't panic if something goes sideways.

Plan the actual go-live

Everything above is preparation. This is the part where you pick a date and commit. Don't rush it. A delayed upgrade beats a botched one every time.

• Aim for Q4 2026 or Q1 2027. Odoo 20 is out, and production should move only after compatibility evidence exists. Use Q4 2026 or Q1 2027 as planning windows, then choose the actual go-live date after staging, module checks, user acceptance testing, and cutover rehearsal.
• Choose a controlled cutover window. Avoid close cycles, filing deadlines, peak demand, or other business-critical periods. Select the date from rehearsed duration, rollback criteria, staff availability, reconciliation needs, and the approved support plan.
• Keep the old system accessible for an agreed verification period. Where licensing and policy allow it, use read-only access so the team can cross-reference source records while reconciliation and exception checks are completed.
• Define what "success" looks like before you start. Confirm access, core workflows, financial reconciliation, integration results, record counts, agreed exceptions, rollback criteria, and sign-off. Test all of this on staging before touching production.
• Budget time for feature adoption after go-live. The upgrade is step one. Set an adoption period based on the features enabled, affected roles, controls, training results, and support plan.