Oliver/ODOO4projects.com
Public Access
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

copy(upgrade): apply the 5 ICP-required changes to /odoo-community-upgrade.html

Browse Source 
Retrospective ICP 1 review (kanban t_03b62410) found the EN page made a
non-technical owner-operator hesitate: the offer sat behind four blocks of
shell commands, the hero ended on "a developer", one hero line carried an
untraced claim, there was no route to a number, the FAQ printed the
OpenUpgrade data-loss warning against our own fresh-database service, and
the "restaurant meal" simile was unitless.

R1 move "The ODOO4projects way" above the process and the commands; swap the
   two band classes so the page still alternates; keep the offer's code cards
   legible on the dark band; reword the §5 intro and §6 opening sentence.
R2 hero subhead reworded, dropping the untraced "costs you your history".
R3 "See the plans" route added inside §6, with the honest "not priced on that
   page" clause. No price, no plan hero, no Offer node.
R4 FAQ "What happens to my history…" answer rewritten (JSON-LD acceptedAnswer
   kept verbatim-equal to the visible text).
R5 "restaurant meal" clause deleted.

Band-aware text colours added for the elements the class swap re-parented
(process list on light, technical section and its notes on dark, the §6 link).
No other content changed: H1, CTAs, code blocks (all 4 byte-identical),
Sweat Equity, the 8 FAQs and the JSON-LD shape are untouched.
This commit is contained in:
oliver committed 2026-10-27 19:03:06 +00:00
1 parent 3c602d97be
commit 2fe0c31e2b
1 file changed
+113 -78
Download Patch File Download Diff File Expand all files Collapse all files
odoo-community-upgrade.html
+113 -78
View File
@@ -217,6 +217,31 @@
overflow-x: auto;
box-shadow: var(--shadow-rest);
}
.section-dark .oc-code {
background: var(--midnight-2);
}
/* R1 moved the process list onto a light band and the technical section onto a
dark one, so their text colours have to follow the band, not their old parent. */
.section-light .oc-steps li {
color: var(--ink-soft);
}
.section-light .oc-steps li strong {
color: var(--ink);
}
.section-dark .oc-sub h3 {
color: var(--cream);
}
.section-dark .oc-sub > p,
.section-dark .oc-note {
color: rgba(255, 255, 255, 0.78);
}
.section-dark .oc-note strong {
color: #fff;
}
/* R3 puts the "See the plans" link inside the dark offer band. */
.section-dark .oc-body a {
color: var(--brass-bright);
}
.oc-code code {
display: block;
font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, "Liberation Mono", monospace;
@@ -401,7 +426,7 @@
"name": "What happens to my history — the invoices, the payments, the attachments?",
"acceptedAnswer": {
"@type": "Answer",
"text": "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."
"text": "That is the right question to ask, and the honest answer is that it depends on the route. The OpenUpgrade route — a version migration run on your own server — carries the database across and keeps the history and the links between records. The OpenUpgrade documentation warns that the other route, moving documents into a fresh system, recovers only some of your data and loses the history and the links between records — the invoices for each customer, for example. Our service builds you a new database and moves your data into it, so ours is the route to ask about: before you approve anything, ask us to list exactly which records will be in the new database, and which will not. We would rather you ask it than assume it."
}
},
{
@@ -487,9 +512,10 @@
<p class="hero-kicker">ODOO COMMUNITY UPGRADE</p>
<h1><span>Odoo Community Upgrade</span>: What Changes, and How We Do It For You</h1>
<p class="hero-sub">
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.
Moving up a major Odoo version is not an update: it is a one-way change to your database, and it
is not something you want to get wrong. Here is how we do it for you — a new system on our own
servers, your current one left untouched while we work — and, underneath, the exact commands a
developer would run.
</p>
<div class="hero-actions">
<a href="support.html#contact" class="btn btn-brass btn-lg">Open a ticket — tell us which version you run</a>
@@ -541,8 +567,76 @@
</div>
</section>
<!-- Our way -->
<section class="section-dark" id="our-way">
<div class="container">
<p class="section-kicker">The ODOO4projects way</p>
<h2 class="section-title">The ODOO4projects way: a new database, and we do the work</h2>
<div class="oc-body">
<p>
You do not have to do any of this yourself. If your business runs on Odoo Community and you want
the version moved without hiring someone to work through the sequence on this page, this is what we
do instead.
</p>
<p>
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.
</p>
<p>
If you would rather see a number first: which plan you need depends on the modules you run, and the
plans are here — <a href="index.html#pricing">See the plans</a>. The upgrade itself is not priced on
that page; we come back to you after we have looked at your database.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
</section>
<!-- Process -->
<section class="section-dark">
<section class="section-light">
<div class="container">
<p class="section-kicker">The published path</p>
<h2 class="section-title">The upgrade process, step by step</h2>
@@ -608,13 +702,14 @@
</section>
<!-- Technical section -->
<section class="section-light" id="commands">
<section class="section-dark" id="commands">
<div class="container">
<p class="section-kicker">For your developer</p>
<h2 class="section-title">For your developer: the actual commands</h2>
<div class="oc-body">
<p>
If you are running Odoo Community yourself and you want to do this in-house, these are the commands.
If you are running Odoo Community yourself and you would rather do this in-house than have us do
it, 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,
@@ -740,67 +835,6 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
</div>
</section>
<!-- Our way -->
<section class="section-dark" id="our-way">
<div class="container">
<p class="section-kicker">The ODOO4projects way</p>
<h2 class="section-title">The ODOO4projects way: a new database, and we do the work</h2>
<div class="oc-body">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
</section>
<!-- Self-hosting cost -->
<section class="section-light">
@@ -809,9 +843,9 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
<h2 class="section-title">What doing it yourself really costs</h2>
<div class="oc-body">
<p>
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.
A rented server is cheap. That is the smallest number in this decision. Odoo Community itself is
free — you will not find a per-user licence anywhere in this route, because Community does not have
one.
</p>
<p>
What is not in that number is the person. An upgrade on your own server means someone installs the
@@ -865,13 +899,14 @@ sudo -u postgres pg_restore -d &lt;DB_NEW&gt; /path/backup/&lt;DB&gt;.dump
<summary>What happens to my history — the invoices, the payments, the attachments?</summary>
<div class="cmp-a">
<p>
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.
That is the right question to ask, and the honest answer is that it depends on the route. The
OpenUpgrade route — a version migration run on your own server — carries the database across and
keeps the history and the links between records. The OpenUpgrade documentation warns that the
other route, moving documents into a fresh system, recovers only some of your data and loses the
history and the links between records — the invoices for each customer, for example. Our service
builds you a new database and moves your data into it, so ours is the route to ask about: before
you approve anything, ask us to list exactly which records will be in the new database, and
which will not. We would rather you ask it than assume it.
</p>
</div>
</details>