How to plan an Odoo Community upgrade with OpenUpgrade
If your Community database runs an older major version and is approaching the end of standard support, each upgrade moves one major version at a time, and the plan depends on module coverage and testing. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes. Once a version leaves standard support, security patches stop, so that deadline should set the start of your planning. Begin with an inventory of the database: the installed apps, every custom module, any third-party modules from the Odoo Community Association, and the integrations that read from or write to the database. Each item determines whether the upgrade is a configuration exercise or a development project.
Odoo's upgrade service is not available to Community users. Odoo documents that on-premise use of the upgrade service requires an Enterprise subscription, and the Community edition has no access to it. That leaves OpenUpgrade, a community project that provides migration scripts for moving data between major versions. Because it is maintained by the community, your team or partner owns verification at every step. Treat each migrated database as unverified until it passes your own checks: module installation logs, record counts in key models, financial and operational reports reconciled against the source system, and acceptance tests for the workflows the business depends on.
The supported path moves the database through each major release in sequence, and each hop needs its own test run. Do not skip a version in the middle of the chain unless the release notes state that the pair is supported. Confirm the exact version pairs against the current OpenUpgrade release notes and the Odoo documentation for every version involved before you commit to a sequence, because the number of hops depends on where you start and where you end. Version-specific changes are covered on separate pages in this series. Do not start the next hop until the previous one has passed acceptance testing, since an error introduced in one step carries into every step after it.
Decide early whether each custom module is kept, ported or replaced. For each third-party module, check whether a version exists for the target release and whether its maintainer has announced one. Modules without a target version are the usual reason a schedule slips, so request this list in writing before any effort is estimated. Odoo documents database duplication with neutralization for test copies, which is the right basis for rehearsals, but confirm exactly what neutralization disables in your version, such as outgoing mail, payment connections and scheduled actions. Record how long each rehearsal takes, so the production cutover window rests on measured data.
Cost follows the work in each hop. One-time items include the inventory, module ports, test environments and the verification effort for each step. Recurring items include keeping custom modules compatible with each new release and any support arrangement after cutover. Ask for a quote that lists each hop separately, shows module ports as individual line items and states who keeps the test evidence at the end. Also compare the Community path with an Enterprise subscription, which includes access to Odoo's upgrade service. That comparison involves licensing, hosting and support as well as effort, so put both options in writing before the plan is fixed.
What changes across Odoo versions and what each change asks of you
This table lists the support windows, release rules and version-specific checks that set the deadlines for an Odoo Community upgrade. Read the support windows first, because security patches stop when standard support ends, then check the upgrade rules for your hosting type. The main takeaway is that every version you pass through brings its own changes, so the release notes for each one shape the work.
| Change | Impact on a Community database | Action needed |
|---|---|---|
| Odoo 17.0 support window | Standard support ended in September 2026, so security patches are no longer provided under standard support | Confirm your exposure with your security team and set a target version and date for the move |
| Odoo 18.0 support window | Standard support runs until September 2027, after which security patches stop | Set the move to 19.0 or 20.0 and rehearse it on a test copy before that date |
| Odoo 19.0 support window | Standard support runs until September 2028 | Plan the next move using the 19.0 to 20.0 sibling page before the window closes |
| Odoo 20.0 support window | Released September 2026, with standard support planned until September 2029 | Treat the end date as Odoo's current plan and confirm it in the support documentation before you commit budget |
| Major upgrade requirement | On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years | If you run Online or Odoo.sh, schedule upgrades on that cycle. Confirm with Odoo whether the rule applies to on-premise installs. |
| SaaS release cadence | Odoo SaaS versions ship every two to three months and cannot use extended support | Use this cadence as a reference when you decide how often to review release notes |
| Version-specific breaking changes | Each major version can change behavior that custom modules depend on. The changes are not listed on this page. | Read the notes for each version you pass through, plus the sibling upgrade page for each step |
| Extended support | Paid extended support covers Odoo.sh for select versions and on-premise only, and security patches end with standard support | Ask Odoo whether extended support exists for your version and hosting type before you plan around it |
How OpenUpgrade handles each Odoo Community upgrade step
OpenUpgrade moves a Community database one major version at a time, so an upgrade that spans several releases is a chain of separate migrations. Each link in that chain has its own input, its own output and its own test cycle, and a failure in an early link carries into every link after it. Plan the chain as a list of version pairs before anyone runs a script, and treat each pair as a checkpoint that needs a restored copy, a migration run, a functional test and a sign-off before the next pair starts. Teams that try to jump several versions in one pass tend to find that errors are hard to attribute, because the database has already changed in several ways by the time a problem appears.
Before the first migration, run a module coverage check for every version pair in the chain. For each installed module, confirm whether OpenUpgrade provides a migration script for that pair, whether the module is maintained by the Odoo Community Association (OCA) and therefore has a community port, whether it must be ported by hand, or whether it is no longer needed and can be dropped. Export the full list of installed modules, including custom code and third-party add-ons, and record the result as a table with one row per module and one column per version pair. This table becomes the scope document for the upgrade. Confirm the current OpenUpgrade coverage in its project repository, because the set of covered modules and version pairs changes over time and any list copied into a proposal will go stale.
Treat OCA module ports as a separate workstream with its own owner and its own review. A port that exists for the target version still has to be installed, configured and tested against your data, and an OCA module that is ported late in the release cycle may differ from the version your team tested last year. Name one person who decides which OCA version each module moves to, who checks licenses and maintainers, and who signs off that the port behaves the same for your business processes. Keep the port decisions in version control next to the custom module work so that a reviewer can see what changed and why.
Modules that must be ported by hand need the most planning. Estimate them from their code, their dependencies on changed core APIs and the number of screens, reports and automated actions that rely on them, not from their size on disk. Ask any partner quoting the work to show how each hand-ported module was scoped, and ask which of your custom modules rely on features whose behavior changed between the versions in your chain. Dropped modules need a written decision with the business owner, because removing a module can remove a menu, a report or a data field that someone depends on.
Verify each migration step against the coverage table, not against memory. After each version pair, compare the modules that loaded, the modules that were skipped or disabled, and the errors in the upgrade log with the plan. Any module that is missing from the output, or that appears with a changed state, should be resolved before the next pair runs. Keep the coverage table, the log and the test results for every pair as evidence of how the upgrade was run, since auditors and internal reviewers often ask how a migrated system was validated.
What to back up and inventory before the Odoo Community upgrade starts
These four items set the scope and the baseline for the upgrade. Each one feeds the next: the verified backup protects the data, the module inventory defines what needs porting, the custom code list shows what the upgrade must rework, and the neutralized test copy is where every step gets rehearsed.
Full backup verified by restore
Take a full database dump and a copy of the filestore from the same point in time, and record the Odoo and PostgreSQL versions alongside them. A backup only counts once a restore onto a separate server has succeeded and attachments open correctly. The infrastructure or DevOps lead owns the backup job, and the functional owner signs off on the restore check. Confirm that the restore test runs on the same PostgreSQL major version the upgrade will start from.
Module inventory with sources and licenses
List every installed module with its technical name, its source (Odoo core, OCA, a vendor or in-house code) and its license. Odoo Community is licensed under LGPL-3.0, but third-party modules may carry other terms, so record each one separately. Mark which modules have an upgrade path already published and which your developers must port. Any Enterprise-only module found in the database must be settled as an edition question before the plan is fixed. The technical lead owns this list and updates it as modules change.
Custom code, configuration and integrations
Inventory custom addons, server configuration, scheduled actions, report templates and access rules. Include every external integration, such as payment, shipping, bank and identity connections, along with any system that calls Odoo through its external API. For each one, note the endpoint, the account it authenticates with and the owner of that credential. Confirm which API version each integration uses before the upgrade plan is fixed. Developers own the code inventory, and each integration owner owns their connection.
Neutralized test environment from production
Duplicate the production database and filestore into a separate environment using Odoo's database duplication with neutralization, which Odoo documents for test copies. Confirm which settings neutralization disables in your version, and check that outgoing mail, payment providers and scheduled actions cannot reach customers or banks. The test copy must match production's module list and version, because the upgraded copy is first run here. The platform owner builds it, and the functional lead verifies the neutralized settings.
The Odoo Community upgrade sequence with checks and rollback points
This sequence moves an Odoo Community database one major version at a time with OpenUpgrade, and each step closes with a check and a rollback point so the team can stop, correct or return to the verified backup before production is touched.
Freeze scope and confirm the target version
The team agrees the target Odoo version, the installed apps, the custom and OCA modules in use, and the business flows that must work after the move, and records them in writing. Because OpenUpgrade migrates one major version at a time, the chain of intermediate versions is fixed here as well. Confirm the target against the Odoo standard support dates in the lifecycle documentation before committing. The check is a signed scope note that names the source and target versions and the freeze date for code and configuration changes. Rollback point: nothing has changed in production, so the only action is to reopen the scope note if the target version is no longer supported.
Run the module coverage check
Compare every installed module against the modules available for the target version, covering Odoo core, OCA repositories and any custom code. Each module is classed as available, ported by OpenUpgrade migration scripts, needing a port, or to be retired. The output is a coverage register with one owner per gap. The check is complete when no module on the register is unclassified. Rollback point: the register is a planning document only, so the decision to proceed or stop the project can be taken here without any technical reversal.
Port custom and OCA modules in a branch
Developers create a version branch of the custom and OCA module repositories and port code to the target API, views, and data model. Each change is tracked in version control with a reviewed merge request, and module manifests are updated for the target version. The check is that every module in the register installs cleanly on an empty database of the target version and passes its own unit tests. Rollback point: the work lives in a branch, so production code and the running system are unaffected, and the branch can be discarded or reset.
Restore a neutralized copy and run the migration chain
Take a fresh backup of the production database and filestore, restore it to an isolated server, and neutralize the copy so outgoing email, payment and external connectors cannot reach live services. Run the OpenUpgrade migration chain from the source version through each intermediate major version to the target, recording the output of every stage. The check is that each stage completes with a clean exit and the database schema loads. Rollback point: the original database and filestore stay untouched, and the isolated copy can be deleted and rebuilt from the same backup.
Review logs and errors per step
After each migration stage, the upgrade engineer reviews the server log for errors, skipped scripts, missing field warnings and data that was dropped or converted. Findings are sorted into blocking, needs decision and accepted, with a named owner for each. The check is that no blocking item remains open before the next stage begins, and the log excerpts are kept with the project record. Rollback point: the team can stop at any stage and return to the verified backup, and the decision point for stopping should have been agreed in writing before the run started.
Run functional tests of key business flows
Business users and the delivery team run scripted tests of the flows named in the scope note, such as quotations to invoices, stock moves, payroll runs, point of sale sessions and month-end reports. Results are compared with figures from the source system for the same period and the same records. The check is a signed test log in which each flow passes, or each failure has a fix ticket and a retest. Rollback point: failures are fixed in the branch and the migration is rerun from the backup, so no production data is changed during testing.
Rehearse the cutover on a second copy
The full sequence is run again on a second neutralized copy, using the same branch, the same migration chain and the same test scripts, with the cutover steps timed and written down in order. Any manual step that was needed during the first run is either automated or added to the runbook. The check is that the rehearsal passes end to end with the same results as the first run and that the runbook has a named operator for each action. Rollback point: the rehearsal copy is disposable, and if it fails, the team returns to the branch fixes before any production action is scheduled.
Cut over production and hold the backup for sign-off
Production is placed in maintenance mode, a fresh verified backup of the database and filestore is taken and checked by restoring it, and the migration chain is run against production using the rehearsed runbook. The new version is accepted only after the business owner signs off the functional test log and the post-cutover checks. The original database and filestore are kept untouched until that sign-off. The rollback is restoring the verified backup, and the reader must set the decision point in advance, naming who can call it and by what time. Rollback point: the verified backup, restored to the original host or a replacement, returns the system to the pre-upgrade state.
How to test the upgraded database and roll back if it fails
Testing an OpenUpgrade migration serves two goals, and each needs its own run. A test run proves that the migrated data and code behave correctly. A rehearsal proves that the full cutover, from freezing the old Odoo database to opening the new one, fits inside the window the business has agreed to. Run the test first on a neutralized copy of production, then rehearse the complete sequence at least once on a copy as close to production as you can make it. Time every step and record it, because the cutover window is only as reliable as the slowest step you have measured.
Test scope should follow how the business uses the system. For accounting and stock, compare balances before and after the migration by account, journal, warehouse and valuation: totals, open invoices, unreconciled items, stock on hand and valuation figures. For access, sign in as one user from each role, test LDAP or Azure OAuth sign-in if your deployment uses them, and confirm that two-factor settings survived. Check integration endpoints, scheduled actions, reports and printed documents such as invoices and delivery slips. Run performance tests on volumes close to production, including your heaviest month-end batch. Confirm which OCA modules are in use, since each one needs its own check against the new version.
Treat rollback as a decision with a written cutoff time, agreed before cutover. Before that time, the old database remains the system of record and returning to it costs little. After it, users have written data into the new database, and returning to the old one discards that data unless someone replays it. Make the loss concrete: sales orders, payments, stock moves, journal entries, attachments and outgoing integration messages created after cutover. Decide in advance who can call the rollback, what evidence they need to make the call, and who in finance must approve the balance comparison before the cutoff passes.
Communicate the rollback plan before cutover, in plain terms. Tell users, finance, warehouse staff and integration owners when the freeze starts, what stops working during it, and what they would need to re-enter if the system returns to the old database. Keep the old database and filestore intact until the cutoff has passed and the business has signed the test results. Confirm with your business owners which checks they must sign. At minimum this should include the accounting and stock balance comparison, the access sign-in tests and the printed documents they rely on. Write those sign-offs into the cutover runbook so that nothing is accepted by default.
What makes an Odoo Community upgrade take longer or cost more
This table lists the drivers that raise or lower the effort of an Odoo Community upgrade with OpenUpgrade, why each one matters, and what to count before you ask for a quote. Each size varies by database, so count every driver in your own instance rather than relying on general impressions. No effort figures are supplied for this page, so ask for a scope-based estimate that lists the count for each driver.
| Driver | Why it raises effort | What to measure before quoting |
|---|---|---|
| Custom modules: number and age | Each custom module must be ported to the target version's model, view and API changes, and older modules usually need more changes. | Count of custom modules, date of last change, and which ones depend on core models that changed in the target version. |
| OCA or third-party modules without a migration path | A dependency with no branch for the target version must be replaced, rewritten or dropped, and that work often sits on the critical path. | Each module, whether a target-version branch exists, the last maintainer activity, and the custom modules that depend on it. |
| Versions to cross | OpenUpgrade migrates one major version at a time, so each hop adds a migration run, a test cycle and a fix round. | Current version, target version, and the number of intermediate hops the scope requires. |
| Database and filestore size | Larger databases lengthen migration runs, add data to verify, and make test copies slower to restore and neutralize. | Database size, filestore size, and the duration of a migration run on a test copy. |
| Integrations and API versions | Connectors built on an older external API may need rewriting, and each connected system needs its own test cycle. | Each integration, its direction, its API version, its owner, and whether it runs on a schedule or in real time. |
| Customized reports and workflows | Changed report templates, server actions, automated actions and approval flows need functional checks and business sign-off. | Count of custom reports, automated actions, server actions and approval flows, with a named tester for each area. |
| Environments kept in step | Development, test, staging and production each need the same code and a migrated copy, and drift between them forces repeated runs. | Number of environments, code branches in use, and how often production data is copied into non-production environments. |
When switching to Enterprise is the cheaper Odoo upgrade path
Switching to Enterprise is the cheaper path when an Enterprise subscription plus Odoo's upgrade service costs less over the next support window than OpenUpgrade work on Community. The decision starts with licensing. Odoo's upgrade service requires an Enterprise subscription for on-premise use, and the Community edition has no access to it. The comparison is therefore not the upgrade alone. It is two different bundles: a Community path in which your team or a partner carries all of the migration work, and an Enterprise path in which the subscription, the upgrade service and on-premise use are paid to Odoo.
On the Enterprise side, the recurring cost is the subscription. Odoo's pricing page lists per-user monthly prices and a yearly discount for its plans. Those figures change, so take them from the page on the day you build the budget and record the plan, user count and billing period used. Only the Custom plan can be hosted on-premise, and only Custom includes custom modules and external API access. If you run custom modules or integrations against the API, Custom is the only plan that fits your architecture, so the plan is set by your requirements, not by the price per user. The one-time item is the upgrade service fee. Confirm it in writing before you compare options, because it is the line most often missing from early estimates.
On the Community side, there is no subscription fee, but the one-time cost is the migration work itself: OpenUpgrade runs, porting of custom modules, checks for OCA modules that cover your apps, test runs against a neutralized database copy, and a rehearsal of the production cutover. That work recurs at each major version. Odoo's standard support covers three years after a major release, including security updates, and security patches are only provided during standard support. Paid extended support is limited to Odoo.sh for select versions and to on-premise, so confirm which versions and fees apply to your target release before you commit to a Community path.
Test the decision by comparing total cost over the next support window, from the upgrade date to the end of standard support for the target version. Include subscription fees, the upgrade service fee, migration labor, hosting, testing, extended support if you expect to need it, and the next upgrade you will face. Ask Odoo for the upgrade service fee in writing, with the plan, user count and version it covers. Ask any partner for a fixed-scope quote that lists the modules, integrations and test cycles included, so both options are priced on the same basis.
Odoo Community upgrade questions buyers ask before hiring help
How much does an Odoo Community upgrade cost?
The cost is set by the written scope, and DeployOpen does not publish a price list, so a quote follows from the scope agreed in writing. You pay for planning, the upgraded test database runs, custom module porting, OCA module checks, test cycles, cutover and documentation. The upgrade itself is one-time work, while a support retainer after go-live recurs. The main drivers are the number of major versions to cross, how many apps, custom modules and OCA modules you run, the size of the database and filestore, the number of integrations, and how many test rounds your business owners need. Ask for a quote that itemizes each phase so you can see which part changes if your module list changes.
How long does an Odoo Community upgrade take?
No single duration applies to every upgrade, so the schedule should come from the written scope rather than a general estimate. Duration depends on how many major versions you cross, since OpenUpgrade moves a database one major version at a time, and on how many custom or OCA modules need porting. Test sign-off speed, the number of integrations to re-verify and the availability of staging copies also shape the timeline. Your support deadline matters too: Odoo 17.0 standard support ended in September 2026, Odoo 18.0 standard support runs until September 2027 and Odoo 19.0 until September 2028. Ask the provider for milestones, the test rounds included and the dates each milestone depends on from your side.
What does our team need to provide for an Odoo upgrade?
The upgrade depends on decisions and access from your side as much as on technical work. Name a business owner for each process area who can sign off test results, since functional testing cannot be finished by the implementation team alone. Provide access to staging environments, a recent backup window, the filestore, and credentials for integrated systems such as payment providers, banks or identity providers. Decide early what happens to each custom module: port it, replace it with a standard feature or an OCA module, or retire it. Confirm who approves the cutover date and who handles user communication. Missing decisions on custom modules are the most common reason test cycles repeat, so settle them before the build starts.
Can our internal team upgrade Odoo Community with OpenUpgrade?
An internal team can upgrade Community with OpenUpgrade if it has Python, PostgreSQL and Odoo development skills and enough time for repeated test cycles. OpenUpgrade migrates a database one major version at a time, so a multi-version jump is staged as a sequence of upgrades, each followed by testing. Your team must also check module coverage, port custom modules, and verify integrations and reports. The harder parts are rarely the scripts. They are test design, data exceptions and keeping the process moving while staff are busy with daily work. Confirm the current OpenUpgrade process, supported paths and tooling with the OpenUpgrade project and your own environment before you commit a date.
Why can't Odoo Community use the Odoo upgrade service?
Odoo's upgrade service is available with an Enterprise subscription for on-premise use, and the Community edition has no access to it. Odoo's own service moves a database to a newer supported version and creates an upgraded test database that should be tested before production. Because Community has no access to that service, a Community upgrade relies on OpenUpgrade, the open source migration tooling, plus project work to check modules and data. This is the main reason the work is planned and tested in-house or with a partner rather than handled by a vendor-run process. Confirm this access rule against Odoo's current upgrade documentation for your version before you plan the project.
What happens if a custom module has no migration path?
If a custom or OCA module has no migration path to the target version, you have three realistic options: port the module by hand, replace it with a standard feature or a maintained OCA module, or retire the functionality. Porting needs a developer who understands the old and new APIs, and the effort depends on how much the module touches core models, views and reports. Replacement may change how users work, so it needs business sign-off. Retirement needs a documented decision and a data plan for records the module created. Decide each case before testing starts, and run the ported module against a neutralized copy of production data. The cost of this decision is usually the largest variable in the quote.
When is Odoo Enterprise cheaper than upgrading Community?
Enterprise is worth comparing when the Community upgrade would require heavy custom work, or when you need features only the higher plan includes. Odoo's pricing page lists per-user monthly prices with a yearly discount, and only the Custom plan can be hosted on Odoo.sh or on-premise and includes multi-company, Odoo Studio, external API access and custom modules. On-premise use of the upgrade service also requires an Enterprise subscription. Compare the total annual subscription, including user counts and any plan changes, with the one-time upgrade quote plus the recurring cost of maintaining ported modules. The Enterprise source code is not publicly available, so factor in that you depend on Odoo's subscription terms. Request both quotes against the same user count and scope.
How long is each Odoo version supported before an upgrade is forced?
Odoo's standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. Odoo 20.0 was released in September 2026 with standard support planned until September 2029, Odoo 19.0 was released in September 2025 with support until September 2028, and Odoo 18.0 was released in October 2024 with support until September 2027. Odoo 17.0 standard support ended in September 2026. Security patches come only during standard support, and SaaS versions cannot use extended support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years. Check which deadline applies to your hosting type and plan the upgrade before support ends.
How DeployOpen scopes and delivers an Odoo Community upgrade
DeployOpen treats an Odoo Community upgrade with OpenUpgrade as a planned sequence of single major-version steps, each tested on a copy of your database before anything reaches production. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts. Ongoing support is available as a retainer.
How we scope
- Confirm the current Odoo version, edition and hosting type, and the target version each step must reach.
- Inventory installed custom and OCA modules and check each one for coverage by OpenUpgrade scripts.
- Record the written scope: which modules are ported, which integrations are retested, and which data is verified.
How we build
- Run OpenUpgrade one major version at a time on a neutralized copy of production, never skipping steps without review.
- Port custom modules to the target API and fix deprecated calls, then run the module test suites against each step.
- Compare business reports, accounting totals and key workflows between the source and upgraded test databases.
How we hand over
- Deliver the upgrade runbook, the module porting changes and the test results for each version step.
- Document the cutover sequence, rollback point, filestore handling and post-upgrade checks your team will run.
- Walk your administrators through the upgraded environment and the open items that remain after cutover.
How we support
- Offer post-cutover support for issues found in production during the agreed window, as set out in the written scope.
- Plan the next major version step with you, since Odoo Online and Odoo.sh require upgrades every two years.
- Provide ongoing support, upgrades and testing as a retainer if your team wants continued cover after handover.
