The yearly rhythm

Odoo releases a new version every year and supports each one for roughly three years.

That gives you a window. You do not have to upgrade the moment a version appears — and you should not — but you cannot ignore it indefinitely either. Once your version leaves support, security fixes stop.

A sensible position: stay one version behind the newest, and plan the move deliberately rather than being forced into it.

What an upgrade actually changes

This is not a patch. Three things change at once.

The data structure. Fields get renamed, models get restructured, tables are reorganised. Your data has to be transformed to fit.

The behaviour. Standard features change. Screens move. Something your team does every day may work differently.

Your custom modules. They were written against the old structure. Some will need adjusting.

That third one is where the work is.

The single biggest factor

How much custom code you have.

A standard Odoo with no customisation upgrades fairly cleanly. Odoo’s own upgrade service handles the data, and testing is mostly confirming that nothing surprising changed.

A heavily customised Odoo is a different exercise. Every module needs checking against the new version, and some will need rework.

This is the strongest practical argument for the rules that sound bureaucratic when a partner first mentions them:

Keep custom work in separate modules. Never in Odoo’s own files. At upgrade time this difference is measured in days.

Keep customisation to what earns its place. Every module is a permanent upgrade cost. A feature nobody uses is still something to test every year.

Document why each customisation exists. In three years nobody will remember, and you will be testing something whose purpose is a mystery.

How to run one

The sequence matters. Skipping steps is where upgrades go wrong.

1. Take a full backup

Database and filestore. Verify it restores before you go further.

2. Upgrade a copy in staging

Never production first. Odoo provides an upgrade service that takes your database and returns an upgraded copy.

3. Test your custom modules

Each one, individually. Do they install? Do they behave the same way? Have any of the fields or methods they rely on moved?

4. Test your integrations

Anything talking to Odoo through the API was built against the old data model. Field names change. Payment gateways, shipping carriers, reporting tools, custom scripts — all of them need checking.

5. Have your team run real scenarios

Not a demo. Real cases from your business: a full sales cycle, a purchase cycle, a stock adjustment, a month-end report. Compare the output with what the old version produced.

6. Note what changed for users

Standard behaviour will have moved somewhere. Write a short list and share it before go-live, not after.

7. Schedule production

Pick a quiet period. Take another backup immediately before. Know your rollback plan.

What usually causes trouble

Five patterns, in rough order of frequency.

Custom modules nobody understands. Written years ago by someone who has left. Now something breaks and nobody can say what it was meant to do.

Studio changes with no record. Dozens of fields and automations added by clicking, over two years, with no log of what or why.

Integrations forgotten. Everyone tests the interface and nobody tests the nightly job that posts payments. It fails silently after go-live.

Reports that shifted. Custom report layouts often need adjustment. Nobody notices until a customer receives an odd-looking invoice.

No time allowed for it. Treated as an afternoon’s work, discovered to be a week’s, and rushed.

Community and Enterprise

The difference matters here.

Enterprise includes upgrade assistance. Odoo runs the database upgrade and supports you through problems.

Community upgrades are yours to manage. The tooling exists and it is well documented, but the work and the risk are yours.

For a business with meaningful customisation and no in-house technical capability, this is often the deciding factor between the two editions.

Deciding when

Four questions.

Is our version still supported? If support ends within a year, plan now.

Is there a feature we actually need? A specific requirement is a good reason. “It is newer” is not.

Is our custom code in a state to move? If nobody understands it, sort that out first.

Do we have a quiet period? Not during your busiest month, and not during year-end close.

What to budget

Not just money — time and attention.

Technical work. Testing and adjusting custom modules and integrations.

Your team’s time. Testing real scenarios properly takes hours from people who have other jobs.

A slower fortnight after go-live. People will be careful and will ask questions. That is normal and healthy.

Contingency. Something will need fixing that testing did not catch.

Companies that budget for these are not surprised. Companies that treat an upgrade as a patch are.

The short version

An upgrade is a small project, not a maintenance task.

The amount of work is decided almost entirely by choices made much earlier — whether customisation went into modules, whether it was documented, and whether anyone knows what the integrations do.

Do those three things well and upgrades become routine. Skip them and every year brings a rescue operation.