# Upgrading to Odoo 20: what changes, what it requires and how to test before production > Upgrading to Odoo 20 means asking Odoo's official upgrade platform for a converted copy of your database, testing it thoroughly, and only then converting production. With an Enterprise subscription, Odoo converts standard apps, Studio customizations and modules under a maintenance contract at no extra cost; custom and third-party modules without that contract are adapted by whoever maintains them, and the database cannot be upgraded until their 20.0 version exists. On-premise, Odoo 20 requires Python 3.12 to 3.14 and PostgreSQL 16 or later. A database on 19.0 keeps standard support until September 2028, so there is time to plan the move. - Author: Eduin Garnica, CTO, Quantum Garage - Published: 2026-10-17T00:00:00-06:00 - Updated: 2026-10-17T00:00:00-06:00 - Odoo version: 20 - URL: https://web.quantumgarage.io/en/guides/upgrade-to-odoo-20/ ## What a version upgrade is in Odoo Odoo releases one major version a year —18.0 came out in October 2024, 19.0 in September 2025 and 20.0 in September 2026— and each gets three years of standard support. Upgrading means moving your database from one version to a more recent one, with its data, its apps and the custom code that extends them. Odoo calls this process an *upgrade* and provides it as a service within the Enterprise subscription. If you came to this guide looking for a different kind of move, it helps to know now: the official documentation excludes from a version upgrade going back to an earlier version, switching editions —from Community to Enterprise, for example—, changing hosting type and migrating from another ERP. Each of those is a separate project with its own process. - **Upgrade**: The process by which Odoo converts a database from one version to a more recent one, with its data and its apps. - **Upgrade platform**: Odoo's service at upgrade.odoo.com that receives the database, converts it and returns either a test copy or the upgraded production database. - **Test database**: An upgraded copy of production with the features that reach the outside world disabled, made to test without affecting operations. - **Custom module**: Your own code that extends Odoo's standard behavior and was not built with the [Studio](https://web.quantumgarage.io/en/glossary/odoo-studio/) app. - **Third-party module**: A module written neither by Odoo nor by your company, such as those from the Odoo Apps Store or from another vendor. ## What changes in Odoo 20 The Odoo 20 release notes, published in September 2026, cover dozens of apps and localizations. For an upgrade they don't weigh the same: some new features are optional, while others change how the system is built and force a review of custom code. The table gathers the ones that matter most for a mid-sized company, including the Mexican localization for those operating in Mexico, paraphrasing the release notes, and leaves out the items the notes mark as also available in 19.0. Table: Odoo 20 changes that matter in an upgrade | Change | What the release notes say | What it means for the upgrade | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | AI runs on credits | All AI features now require credits bought through in-app purchases. | AI usage is bought separately: Odoo's pricing page lists it among what its plans don't include. | | MCP server | You can connect to your database through MCP (Model Context Protocol). | An external AI agent can read or modify the database with the permissions of the user who connects it. | | Access permissions | Access permissions were simplified by removing record rules and adding a domain directly at the access level, to set which records each permission applies to. | Custom modules that declare permissions or rules in the 19 format are adapted to the new model. | | Chatter tracking values | Tracking values were removed and the tracking message is now generated on the fly; administrators who still need them can install a dedicated module. | If a report or an audit relied on those values, that module is installed before signing off the upgrade. | | Mexican localization | A cancellation certificate for cancelled CFDI (Mexico's electronic invoice), bimonthly global invoices, balance sheet and profit-and-loss reports based on NIF B-6 and B-3 (Mexican Financial Reporting Standards), supplementary XML trial balance reports, automatic download of missing vendor bills from the SAT (Mexico's tax authority) with the company's FIEL (its advanced electronic signature), selecting the driver of a Carta Porte (the CFDI complement for goods in transit) on the delivery order, and updated minimum wage, income tax tables and UMA (Mexico's reference unit for fines and thresholds). | They are tested on the test database against the company's real tax setup. | The permissions change is the one that takes the most work when there is custom code, and it shows plainly in the 20.0 branch of Odoo's code: the base module no longer ships the record-rule model, `ir.rule`, and ships a new one, `ir.access`, which stores next to each permission the domain of records it applies to. The Sales module is a good example: in 19.0 it declared its permissions in `ir.model.access.csv` and its rules in `ir_rules.xml`; in 20.0 it declares a single file, `ir.access.csv`. Odoo's documentation lists, among the errors that show up when installing a module on the new version, references to standard fields, models or views that no longer exist or were renamed. A module written for 19 that declares its permissions in the old format falls exactly into that case, which is why it is adapted before upgrading. ## When you have to upgrade Support sets the urgency. During standard support, Odoo provides security updates, bug fixes and helpdesk support. When it ends, extended support begins: it carries an extra fee, exists only on Odoo.sh —for some versions— and on-premise, and no longer includes security updates. The table shows where each current major version stands, according to the support table Odoo publishes. Table: Support status of Odoo major versions as of October 17, 2026 | Version | Released | End of standard support | Status | | --------- | -------------- | ------------------------ | ----------------------------------------------------------- | | Odoo 20.0 | September 2026 | September 2029 (planned) | Standard support on Odoo Online, Odoo.sh and on-premise | | Odoo 19.0 | September 2025 | September 2028 (planned) | Standard support on all three hosting types | | Odoo 18.0 | October 2024 | September 2027 (planned) | Standard support on all three hosting types | | Odoo 17.0 | November 2023 | September 2026 | Extended support only, for a fee, on Odoo.sh and on-premise | A database on 19.0 therefore has almost two years of standard support ahead: from October 2026 to September 2028 is 23 months, and no date forces an upgrade this year. What does change over time is the cost of falling behind. Odoo's subscription agreement calls the three most recent major versions «Covered Versions» —today 20.0, 19.0 and 18.0— and, once a year and no earlier than six months after a major release, charges an extra 25% of the annualized price to a database on a version older than those. With 20.0 released in September 2026, that fee can reach a database on 17.0 or earlier from March 2027. Choosing the target version is simple: you can upgrade from any version to any major version still under standard support, or that left it less than six months ago. A database on 17.0 or 18.0 can go straight to 20.0 without stopping at 19.0. Each hosting type adds its own limit. On Odoo Online, a major version must be upgraded every two years; on [Odoo.sh](https://web.quantumgarage.io/en/glossary/odoo-sh/), once the three years of support end there are two more to complete the upgrade, so a database on 19.0 would have until 2030; on-premise, a database can stay on its version indefinitely, although the documentation advises against it and notes that the smaller the version gap, the easier the upgrade. ## Technical requirements on-premise On Odoo Online and Odoo.sh, Odoo runs the infrastructure, so this section only concerns companies that host Odoo on their own servers. There, version 20 raises two minimums: according to its documentation, Python goes from 3.10 to 3.12 and PostgreSQL from 13 to 16. The 20.0 code also sets a ceiling for Python, because the `odoo/release.py` file declares 3.12 as the minimum and 3.14 as the maximum. The table brings together what the version asks for and what Odoo does when the server falls short, as read in the code itself. Table: What Odoo 20 requires on your own server | Component | What 20.0 requires | What happens outside that range | | ------------------------------ | ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Python | 3.12 to 3.14 | Below 3.12, Odoo does not start; above 3.14, it starts and warns that the version is not officially supported. | | PostgreSQL | 16 or later | On an older version, Odoo issues a warning that it is below the minimum. | | PostgreSQL pg-vector extension | Required by the documentation to use the AI features | The extension is only available for PostgreSQL 15 and later. | Do the math on your current server. One running 19.0 on PostgreSQL 14 meets the 19 minimum, which is 13, but not the 20 minimum, which is 16: the database server gets upgraded as part of the project, before the converted database is restored on it. The same goes for the operating system, since Odoo 20's packaged installers are published for Ubuntu Noble (24.04 LTS), as a .deb package, and for Fedora 42, as an .rpm. There is also a network requirement that tends to surface late: the upgrade script needs to reach the platform's servers on TCP port 443 and on any TCP port between 32768 and 60999, which on a restrictive firewall calls for an exception. ## How the official process works The upgrade Odoo documents has seven steps, and their order protects operations: the production database is not touched until step six, and everything before it happens on copies. 1. Request a test database upgraded to the target version. 2. If there are custom modules, adapt their code to the new version. 3. Test the test database thoroughly. 4. Report every issue found to Odoo through its support page, choosing the option for an upgrade under test. 5. Once the issues are resolved and the test database could serve as your main database, plan the production upgrade. 6. Request the production upgrade; the database is unavailable while it runs. 7. Report any issue with that upgrade to Odoo through the production option of its support page. What changes between hosting types is where each copy is requested and what happens to custom code. Odoo.sh is integrated with the upgrade platform and works on [staging](https://web.quantumgarage.io/en/glossary/staging/) branches; on-premise uses a command and returns a backup you restore yourself; Odoo Online handles it from its database manager. The table sums up those differences as the documentation describes them. Table: How the upgrade is done on each hosting type | Moment | Odoo Online | Odoo.sh | On-premise | | ---------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Requesting the test database | From the database manager, with the purpose set to «Test» | From the project: Odoo sends the latest daily production backup to the platform and returns the upgraded database on a staging branch | With the command `python <(curl -s https://upgrade.odoo.com/upgrade) test -d -t ` or from upgrade.odoo.com | | Testing custom code | Not applicable: Odoo Online does not allow modules with Python code, so it cannot run upgrade scripts either | Every commit on the branch restores the upgraded database and updates all custom modules | Restore the upgraded dump and update the modules with `odoo-bin -u` | | Upgrading production | Same flow with the purpose set to «Production»; once finished, there is no way back to the previous version | Triggered by a commit on the production branch; if anything fails, the platform reverts the upgrade, and if it succeeds, it keeps a backup from before | The command replaces `test` with `production`; the copy travels without its filestore, the attachments folder, which is merged with production's before going live | Every completed upgrade comes with an upgrade report, attached to the email for the upgraded database and posted in Discuss for administrators, listing the changes the new version introduced. And with an Enterprise subscription, the conversion is not billed separately. The documentation puts it this way: > “With Odoo Enterprise, upgrading a database to the most recent version of Odoo is free, including any support required to rectify potential discrepancies in the upgraded database.” Odoo, “Upgrade”, official Odoo 20.0 documentation, accessed October 17, 2026. That service is limited to the technical conversion: adapting standard modules and their data to the target version. Cleaning up pre-existing data and configuration, training on the new version, and converting modules without a maintenance contract are not included, and that is what the next section is about. ## Custom and third-party modules Of everything in a database, custom code is the only part Odoo does not convert on its own, and that is why it sets the schedule. The rule is on the same upgrade page: > “If your database contains custom modules, it cannot be upgraded until a version of your custom modules is available for the target version of Odoo.” Odoo, “Upgrade”, official Odoo 20.0 documentation, accessed October 17, 2026. Who builds that version is settled by the contract. The Enterprise Subscription Agreement calls an *Extra Module* any code that adds features or changes standard behavior, whether written by the customer, by Odoo, by a partner or by a third party, including Python-based customizations made inside the database with Studio. It calls a *Covered Extra Module* one used on Odoo Online or one with a maintenance fee paid. The table below follows from that, combining the contract with the coverage section of the upgrade documentation. Table: Who converts each part of the database in an upgrade | Part of the database | Who converts it | Condition | | --------------------------------------------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Standard apps | Odoo, within the subscription | None beyond the subscription | | Customizations made with Studio | Odoo | Studio is still installed and the subscription is active | | Modules under a maintenance contract | Odoo, or the partner Odoo subcontracts those services to | The maintenance fee is paid; the contract computes it per 100 lines of code | | Custom or third-party modules without that contract | Whoever maintains them: the company's team, its partner or the module's author | Their 20.0 version must exist before upgrading | For the modules that fall to their maintainer, the documentation sets out six steps, each aimed at a different risk. The first is to freeze development, because any feature that changes mid-upgrade will have to be upgraded and tested again; bug fixes are exempt. The same step compares what was developed against what the new version already offers: a feature that Odoo 20 covers as standard is code worth retiring, since it lightens this upgrade and the next ones. The second is to request an upgraded database only to confirm the standard conversion works. The third is to install each module, one at a time, on an empty 20.0 database, which is where invalid dependencies, syntax changes and references to fields, models or views that no longer exist come up; the permissions change described above is caught here. Once the modules install, you test views, email templates, reports, server and automated actions, changes to standard flows and computed fields, and you write automated tests to repeat that review on every pass. The fourth step brings the modules onto the upgraded database. That is where upgrade scripts come in, backed by Odoo's upgrade utilities library, to rename fields, models or identifiers without losing data, and where you review the upgrade report, which lists the views that were disabled because they caused errors. The fifth is another round of testing and a full rehearsal the day before production, and the sixth is the production upgrade. A module from the Odoo Apps Store follows the same rule as your own, because for Odoo it is also a custom module: its 20.0 version is published by whoever maintains it, and until it exists, the database is not upgraded. That is why the inventory of installed third-party modules, with each one's author and whether a 20.0 version is out, belongs at the start of the project and not at the end. ## Odoo 20's AI and the MCP server Artificial intelligence is the most visible new feature in version 20, and for an upgrade it helps to split it in two. The first piece is the AI app inside Odoo, with agents that understand natural-language requests and carry out tasks with the tools they are given. Using it consumes in-app purchase credits, and the documentation warns that installing it on a database on the Standard plan triggers a move to the Custom plan. On-premise, it also requires PostgreSQL's pg-vector extension. The second is the [MCP server](https://web.quantumgarage.io/en/glossary/mcp-server/). The *Model Context Protocol* is an open standard that lets a language model interact with external applications and access their data, and Odoo 20 uses it so that an external AI agent can read or modify the database from its user's own tools. The 20.0 documentation gives it a dedicated page, which the 19.0 documentation lacks, and four decisions come out of it before you open it up: - **Authentication —** OAuth is the recommended method, because the user approves access from their client without copying or exposing keys; only internal users can use it, and portal users connect with an API key. - **Permissions —** every request from the client is authenticated with the user's identity and permissions in Odoo, so the agent sees and changes exactly what that user can see and change. - **Exposed tools —** out of the box, the database offers the client five query tools: `AI Tool: Get Fields`, `AI Tool: Get Models`, `AI Tool: MCP Retrieve initial context`, `AI Tool: Search` and `AI Tool: Read group`. Any other tool is exposed by hand, one at a time, from the server actions. - **Revocation —** each connection shows up as an API key in the user's preferences and is revoked by deleting it, so closing access doesn't require touching the server. ## How to test before going to production The test database exists so you can make mistakes without consequences, and Odoo delivers it neutralized so that nothing done in it leaves it: - **Scheduled actions disabled —** no automatic process runs on its own during testing, so a scheduled computation or mailing doesn't fire twice. - **Outgoing email disabled —** Odoo archives the mail servers and adds a fake one, so no customer or vendor receives emails from the test. - **Payments and shipping in test mode —** payment providers and carriers are reset to their test environments, so a charge or a shipping label created in the copy is not real. - **Bank synchronization disabled —** to test it, you need sandbox credentials from your bank synchronization provider. On that copy, the documentation proposes a basic checklist: your usual views display correctly and no view is disabled in the test database while active in production; reports such as invoices and sales orders generate; website pages work; records can be created and modified; email templates, saved translations and search filters are still there; and data can be exported. It adds five areas that tend to be forgotten: integrations with other systems, flows that cross apps —from a lead to a sales order to a delivery—, data exports, automated actions and server actions. For a company operating in Mexico, the localization belongs in the same review: the tax-related changes in the table above are tested against the real setup, with whoever handles the company's Mexican tax compliance. The end-to-end test Odoo suggests follows one product through its whole cycle: buy it, receive it, sell it, ship it, invoice it, issue its credit note and check the accounting reports, comparing every step against production. If something fails, report it through Odoo's support page with the option for an upgrade under test. Do it during testing and not later, because the new version's changes to standard views, fields and models are not reverted case by case: if they break a customization, adapting it falls to whoever maintains the module. For production day, the documentation asks for three things. First, request fresh test databases often while the project runs, because Odoo's scripts and your own database keep changing. Second, rehearse the full upgrade the day before. Third, schedule it when usage is lowest, because the database is unavailable while it converts; on-premise, anything recorded in production after the copy is sent won't reach the upgraded database, so the database is not used during the process. If the rehearsal the day before comes out clean and the test database already carries the full operation, the production upgrade is the repeat of something that already worked. ## Frequently asked questions ### When was Odoo 20 released, and how long is it supported? Odoo 20.0 was released in September 2026, and Odoo's support table plans standard support until September 2029: the three years every major version gets. ### Can we upgrade from Odoo 17 or 18 straight to 20, skipping 19? Yes. Odoo allows upgrading from any version to any major version still under standard support, and 20.0 is. The documentation notes that the smaller the version gap, the easier the upgrade. ### How much does upgrading to Odoo 20 cost? With Odoo Enterprise, converting the database to the most recent version is free, including support to fix discrepancies in the upgraded database. Data cleanup, training, and adapting custom or third-party modules without a maintenance contract are not included. ### Does the upgrade also move us from Community to Enterprise, or from Odoo Online to Odoo.sh? No. Odoo's documentation excludes switching editions and changing hosting type from a version upgrade: each one is a separate process. Moving to Enterprise is planned separately, and with Enterprise the conversion to each new version is included. ### Does Odoo 20 have an MCP server? Yes. The 20.0 documentation has a page for Odoo's MCP server, which lets an external AI agent read or modify the database with the permissions of the user who connects it. The 19.0 documentation has no such page. ## Sources 1. Odoo S.A., “Upgrade”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 2. Odoo S.A., “Standard and extended support”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 3. Odoo S.A., “Upgrade a customized database”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 4. Odoo S.A., “Odoo 20 release notes”, odoo.com. . Accessed 2026-10-17T00:00:00-06:00. 5. Odoo S.A., “Source install”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 6. Odoo S.A., “Packaged installers”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 7. Odoo S.A., “odoo/release.py”, public odoo/odoo repository, 20.0 branch. . Accessed 2026-10-17T00:00:00-06:00. 8. Odoo S.A., “odoo/addons/base/models/ir_access.py”, public odoo/odoo repository, 20.0 branch. . Accessed 2026-10-17T00:00:00-06:00. 9. Odoo S.A., “AI”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 10. Odoo S.A., “AI MCP server”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 11. Odoo S.A., “Odoo Enterprise Subscription Agreement, version 13 (September 24, 2026)”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00.