+ ODOO COMMUNITY UPGRADE
++ Moving up a major Odoo version is not an update — it is a one-way transformation of your database, + and it is the one job where a mistake costs you your history. Here is what actually happens, the + commands a developer will run, and how we do it for you on our own servers. +
+ +The difference that matters
++ Odoo uses two words that sound the same and are not. An update gets you the newest + revision of the software you already run. An upgrade moves your database to a new + major release — 18 to 19, or 19 to 20 — and it transforms the data itself. It is one-way: there is no + supported way back down, and it is not a licence change, not a move to a different edition and not a + switch of hosting provider. +
+Three things about it are worth knowing before anyone touches your system.
++ It happens one major version at a time. A jump from 17 to 20 is three migrations, not + one: 17 → 18, 18 → 19, 19 → 20. Skipping a version is not a supported path anywhere in the Odoo + ecosystem. +
++ It is done on a copy, never on the live database. Everyone who has written about + this — Odoo's own documentation, the OCA's OpenUpgrade project, and every practitioner we have + watched — starts by taking a backup and working on a duplicate. You find out what broke on the copy, + not in front of your customers. +
++ Your own customisations are the part that needs work. A module built for your + business does not move by itself: its code has to be brought up to the target version, and the renames + that would otherwise lose data need migration scripts written for it. Odoo's documentation says it + plainly — an upgrade is blocked until a version of your custom modules exists for the release you are + moving to. +
++ Then the route itself. Odoo sells an upgrade path for Enterprise, and for Odoo Community the + open-source answer is the OCA's OpenUpgrade project. The OpenUpgrade documentation states that Odoo + Community Edition does not support migrations between major releases, and records that OpenUpgrade is + the solution Odoo's own founder recommends for it. It is a real project, maintained by the community + association, and it is the route a developer will use on a Community database. +
+The published path
++ This is the sequence that Odoo's documentation, the OpenUpgrade project and the recorded workshops + all agree on. Nothing here is ours and nothing here is secret — it is the published path, in the + order it is done. +
++ That is the honest shape of it: preparation is the long part, the migration itself is the short part, + and the copy is what you are allowed to break. +
+For your developer
++ If you are running Odoo Community yourself and you want to do this in-house, these are the commands. + They are quoted from the documentation they come from, and each one is labelled with what you must + substitute and what that source warns about. Nothing below has been run by us against your database, + and no command published by us runs on our own servers — our service starts with a support ticket, + not a terminal. +
++ Odoo documents an upgrade platform that works for on-premise installations from the command line. + Odoo's documentation states the migration scripts it runs are not open source and come with + Enterprise — but the platform itself will upgrade a self-hosted database. +
+# upgraded TEST database
+python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
+
+# production upgrade
+python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>
+
+# general help
+python <(curl -s https://upgrade.odoo.com/upgrade) --help
+ Substitute: <your db name> is the database on the machine you
+ run the command from, and <target version> is the release you are moving to —
+ 17.0, 18.0 or 19.0, matching the pricing selector on our own plans page.
+
+ What Odoo's documentation requires next to those three lines, because it changes whether they
+ work: the script needs the usual Linux commands present on the machine; the system user running it
+ needs access to your PostgreSQL database (the standard PostgreSQL client environment, such as
+ .pgpass); and the machine must reach the upgrade platform on TCP 443 and on a port in
+ the range 32768-60999, so a firewall may need an exception. The copy you upload is submitted
+ without a filestore, so the upgraded database has to have the production filestore merged into it
+ before you test it. The download contains dump.sql and a filestore folder, and only
+ the person who requested the upgrade can download the result.
+
# 1. OpenUpgrade for the TARGET version (the branch is the target major version)
+git clone --depth 1 --branch <TARGET>.0 https://github.com/OCA/OpenUpgrade.git
+
+# 2. helper library — the line the OpenUpgrade docs use
+pip install "git+https://github.com/OCA/openupgradelib.git@master#egg=openupgradelib"
+
+# 3. put the clone on the add-ons path of the <TARGET> Odoo config
+# addons_path = <your own addons>,</abs/path>/OpenUpgrade
+
+# 4. migrate the copy of the database
+<odoo-bin> -c /etc/odoo/<TARGET>.conf \
+ -d <DB> \
+ --upgrade-path=/abs/path/OpenUpgrade/openupgrade_scripts/scripts \
+ -u all --stop-after-init \
+ --load=base,web,openupgrade_framework
+
+# 5. finish: a plain update, no migration parameters
+<odoo-bin> -c /etc/odoo/<TARGET>.conf -d <DB> -u all --stop-after-init
+ Substitute four things: <TARGET> is the target major version
+ (17, 18 or 19 — not the version you are coming from); <DB> is the copy you are
+ migrating, never the live database; <odoo-bin> is the binary for the target
+ version, and what it is called depends on how you installed Odoo (odoo-bin,
+ odoo, or the Docker equivalent); and both absolute paths are your own — the add-ons
+ path and the location of the OpenUpgrade clone.
+
+ Two details worth carrying from the project's own documentation: the
+ openupgrade_framework part of that command is a set of patches that, among other
+ things, stops Odoo dropping the columns and tables of fields that no longer exist — which is one
+ of the ways a migration loses data. And the environment variable
+ OPENUPGRADE_USE_DEMO=yes keeps demo data in the migrated database when you want it.
+
# Odoo's own code-rewrite command (it runs the scripts in odoo/upgrade_code)
+<odoo-bin> upgrade_code --from <FROM> --to <TO> --dry-run
+ Substitute <FROM> and <TO> with the two
+ major versions (18 and 19, for example). Run it with --dry-run first. Odoo's own
+ command reference calls this command a "best-effort" tool and warns that it is "not silver
+ bullets" — it rewrites what it can and leaves you a list of what a human still has to change. The
+ OpenUpgrade community's equivalent for module code is odoo-module-migrator, which
+ logs INFO for automatic changes, WARNING for things to check and ERROR for things that will not
+ work at all. Both tools report; neither one thinks.
+
# stop the service while you work (packaged install; the Odoo docs show this pattern)
+sudo service odoo<TARGET> stop
+
+# database dump (PostgreSQL's own tool)
+sudo -u postgres pg_dump -Fc -d <DB> -f /path/backup/<DB>.dump
+
+# restore a dump into a fresh database
+sudo -u postgres createdb -O <DB_OWNER> <DB_NEW>
+sudo -u postgres pg_restore -d <DB_NEW> /path/backup/<DB>.dump
+
+# the filestore lives under Odoo's data directory:
+# default on Unix: $XDG_DATA_HOME or ~/.local/share/Odoo or /var/lib/Odoo
+# filestore path: <data_dir>/filestore/<DB>+ Substitute the database names, the owner, the backup path and the filestore data + directory with your own; the filestore is what holds the attachments and documents your records + point at, and a database restored without it is a database whose files are missing. These are + PostgreSQL's and Odoo's documented procedures, not ours — we do not publish a command that runs on + our own servers, because our service starts with a ticket. +
+The ODOO4projects way
++ You do not have to run any of the above. If your business runs on Odoo Community and you want the + version moved without hiring the developer who wrote the ten steps, this is what we do instead. +
++ You open a support ticket and tell us what you have. We look at your database first — its version, + its customisations, whether it is something we can move — and we tell you what we find. Then we send + you a link to a secure form where you upload your database. When we have it, we spin up a new server + for you on our own infrastructure and hand you the credentials. Your existing system keeps running + the whole time, because we are not touching it: we work on the database you sent us and the new + server we built. +
++ That last point is the whole reason to do it this way. On our service you are not migrating your + live database in the evening after the shop closes. You are looking at a second system, in a new + version, with your data in it, and you can compare the two before you decide anything. +
++ Our migration service documents support for databases on Odoo 17, 18 and 19, main releases only — + patch releases such as 18.1 or 17.2 are not supported anywhere in our service. If your database is + older than 17, we can still help you get it to a supported release, but only after reviewing it to + check compatibility. New instances on our servers can be created on Odoo 19 or Odoo 20, so if you + are moving to 20 specifically, say so in the ticket: the version you are going to matters more than + the version you are on. +
++ On the AI side, here is a case we have actually published. Copying invoices from one Odoo instance + to another by hand is slow and easy to get wrong, so we did it with a workflow instead: records + written from an Odoo 19 system into a new Odoo 20 system, driven by an automation workflow and an + MCP server pointed at the new system. Three rules made it safe — the invoice number and date never + change, the contact is looked up rather than guessed, the product is looked up rather than guessed — + and one hard constraint: if a contact or a product is missing, the run fails loudly rather than + creating a near-duplicate. Before releasing it on the rest, we checked one invoice end to end: + number, date, contact, product lines. +
++ One thing we will not blur, because it is the difference between us and a salesman. The MCP server + we ship inside our own management console does hosting operations. It restarts a server, uploads a + module, adds or checks a domain, manages backups and reads a log file — that is the published list, + and it is a real convenience if you use an AI assistant. It is not a data-migration engine and we do + not describe it as one. The import work above was done with an automation workflow and a third-party + MCP; the AI was doing the tedious part and being checked by a human, exactly as it should be. +
++ And the honest limit, in the words of the project that knows this best. The OpenUpgrade + documentation names the export-and-import alternative and prices it plainly: you recover only some + of your data, and in particular you do not get the history and the links between records — the + invoices for each customer, for example. That is the risk of any route that moves documents into a + fresh system, and it is why, if you take that route with us, you ask us one question before you + approve anything: which records will be in the new database, and which will not. We would rather you + ask it than assume it. +
+Sweat equity
++ A rented server is cheap. That is the smallest number in this decision. A modest virtual server + costs about the price of a restaurant meal a year, and Odoo Community itself is free — you will not + find a per-user licence anywhere in this route, because Community does not have one. +
++ What is not in that number is the person. An upgrade on your own server means someone installs the + new version, gets the migration code onto the right path, ports the modules your business actually + uses, runs the migration until the log stops complaining, checks that the customers, orders and + invoices are still there, cleans up what the migration left behind, and then does it again on the + production database at a time that suits the business. Odoo's own documentation says the update is + most appropriately done by the person who deployed Odoo in the first place. On a rented server, that + person is you or someone you pay by the hour — and neither of those lines appears on the invoice. + That is the half of the bill nobody prints, and it is the half that lands in your evenings. +
++ We are not going to put a number on your hours, because we have not measured them and a marketing + figure would be worse than none. What we will say is the part that is not really about money: while + you are doing that work, you are not doing the work you get paid for, and if the migration is wrong + you find out from a customer. +
+Straight answers
++ No. An update gives you the newest revision of the software you already run. An upgrade moves + your database to a new major release — 18 to 19, or 19 to 20 — and transforms the data itself. + It is one-way: there is no supported path back down, and it is not a licence change, an edition + change or a hosting change. +
++ No. It is one major version at a time: 14 → 15 → 16 → 17 → 18 → 19 → 20. Skipping a version is + not a supported path. Our own migration service documents support for databases on Odoo 17, 18 + and 19, main releases only — no patch releases — and older databases need a compatibility review + first, which starts with a support ticket. +
++ That is the right question to ask, and the answer depends on which route you take. A version + migration carries the database across and keeps the history and the links between records; that + is the point of it. A route that moves documents into a fresh system does not, and the + OpenUpgrade documentation says so plainly: export and import recovers only some of your data, + and you lose the history and the links — the invoices for each customer, for example. If your + upgrade runs on our service, ask us to list exactly which records will be in the new database + before you approve anything. +
++ Not by themselves. A module written for your business has to have its code brought up to the + target version, and any renames that would otherwise lose data need their own migration scripts. + Odoo's documentation is direct about it: an upgrade is blocked until a version of your custom + modules exists for the release you are moving to. Modules that ship with Odoo and modules from + the community association carry their own migration scripts; yours do not, and someone has to + write them. +
++ We publish no price and no duration for the upgrade service, and we are not going to invent one + here. What we do publish is how it starts: you open a support ticket, we review your database + for compatibility, and we come back to you. If you are weighing it against doing it yourself, + the honest comparison is not the server rental — it is your own hours, which never appear on + that invoice. +
++ To run the commands in the technical section, yes — or someone comfortable in a terminal with + PostgreSQL. To have us do it, no: that is the point of the service. You send the database, we + build the new system on our infrastructure, and you get credentials. +
++ Yes, and you should. Whoever does the work migrates a copy first — that is the first rule of the + whole process, in Odoo's documentation and in the OpenUpgrade project's — and the migrated copy + is what you inspect before anything happens to the system your business is running on. Our + service follows the same principle: we build the new system on our own servers and you compare + it with the old one. +
++ Yes, that is exactly what our migration service is for. You open a support ticket, we send you a + secure form to upload your database, and we spin up a new server for you on our infrastructure + and provide the credentials. Databases on Odoo 17, 18 and 19, main releases only; older ones + after a compatibility review. +
++ Open a support ticket, we review your database for compatibility, and we come back to you. +
+ +Yes, we can help you upgrade your database from older versions to a supported release (17, 18, or 19), but only after reviewing your database to ensure compatibility. Please submit a support ticket to start the process.
+The full process, and the commands a developer would run, are explained on our Odoo Community upgrade page.