Still on Odoo 12 or 13? What Staying Actually Costs

Nothing breaks on the day support ends

Odoo supports each major version for three years. Odoo 12 arrived in October 2018 and left that window in 2021. Odoo 13 arrived a year later and left in 2022. By 2026 both are several years past the point where anyone at Odoo is fixing anything in them.

The system does not notice. It boots, invoices go out, the warehouse picks. This is the single reason so many businesses are still running them, and it is a reasonable response to what they can observe.

What they cannot observe is that the cost has moved off the invoice and onto the balance sheet as risk.

Where the money actually goes

Security you cannot patch

Once a version is out of standard support it receives no security fixes. Vulnerabilities found after that date are disclosed publicly and fixed in current releases, which is exactly the information an attacker needs about your version.

For most businesses this stays theoretical until an audit, a cyber insurance renewal or a customer security questionnaire makes it concrete. Then it becomes urgent, and urgent upgrades are the expensive kind.

A shrinking pool of people

Odoo 12 is a different codebase to work in. The attrs attribute that drove conditional visibility in views has since been removed in favour of direct invisible expressions. The JavaScript layer was rewritten around the OWL component framework. Field names on core models have moved between versions.

A developer who started with Odoo in 2023 has never seen most of this. They can learn it, and you will pay for that learning, on a codebase that has no future. Meanwhile the people who genuinely know Odoo 12 have mostly moved on to work that does.

Integrations age out from the other side

Your ERP is one end of every integration. The other end keeps moving.

Payment providers retire API versions on their own schedule. Banks change statement formats. Shipping carriers deprecate endpoints. When that happens, the fix has to be written against a framework that no longer receives updates, by someone who is comfortable in it, and tested on a version nobody else is running. Every one of those constraints adds cost.

We cover the general shape of this in integration architecture, and it is materially worse when one side is frozen.

The upgrade bill compounds

This is the cost that grows while you wait, and the reason "we will do it next year" is rarely the cheaper choice.

The database conversion is not the problem. Odoo's upgrade service handles standard data in standard models, and the process steps through intervening versions rather than jumping, as we explain in the upgrade path.

The problem is everything you added. Custom modules have to be reviewed and re-tested against every framework change between your version and the target. That work does not scale with the size of the jump in a straight line, because the interactions multiply. Two versions behind is a project with a known shape. Six versions behind is a project where the first phase is finding out what you have.

What actually breaks in a v12 or v13 upgrade

The pattern is consistent enough to plan around. In rough order of how much time they consume:

• View definitions. The old attrs syntax for conditional visibility and readonly is gone. Every custom view that used it needs rewriting, and there are usually more than anyone remembers.
• JavaScript and widgets. Anything built against the pre-OWL framework is a rewrite, not a port. Custom widgets and client actions are the usual casualties.
• Renamed fields and methods on core models. Invisible inside Odoo, breaking for anything that calls in by name. This is where integrations fail.
• Reports. QWeb templates that reference moved fields render blank rather than erroring, which is why they are found late.
• Modules that no longer need to exist. Six years of Odoo releases have absorbed a lot of what used to require custom work.

That last one is the opportunity hiding in the project. Some of what you paid to build in 2018 is now standard, and porting it forward means paying twice for the same feature. A proper fit-gap review before the port is usually the highest-return hour in the whole upgrade.

The full breakdown is in what actually breaks in an Odoo upgrade, and custom module migration covers the porting work itself.

How to plan it from this far back

Upgrading from six versions behind is a different exercise from a routine annual upgrade. The difference is how much of it is discovery.

1. Inventory what you have. Every custom module, every integration, every report anyone depends on. From this far back the list is always longer than the one people carry in their heads.

2. Decide what deserves to survive. Sort the inventory into keep, replace with standard Odoo, and retire. The retire pile is usually the biggest surprise and the biggest saving.

3. Convert the database and see what happens. A test conversion tells you more in a day than a fortnight of speculation. Nothing is at risk because nothing touches production.

4. Test as real users, not as an administrator. An administrator session cannot see an access rights problem, which is why they are found by staff in week one rather than by the project in week six. Our upgrade testing strategy covers how to structure this.

5. Plan the rollback before the cutover. Not because you expect to use it, but because deciding under pressure produces worse decisions. See rollback planning.

6. Run parallel briefly. Compare the numbers that matter, on real data, before you commit.

Migration validation covers what to compare, and upgrade mistakes covers what tends to go wrong.

The honest version of the advice

If you are on Odoo 12 or 13 and everything works, you do not have an emergency. You have a growing liability with no deadline attached, which is harder to act on than an emergency and more expensive to ignore.

The useful next step is not a quote. It is a test conversion and an inventory, because both are cheap and both replace guesses with facts. Once you know what you have and what survives, the decision between upgrading and reimplementing usually makes itself.

We do this work as a fixed-scope assessment before anyone commits to the larger project, precisely because from this far back nobody, including us, can price the project honestly without it.