From 695f42a04f2807a77346e3d3a55bceb616e01f1a Mon Sep 17 00:00:00 2001 From: webmaster Date: Tue, 27 Oct 2026 18:43:33 +0000 Subject: [PATCH] feat(site): publish /odoo-community-upgrade.html (EN Odoo Community Upgrade page) New EN landing page for the head term "ODOO Community Upgrade": hero, what an upgrade is, the 10-step published process, a developer-labelled technical section with four sourced command blocks and their substitution notes, the ODOO4projects migration service (new database on our servers), the self-hosting cost honesty section, an 8-question FAQ and a final CTA. House CI only, page-scoped CSS, no new blocking resources. - CTAs are plain links to the real flows: /support.html#contact (opens the migration ticket) and /index.html#pricing. No basket POST and no product id: no price is published for the migration service, so wiring a buy would invent one. - JSON-LD: WebPage + Service + FAQPage (8 questions), no Offer node. - sitemap.xml: new URL added; llms.txt: page listed under Key pages. - support.html: the "older version" FAQ answer now links the new page so it is not orphaned. Copy: copywriter/out/odoo-community-upgrade-page-copy-2026-10-27.md. The 7 NOT PUBLISHED gaps (G1-G7) are not in the build. --- llms.txt | 1 + odoo-community-upgrade.html | 1002 +++++++++++++++++++++++++++++++++++ sitemap.xml | 6 + support.html | 1 + 4 files changed, 1010 insertions(+) create mode 100644 odoo-community-upgrade.html diff --git a/llms.txt b/llms.txt index f33d169..01d94e7 100644 --- a/llms.txt +++ b/llms.txt @@ -30,6 +30,7 @@ ## Key pages +- [Odoo Community upgrade](https://odoo4projects.com/odoo-community-upgrade.html): what an upgrade changes, the published step-by-step process, the real commands for a developer (Odoo's upgrade platform and the OCA OpenUpgrade route) and how we migrate a database onto our servers. No price and no duration are published for the migration service; it starts with a support ticket. - [Odoo hosting in Australia — Sydney](https://odoo4projects.com/australia.html): managed Odoo Community hosting on our own servers in Sydney, for Australian businesses. The four plans and yearly prices, the checkout with Australia (Sydney) pre-selected, and the one Sydney claim we make — we host in Sydney (no AU support hours, no AU entity, no AUD price published). - [Odoo hosting 2027 — comparison landing page](https://odoo4projects.com/odoo-hosting-2027.html): every route to Odoo (managed, VPS, odoo.sh, Odoo Online, own hardware) side by side, with annual and five-year cost comparisons. - [Odoo ERP Automation Bootcamp](https://odoo4projects.com/odoo-erp-automation-bootcamp/): a three-month, ten-session live bootcamp with Oliver Arnold, Technical Lead, that takes a small business from zero to a running ERP. Thursdays, one hour, Q1 2026, starting 8 January 2026; one year of hosted Odoo Community Edition included. The current price is confirmed on registration. diff --git a/odoo-community-upgrade.html b/odoo-community-upgrade.html new file mode 100644 index 0000000..b5a295a --- /dev/null +++ b/odoo-community-upgrade.html @@ -0,0 +1,1002 @@ + + + + + + Odoo Community Upgrade — Managed for You | ODOO4projects + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ ODOO4projects + +
+
+
+ + +
+
+ Amsterdam at dusk — one of the six regions our servers run in +
+
+

ODOO COMMUNITY UPGRADE

+

Odoo Community Upgrade: What Changes, and How We Do It For You

+

+ 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. +

+
+ Open a ticket — tell us which version you run + See the plans +
+
+
+ + +
+
+

The difference that matters

+

What an Odoo Community upgrade actually is

+
+

+ 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

+

The upgrade process, step by step

+
+

+ 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. +

+
+
    +
  1. + Back up the database, and know where the filestore is. Before anything else. The + documentation of the OpenUpgrade project says you absolutely must take a backup of the live + database, and every practitioner does this first. +
    2. +
  2. + Work on a copy. Restore the backup into a test database and migrate that. Your live + system stays untouched until the copy works. +
    3. +
  3. + Bring the target version up first. Install the newer Odoo, and put the OpenUpgrade + code for the target version on its add-ons path, alongside the modules you already use. +
    4. +
  4. + Port your custom modules. Bring their code to the new version before the migration + runs. +
    5. +
  5. + Run the migration on the copy. One module at a time, in dependency order, each + running its own pre-script, then loading, then its post-script. +
    6. +
  6. + Expect to run it more than once. This is iterative. In the recorded workshop, the + environment — repositories, branches, the module list — is the part that takes the time; the + migration run itself is quick once the environment exists, and you reset and run again until the log + is clean. +
    7. +
  7. + Finish with a plain update. Running the update once more without the migration + parameters is what clears the "incompatible" state and leaves the database usable. +
    8. +
  8. + Test by data, not by the version number. Open the migrated copy and check the + things that matter: a customer, a product, an order, an invoice, a payment. That is how the + practitioners verify it on screen. +
    9. +
  9. + Clean up afterwards. Obsolete tables, columns and views left behind by a migration + cost performance, so they are removed once the system has been running for a while and nobody has + reported a problem. +
    10. +
  10. + Then move to production. Restore the migrated database where it belongs, or have + the upgrade run on the production database at a time you choose. +
    11. +
+

+ 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

+

For your developer: the actual commands

+
+

+ 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's upgrade platform

+

+ 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. +

+
+
+ +
+

The Community route: OCA OpenUpgrade

+ 
# 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. +

+
+
+ +
+

Your custom modules

+ 
# 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. +

+
+
+ +
+

Backups and the filestore

+ 
# 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

+

The ODOO4projects way: a new database, and we do the work

+
+

+ 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

+

What doing it yourself really costs

+
+

+ 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

+

Questions about upgrading

+
+
+ Is an upgrade the same as an update? +
+

+ 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. +

+
+
+
+ Can we upgrade straight from Odoo 14 to Odoo 20? +
+

+ 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. +

+
+
+
+ What happens to my history — the invoices, the payments, the attachments? +
+

+ 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. +

+
+
+
+ Will my custom modules still work? +
+

+ 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. +

+
+
+
+ What does it cost, and how long does it take? +
+

+ 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. +

+
+
+
+ Do I need a developer? +
+

+ 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. +

+
+
+
+ Can I look at the upgraded system before going live? +
+

+ 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. +

+
+
+
+ We are hosted somewhere else. Can you still upgrade us? +
+

+ 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. +

+
+ Open a ticket — tell us which version you run + See the plans +
+
+
+ + + + + diff --git a/sitemap.xml b/sitemap.xml index 5dd7a41..826d526 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -18,6 +18,12 @@ monthly 0.9 + + https://odoo4projects.com/odoo-community-upgrade.html + 2026-10-27 + monthly + 0.9 + https://odoo4projects.com/odoo-erp-automation-bootcamp/ 2026-10-24 diff --git a/support.html b/support.html index 728ff66..439d26c 100644 --- a/support.html +++ b/support.html @@ -485,6 +485,7 @@

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.