Why plan the Odoo 19 to 20 upgrade now, and what sets the deadline
If your organization runs Odoo 19 today, the decision in front of you is when to move to Odoo 20.0, which was released in September 2026. Plan the move now, while 19.0 is still in standard support, and set the cutover date from the support calendar and your own change windows rather than from the release date alone. The standard support dates are the main constraint: Odoo plans standard support for 20.0 until September 2029, and for 19.0 until September 2028. Those dates are published in Odoo's standard and extended support documentation, so confirm them there before you put them in a project plan. The support dates matter because security patches are only provided during standard support. Odoo's standard and extended support documentation states that extended support is paid, limited to Odoo.sh for select versions and on-premise, and that security patches are not part of it. In practical terms, a 19.0 database that runs past September 2028 without a move to a newer version carries known exposure that your security team would need to accept in writing. Ask your Odoo partner or Odoo account contact which hosting types and versions would still be eligible for extended support when you reach that date, because the answer depends on your hosting type and edition. Hosting type changes the pressure. Odoo's upgrade documentation states that on Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. If you run Odoo Online or Odoo.sh, the move to a new major version is not optional on that schedule, so the question becomes how much time you have to prepare. On-premise deployments are not subject to that same mandatory cadence, but they still lose security patches when standard support ends. Confirm which rule applies to your deployment and write the resulting deadline into your project charter. The upgrade is a planning exercise, not a single button press. Odoo's upgrade service moves a database to a newer version through an upgraded test database, which Odoo recommends you test before you touch production. Your plan needs an inventory of installed custom modules, a decision on which ones must be ported, a test database refreshed from production with personal data neutralized, a list of integrations that call your Odoo instance, and a rehearsal of the full cutover. Each of these items has an owner and a duration you must estimate from your own environment, and none of them is covered by the upgrade service alone. Start with three actions this quarter: confirm your current version and hosting type, record the end-of-support date that applies to your deployment, and request a written scope and quote from your implementation partner based on your module list. The quote should separate the upgrade service fee, custom module porting, integration rework and testing, and state which items are one-time and which recur.
What changes in Odoo 20 and what each change asks of your team
This table lists the Odoo 20.0 changes that matter most for an upgrade and what each one asks of your team. Use it as a checklist: verify every row against the Odoo 20.0 release notes, then map each item to the modules, custom code, data and integrations you actually run. The main takeaway is that a change only affects you where your own customizations touch it, so the module mapping drives the work.
| Change | Impact | Action needed |
|---|---|---|
| Mail tracking rework | Changes how tracked changes are handled in the 20.0 release. Custom code that reads or writes tracking data needs review. | Confirm the scope in the 20.0 release notes, then test tracked fields and chatter messages in your custom modules on the upgraded test database. |
| Expense flow changes | Changes parts of the expense workflow. Customized approval, posting or reporting logic may need adjusting. | Map each expense step your company uses, check it against the release notes, and test one full claim from submission to accounting entry. |
| Other 20.0 items touching custom code | Items that change model fields, methods, views or data formats can break custom modules and integrations. | List every 20.0 release note item, then map each one to the custom modules, data imports and integrations you run. |
| Module porting | Custom modules written for 19.0 may need changes before they install and run on 20.0. | Inventory each custom module, assign who ports it, and run install and functional tests on the test database. |
| Upgrade service and test database | The upgrade service produces an upgraded test database that should be tested before production cutover. | Request the upgraded test database early and plan your test cycle around it. On-premise use requires an Enterprise subscription. |
| Test copy handling | Odoo documents neutralization for test copies, but its effect must be confirmed for your setup. | Check the Odoo documentation for what neutralization covers, and confirm outbound email, payment and integration connections are disabled in test. |
What to prepare before the upgraded test database is requested
Four items decide how quickly the upgraded test database can be requested and how useful it is once it arrives. Each one holds knowledge that the database alone does not contain, so prepare them in parallel with the upgrade plan and assign each to a named person on your side.
Verified backup of the database and filestore
Take a backup of the PostgreSQL database and the filestore together, because attachments, images and generated documents live in the filestore and a database-only copy will break references to them. Restore the backup to a separate server and confirm that users can sign in, that key records and attachments open, and that record counts match production. Confirm where the backup is kept, how long it is retained, and who can restore it without waiting for a single engineer.
Inventory of custom modules and third-party apps
List every custom module, every Odoo Community Association module and every purchased app, with its current version, source repository and a named owner who can answer questions and approve changes. Modules that override core methods, views or reports are the most common source of porting work, so flag them first. For each item, confirm with the vendor or maintainer whether a version for Odoo 20 exists and when it will be available, instead of assuming that a module working on Odoo 19 will load unchanged.
Integration list including external API use
Record every system that reads from or writes to Odoo, including identity providers, payment gateways, shipping carriers, banks, marketplaces and reporting tools. The Custom plan includes external API access, so note which endpoints, API keys and permission scopes each integration uses, who owns each credential, and how each system is tested. Ask the Odoo partner or vendor to confirm which API behaviour changes in Odoo 20 before the test environment is built.
Neutralized test environment from a production copy
Build the test environment from a copy of production using the database duplication and neutralization steps Odoo documents for on-premise installations. Neutralization disables outgoing email, scheduled actions and live integration endpoints, so the copy cannot send messages or call payment and shipping services by mistake. Keep the test environment on an Enterprise subscription, since the upgrade service requires one for on-premise use, and record the date of the copy, because the upgraded test database will be compared against it.
What makes the Odoo 19 to 20 upgrade take longer
This table lists six drivers that most often change how long an Odoo 19 to 20 upgrade takes, why each one matters and how to reduce it before the build starts. The size of the effort cannot be given without a written scope and a complete inventory of modules, apps, data, integrations, companies and approvers. Teams that measure these drivers early can ask for a quote based on their own environment.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Custom modules: number and depth | Each custom module must be ported and retested for Odoo 20, including the mail tracking rework and expense flow changes. Deep overrides of core models break more often. | Inventory every module, remove unused ones, and prefer standard features before porting. Record which core models each module overrides. |
| Apps in use | Every installed app adds models, views and automated actions that need checking after the upgrade, even when no custom code touches them. | List active apps by business process, disable those nobody uses, and define core test flows for each app that stays. |
| Data and attachments | Database and filestore volume affects the upgrade run, the size of the upgraded test database and the time needed to verify results. | Archive or purge obsolete records and attachments before the test copy. Measure database and filestore size and confirm both are copied together. |
| Integrations with external systems | Each integration that calls Odoo's APIs or receives its data needs its own test case, credentials check and named owner. | Document every endpoint, data flow, authentication method and owner. Confirm with the Odoo 20 release documentation which interfaces change. |
| Companies and fiscal localizations | Each company has its own chart of accounts, tax mappings and reports, and each must reconcile before and after the upgrade. | Compare trial balances and tax reports per company on the test database. Confirm the localization version each company uses before the rehearsal. |
| Sign-off on test results | Each approver needs a defined test set and acceptance criteria. Unclear ownership or late approvals extend the rehearsal and delay cutover. | Agree acceptance criteria and named approvers in writing before the rehearsal. Assign one owner for each process area, such as finance, sales or inventory. |
The upgrade sequence from inventory to cutover
The sequence moves the upgrade from verified backups and a frozen change window through module porting, an upgraded test database and a full cutover rehearsal before any production change. Each step closes with a named check, and the 19.0 source stays available as a rollback point until the go or no-go decision is signed off.
Take and verify backups
Back up the 19.0 PostgreSQL database and the filestore together, then restore both into a separate environment to confirm they load and that test users can sign in. The team running the upgrade owns this step, and the infrastructure owner provides storage and access. The step is done when a full restore has been tested end to end and the backup set is recorded with its date and checksum. That verified set is the first rollback point and stays in place until production is confirmed on 20.0.
Freeze changes on the source database
Agree a change freeze with the business owners and stop module installs, module updates, configuration edits and scheduled jobs that write data. Record the freeze in writing with its start point and the named contact who can approve an exception. Capture a snapshot of installed modules, company settings and key configuration so the state can be compared later. The step passes when the snapshot is stored and no unlogged change has been made since. The untouched 19.0 database is the rollback point for this step.
Inventory and port custom modules
List every custom module with its source repository, its declared dependencies, and each place it changes core views, models or reports. Check each Odoo dependency against the 20.0 release documentation and the Odoo Community Association ports where they exist for your edition. The development team owns this step and reviews it with the business process owners. The step passes when each module has a porting ticket with an assigned owner and a 20.0 branch that installs in a scratch database. Keep the 19.0 code in version control so the old branch remains the rollback point.
Build the upgraded test database and run test cases
Request the upgrade of a neutralized copy of production through the upgrade service, and confirm first that your edition and subscription allow it. On-premise use of the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. Duplicate the database with neutralization so outgoing email, payment and integration endpoints cannot reach live systems. Run the agreed test cases for sales, accounting, inventory and each custom module. Confirm exact commands against the 19.0 and 20.0 documentation. The step passes when every test case has a recorded result and the upgraded database loads without errors in the server log.
Fix defects and retest
Log each failed test case with reproduction steps and triage it as a porting fix, a data issue or a configuration change. Fix the code on the 20.0 branch, rebuild the test database from the untouched 19.0 copy, and rerun the affected cases along with a regression pass on core flows. Developers make the fixes, and the business owners accept the results. The step passes when no open defect blocks go-live and the business owners sign the test report. Because the test database is rebuilt from the same source copy, the upgrade can be repeated from an identical starting point.
Rehearse the full cutover on a copy
Run the complete production cutover on a fresh copy of production, from final backup through upgrade, filestore handling, module installation and post-upgrade checks. Write each action as a numbered runbook step with an owner and an expected result, and time the run against your maintenance window. Confirm exact commands against the 20.0 documentation before the rehearsal. The step passes when the rehearsal completes with no deviation from the runbook and the smoke test list is signed off. Production stays on 19.0 throughout, so the rollback point remains the untouched production database and its backup.
Cut over production with a go or no-go check
Hold a go or no-go review against the criteria agreed in the testing and rehearsal steps, covering backup verification, open defects, sign-offs and the named person who can call a rollback. On go, freeze production, take a final backup, run the rehearsed runbook and complete smoke tests with the business owners. The step passes when key flows are confirmed on 20.0 and the cutover record is signed. Keep the 19.0 database and backup intact under a retention period your operations team sets. On no-go, production remains on 19.0.
How the upgraded test database and rehearsal decide cutover
The upgraded test database is the only evidence you will have that production will behave correctly on Odoo 20 after cutover, so the cutover decision should follow from what that test shows, not from the upgrade calendar. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, and Odoo's documentation recommends testing that copy before production is switched. Build the test copy from a database duplicate with neutralization, so outbound email, payment connectors and scheduled actions cannot reach customers or banks during testing. Ask your partner to confirm exactly what neutralization disables in your setup, including any custom modules and external connectors.
A useful test covers more than the login page. Walk the core business processes end to end: quotation to sales order to invoice to payment, purchase order to receipt to vendor bill, manufacturing orders, point of sale sessions and the steps of your month-end close. Check each custom module's fields, views, server actions and automated actions against the list produced during porting. Exercise every integration the upgrade touches, such as bank feeds, payment providers, shipping carriers and identity providers. Print and export each report that finance, operations and customers rely on. For accounting and inventory, compare receivables, payables, bank balances, the trial balance and stock valuation between source and test at the same cutoff date. Finally, sign in as a non-administrator from each role through each sign-in method you use, including LDAP, Google, Microsoft or two-factor authentication where configured.
Run the full cutover sequence as a rehearsal on a copy that mirrors production as closely as possible, including the same data volume, module set and integrations. Time every step and record the measured duration of each one, then use those measurements to set the cutover window. Do not reuse durations from another project or from a vendor's example, because your filestore size, custom code and integration count drive the result. The rollback plan is part of the same rehearsal. Name the trigger that starts a rollback, the person who authorizes it, the backup that will be restored, and the last point at which a restore is still clean. Rehearse that restore once so the team knows the commands, access and sequence before they are needed under pressure.
Rollback becomes difficult once the upgraded database is live and users post transactions. Invoices, payments, stock moves and journal entries created on Odoo 20 will not exist in the pre-upgrade backup, so a restore means either re-keying those transactions or planning a separate reverse migration. Confirm with Odoo's documentation and your partner whether a downgrade path exists for your version pair, and plan as though none does. For that reason the decision point must be fixed before the rehearsal: write down the go and no-go criteria, the person who makes the call, the time after which a clean restore is no longer possible, and the write freeze that starts at cutover. When the rehearsal tests those written rules as well as the technical steps, the team can make the cutover decision on evidence instead of pressure.
Questions teams ask before the Odoo 19 to 20 upgrade
How much does an Odoo 19 to 20 upgrade cost?
The cost depends on your edition, the size of the database and custom code, and who performs each step. On-premise databases need an Enterprise subscription to use the upgrade service, so the subscription is one recurring cost. Hosting and any support retainer also recur. The upgrade project itself is one-time. The largest drivers are the number of custom modules and integrations to port and the number of apps in use. Ask for each line to be priced separately: subscription, upgrade service use, module porting, test database work, rehearsal, cutover and post-go-live support. Each line should map to a written scope.
How long does an Odoo 19 to 20 upgrade take?
Duration depends mainly on how much custom code needs porting and how many apps and integrations the database uses. Other drivers include the size of the database and filestore, the number of test cycles, how quickly business owners return their sign-off, and whether a rehearsal on a fresh copy is planned before cutover. Odoo's upgrade documentation says the upgraded test database should be tested before production, so that test window needs its own time in the plan. Ask for milestones in the written scope: the upgraded test database, the fix cycles, sign-off and the production cutover window.
What does an Odoo 19 to 20 upgrade need from our team?
The work depends on your people more than on the software. Plan for these inputs:
Test users: named people who run each key process, such as sales, invoicing, inventory and payroll, after each test cycle. Business owners: people who decide what correct behavior looks like and who approve each area. Access: administrator access to the servers, the database, the filestore and the Odoo instance, plus the subscription and account details. Sign-off: a named approver for the test result and another for the production cutover. Change window: agreed downtime and a communication plan for users.
If these roles are unclear at the start, testing usually slips.
Can our internal team upgrade Odoo 19 to 20 on its own?
Yes, for a simple setup, provided you hold an Enterprise subscription and use the upgrade service. A simple setup has few custom modules, few integrations and a standard hosting model. Your team will need Linux and server administration skills, PostgreSQL experience for backup and restore, Python skills and Odoo development knowledge for porting custom modules, and people who can run functional tests against business processes. Plan dedicated time for each role, and check whether the people who hold these skills can leave their current work for the test cycles. Larger or heavily customized databases usually benefit from an outside team for porting and rehearsal.
Can Odoo Community users follow the same upgrade route to 20?
No. The upgrade service is available to Enterprise subscribers, and Odoo's documentation says the Community edition has no access to it. Community databases move through OpenUpgrade, which migrates one major version at a time, so the route to 20 passes through the intermediate versions. Module coverage matters, because some custom and third-party modules may need community-maintained ports before they run. Confirm each step against the current OpenUpgrade documentation and the module status for your apps. The Odoo Community upgrades with OpenUpgrade topic covers that route in more detail.
What happens if we keep running Odoo 19.0 after its support ends?
Security patches stop when standard support ends. Odoo's documented schedule gives 19.0 standard support until September 2028, and security updates and bug fixes are only provided during that period. Paid extended support exists only for select versions on Odoo.sh and for on-premise installations, so confirm whether 19.0 would be covered for your hosting type before you rely on it. Odoo Online and Odoo.sh also require major upgrades every two years, so the upgrade may be forced regardless. A platform holding business data without patches creates a security and compliance gap, so schedule the upgrade well before September 2028.
How DeployOpen scopes, delivers and supports the upgrade
DeployOpen plans the Odoo 19 to 20 upgrade as a fixed-scope piece of work, starting from a written scope that names the modules, custom code and environments involved. The work runs against an upgraded test database, covers the mail tracking rework and expense flow changes, and ends with a rehearsal before production cutover. Support after handover can be provided as a retainer.
How we scope
- A written scope lists the databases, modules, custom code and hosting type covered by the upgrade.
- We inventory custom modules and flag each one that needs porting to Odoo 20 before the build starts.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work begins.
How we build
- Build starts from an upgraded test database, created from a neutralized copy of production.
- Custom modules are ported and reviewed against the Odoo 20 changes, including the mail tracking rework and expense flow changes.
- Functional tests cover accounting, sales, inventory and other apps in use, run against the upgraded database.
How we hand over
- A rehearsal on a copy of production runs the full cutover steps and records timings and issues.
- Documentation records the porting decisions, test results, rollback steps and the production cutover runbook.
- Your team receives the ported code in your repositories and a walkthrough of what changed.
How we support
- Post-cutover checks confirm logins, mail, expenses and integrations behave as the rehearsal showed.
- Standard support for Odoo 20 is planned until September 2029, which sets the window for later upgrades.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
