Will I lose data in an Odoo upgrade?

Rarely, and it is not usually where the risk sits. Standard records move with the documented upgrade path and can be reconciled afterwards. The failures that hurt are a module that no longer installs, a view that no longer renders, or a workflow that silently stops firing — the system comes up, and something is quietly not happening any more.

How do I know what will break before committing?

Upgrade a copy, not production. Restore a recent backup into a staging database, run the upgrade there, install each custom module one at a time and note what fails. That gives you a real list rather than an estimate, and the list is what turns an open-ended quote into a scoped job.

Do I have to upgrade Odoo at all?

Not immediately, but the cost of waiting compounds. Each version you fall behind adds another set of changes your modules have to cross in one jump, and support for older versions ends. Skipping versions is possible but it is not cheaper — it is the same work, done all at once, with more of it interacting.

What actually breaks when you upgrade Odoo

It is almost never your data. It is your custom modules. Odoo has a documented path for moving standard records between versions, and it mostly works. What it cannot do is rewrite code someone wrote against the old version — and every module sitting on top of standard Odoo, whether a partner built it, a freelancer built it or it came from the community, has to be read and adapted before it will run on the new one.

Where the work really is

This is not a guess. Across the Odoo upgrade and migration requests CodeCobra has handled in production, roughly three in four were about whether a specific custom module still worked on the new version — not about records, balances or history. Data integrity came up in a small fraction by comparison.

That distribution is worth sitting with, because it is the opposite of how upgrades are usually discussed. The anxiety goes to the ledger. The invoices go to the modules.

What moves	How much trouble it is
Standard records	Handled by the documented upgrade path. Verify afterwards; rarely the blocker.
Configuration and settings	Mostly carries. Expect to re-check anything set up in Studio.
Custom modules	The real work. Every one has to be read against the new version's models, fields and views.
Third-party and OCA modules	Depends entirely on whether someone has already ported them. If not, they are custom modules as far as you are concerned.
Reports and templates	Break quietly. A QWeb template that references a renamed field renders wrong rather than erroring.

Why the failures are quiet

A module that refuses to install is the good case: you find out immediately. The expensive cases are the ones where the system comes up looking fine. A view renders without the field someone relied on. An automated action stops firing because the trigger it hooked moved. A report totals a column that is now computed differently.

Nobody files a ticket on the day of the upgrade. They file it three weeks later, when a number is wrong and the upgrade is no longer the obvious suspect.

How to find out before you commit

The whole question — “what will this cost and what will break” — is answerable before you spend anything real, and the method is unglamorous:

Restore a recent backup into a separate database. Not production, and not a subset — the upgrade behaves differently on real volume.
Run the upgrade there. Whatever fails, fails somewhere that does not matter.
Install your custom modules one at a time. One at a time is the point: installed together, one failure masks the next.
Write down what each one needs. Some need nothing. Some need a rename. Some were written against behaviour that no longer exists and need a rethink.
Exercise the workflows people actually use, especially anything automated. This is where the quiet failures surface.

What you get out of this is a list. The list is the deliverable: it converts an open-ended quote into a set of known jobs, and it is the single most useful thing to have in hand before anyone gives you a number.

Reading an upgrade quote

Given that, a quote that prices “the upgrade” as one number is pricing the unknown — which means pricing it defensively. A quote worth taking seriously names the modules and says something specific about each one.

Two questions separate the two kinds fast. Which of my modules have you looked at?And what happens to the price if one of them turns out to need a rewrite? The answers tell you whether you are buying an assessment or a gamble.

Where CodeCobra fits

Reading a module and saying whether it survives the jump is exactly the shape of work an agent is good at: it is bounded, it is mechanical, and the answer is verifiable by trying it. CodeCobra reads each module against the target version, reports what breaks in plain language, and — with your approval — does the adaptation and opens a pull request you review like any other change.

It works on a disposable copy of your project, so the assessment costs you nothing but time and touches nothing real. You can also stop after the assessment: the list of what breaks is useful whoever ends up doing the work.

Try it free See pricing

Start with free credit — no card required.