Public Access
Compare commits
2
Commits
3c602d97be
...
68c26e9725
| Author | SHA1 | Date | |
|---|---|---|---|
 oliver
|
68c26e9725 | ||
|
oliver
|
2fe0c31e2b |
+113
-78
@@ -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 <DB_NEW> /path/backup/<DB>.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 <DB_NEW> /path/backup/<DB>.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 <DB_NEW> /path/backup/<DB>.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>
|
||||
|
||||
Reference in new issue
Block a user