Odoo's upgrade documentation says that with Odoo Enterprise, "upgrading a database to the most recent version of Odoo is free", including support for discrepancies in the upgraded database. That service is part of the Enterprise subscription. A company on Odoo Community migrates its data another way: with the migration scripts of OpenUpgrade, an open-source project of the Odoo Community Association (OCA).
Odoo 18.0 has standard support until September 2027 in Odoo's support table, so there is time. But 19.0 is where many companies are headed, and the practical question is simple: can a Community database make the jump today?
Yes, for the main apps, with care. OpenUpgrade's 19.0 branch has scripts for accounting, sales, purchase, inventory, manufacturing, CRM, point of sale, website and more. Other modules, including the US localization, were not covered yet when we checked. Compare your own module list with the coverage file, then rehearse on a copy until the run is clean.
What OpenUpgrade is
OpenUpgrade is a set of migration scripts for Odoo S.A.'s own modules, maintained in public on GitHub by the OCA. Its documentation states the goal plainly: "For all official addons, migration scripts should be provided for migrating between subsequent major releases of Odoo." Each branch migrates from the version before it, so the 19.0 branch takes a database from 18.0 to 19.0. The documentation adds that "Skipping versions is not supported": a database on 16.0 goes through 17.0 and 18.0 on the way.
Since 14.0 it ships as two Odoo modules. openupgrade_framework is loaded as a server-wide module during the run, and openupgrade_scripts holds the scripts; it only needs to be on the addons path. They rely on the openupgradelib Python library, which the documentation asks you to install from its GitHub source to get the latest fixes.
Where 18.0 to 19.0 coverage stands
Each branch has a coverage file listing every Odoo module with a status. The legend defines three: "Done" means scripts are ready to run, "Nothing to do" means the analysis found no change that needs a script, and an empty status means "Not covered yet". On September 28, 2026, the file on the 19.0 branch, last changed on September 21, read like this for modules that exist in both versions:
| Status | Modules | Examples |
|---|---|---|
| Done | 93 | account, sale, purchase, stock, mrp, crm, point_of_sale, website_sale, project, hr, hr_expense, maintenance, mrp_subcontracting |
| Nothing to do | 168 | web, analytic, contacts, stock_landed_costs, stock_delivery, sale_mrp, purchase_mrp |
| No status (not covered yet) | 300 | l10n_us, l10n_us_account, account_check_printing, account_debit_note, repair, and many other localizations |
Of the 300 without a status, 180 carry the note "No DB layout changes", which is a good sign but not the same as a reviewed script. The other 120 have no note at all. The documentation's own advice is direct: if modules installed on your database have no scripts yet, "your migration may fail or the integrity of your database may be lacking." It also warns that when migrating to a recent version, "you'll certainly have to reference numerous open pull requests" for the modules on your instance.
For a company in the United States, the rows to look at first are the US localization and check printing. They were not covered yet on the day we looked, and we found no open pull request for them. A rehearsal will show whether they need work on your database.
Check your own module list
Start with the list of installed modules. If you can reach the database, this read-only query gives it:
Read-only Odoo 18
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;
SELECT name, author, latest_version
FROM ir_module_module
WHERE state = 'installed'
ORDER BY name;
Sort the result into three groups. Odoo's own modules are checked against the coverage file. Modules from the OCA need their 19.0 versions, which you can check on each repository's 19.0 branch; our Odoo 19 Enterprise vs Community table lists the common ones. Everything else is custom code that has to be ported to 19.0 before the run, and our article on upgrading custom modules lists the changes that break it, such as the reorganized groups in 19.0 and _sql_constraints, which 19.0 no longer creates. Our free scan does the same sorting for you and changes nothing.
A rehearsal, step by step
OpenUpgrade's documentation is honest about what a run looks like: "Expect to repeat the process several times as you encounter errors, clean up your data, and try again." So plan for rehearsals from the start, on a separate server, never on production.
- Restore a neutralized copy. Restore a recent production backup on the separate server and neutralize it with Odoo 18's
odoo-bin neutralize, so it cannot send mail, run scheduled actions or reach payment providers. Check custom integrations yourself: neutralization covers Odoo's standard features, not a module that calls an outside service directly. - Record the numbers that must not change. Trial balance by account, open receivables and payables, stock quantity and value by category, open orders, and record counts for key models.
- Prepare the 19.0 environment. Odoo 19.0 source, the OpenUpgrade 19.0 branch on the addons path,
openupgradelibinstalled from GitHub, the 19.0 versions of your OCA modules, and your ported custom modules. - Run the migration and keep the log. The documentation recommends
--update all --stop-after-init --load=base,web,openupgrade_framework. - Read the log, fix, and run again from a fresh copy of the 18.0 backup. Search for errors first, then for warnings. Time each run: that is your downtime estimate.
- Compare the numbers from step 2 after the run. A difference is either explained or a bug.
- Let the people who use Odoo test their weekly routine on the copy: a quote, a delivery, a vendor bill, a bank statement, the reports the accountant relies on.
- Schedule production only when a rehearsal produces no surprises, and follow the same written steps.
Rehearsal copy only Odoo 19, example paths
pip install git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib
odoo-bin -d upgrade_rehearsal \
--addons-path=/opt/odoo19/odoo/addons,/opt/odoo19/addons,/opt/OpenUpgrade,/opt/oca19,/opt/custom19 \
--update all --stop-after-init \
--load=base,web,openupgrade_framework \
--logfile=/var/log/odoo/upgrade_rehearsal.log
The paths are examples: the OpenUpgrade folder is the root of the cloned repository, which holds both modules. When openupgrade_framework is loaded and openupgrade_scripts is on the addons path, the framework's documentation says Odoo's --upgrade-path option is set to the scripts automatically.
OpenUpgrade deliberately keeps old tables and columns, renamed with an openupgrade_legacy_ prefix, in case a later script or a fix needs them. Once the upgraded database has run calmly for a while, the OCA's database_cleanup module (server-tools, present on 19.0) can remove them. Take a backup first.
Where Odoo 20 fits
Odoo opened its 20.0 branch in September 2026. The OpenUpgrade repository and the main OCA module repositories opened their 20.0 branches on September 28, 2026, and held no modules or scripts yet that day. For a Community system, 19.0 is the newest version with working migration scripts and broad OCA coverage, and moving from 19 to 20 later is one step. Clearing the deprecation warnings from your 19.0 logs makes that step smaller.
Do it yourself, or hand it over
Everything above is public, and a technical team can run it. The work that takes the time is the rehearsals: reading logs, fixing data, porting modules and checking numbers until a run is uneventful. If you would rather have us do it, our Odoo 19 upgrade page explains how we run it on copies of your database and how it is priced, and our Enterprise to Community page covers the case where you are leaving Enterprise at the same time.
Questions people ask
Can Odoo Community be upgraded from 18 to 19 without Enterprise?
Yes. The OCA's OpenUpgrade project has a 19.0 branch with migration scripts for Odoo's own modules from 18.0 to 19.0. Coverage is good for the main apps and incomplete elsewhere, so check your installed modules against its coverage file and rehearse on a copy.
Is OpenUpgrade 19.0 finished?
No. On September 28, 2026 its coverage file listed 93 modules as done and 168 as nothing to do, while 300 modules present in both versions had no status, which the project's legend defines as not covered yet. The scripts module is marked Beta.
Is the US localization covered?
Not yet. On September 28, 2026, l10n_us, l10n_us_account and account_check_printing had no status in the 18.0 to 19.0 coverage file. That does not mean they will fail; it means nobody has confirmed them, so a rehearsal on a copy has to.
Can we skip from Odoo 16 straight to 19 with OpenUpgrade?
Not in one run. OpenUpgrade's documentation says each branch migrates from the previous version and that skipping versions is not supported, so the data goes 16 to 17, 17 to 18 and 18 to 19 in turn. Custom modules can still be ported straight to 19.
What about our OCA and custom modules?
OpenUpgrade covers Odoo's own modules. OCA modules you use need their 19.0 versions available for the run, and custom modules must be ported to 19.0 first. Our article on upgrading custom modules lists the changes that break them.
Is there an OpenUpgrade for Odoo 20?
The OpenUpgrade repository opened a 20.0 branch on September 28, 2026, and on September 30 it still held no migration scripts. For a Community system, 19 is the version with working migration scripts today.
Sources
- OCA OpenUpgrade, 19.0 branch
- OpenUpgrade coverage file, 18.0 to 19.0 (read September 28, 2026)
- OpenUpgrade coverage legend
- OpenUpgrade documentation: coverage analysis
- OpenUpgrade documentation: running the migration
- OpenUpgrade documentation: after migration
- OpenUpgrade documentation: required knowledge
- openupgrade_framework, 19.0 and openupgrade_scripts, 19.0
- OCA server-tools: database_cleanup, 19.0
- Odoo documentation: Upgrade
- Odoo documentation: Standard and extended support
- Odoo documentation: Neutralized databases