Sep 28, 2026

Most Odoo projects go smoothly on day one. The trouble shows up a year or two later, when it’s time to move to the next major version and someone asks a simple question: which of our changes are going to break?

The answer depends largely on how each change was made. A field added through Odoo Studio and a feature written as a custom Python module look the same to your users. During an upgrade, they behave very differently.

This guide explains the difference, where each approach tends to fail, and how to make customization decisions today that won’t turn your next upgrade into a rebuild.

The short answer

Type of change	Usually made with	Upgrade risk
New fields, labels, form and list layouts	Studio	Low
Simple approval rules and automated actions	Studio	Low to medium
Custom PDF reports (invoices, delivery notes)	Studio or code	Medium
New business logic, calculations, workflows	Custom module	Medium to high
Changes to how standard Odoo features behave	Custom module	High
Integrations with other systems (banks, marketplaces, tax portals)	Custom module	High
Third-party apps from the Odoo Apps store	Vendor module	Depends on the vendor

The pattern is simple. The more a change reaches into Odoo’s own behaviour, the more work it takes to carry forward.

How an upgrade treats each kind of change

Studio changes: carried forward, but still worth testing

Odoo Studio is the drag-and-drop editor included with Odoo Enterprise. Behind the scenes, it stores your changes as configuration Odoo understands, rather than as separate code. When Enterprise customers upgrade through Odoo’s upgrade service, Studio customizations are generally migrated along with the standard database.

“Generally” is doing some work in that sentence. Studio changes usually sit on top of standard screens and fields. If a new version renames a field, restructures a form or reworks a report template, a Studio tweak built on the old layout can end up misplaced or broken. The risk is lower, not zero.

Custom modules: someone has to port them

A custom module is Python and XML code written by a developer. Odoo’s upgrade service moves your data, but it doesn’t rewrite your custom code for the new version. A developer or partner has to update each module to match the new framework, test it and fix what breaks.

How much work that takes depends on how the module was written. A module that adds its own screens and models usually ports cleanly. One that overrides core methods, like how invoices post or how stock moves are validated, has to be checked line by line against Odoo’s changes.

Third-party apps: only as good as their maintainer

Modules bought from the Odoo Apps store sit in between. If the vendor releases a version for your new Odoo release, you’re fine. If they’ve stopped maintaining it, you inherit the problem. Always check a vendor’s version history before relying on their app for something critical.

Where Studio runs out of road

Studio is great for quick, visible changes. It struggles when you need:

• Complex logic, like pricing that depends on customer tier, region and stock level at once
• Heavy automation that would need dozens of chained automated actions to fake
• Integrations with banks, marketplaces, logistics providers or government tax systems
• Performance on large data volumes, where a poorly designed computed field slows everything down

Pushing Studio past these limits usually creates fragile workarounds that are harder to upgrade than clean code would have been.

Where custom modules earn their keep

A well-written module is the right call when the requirement is genuinely unique to how your business works, needs to behave reliably at scale, or connects Odoo to the outside world. The key word is well-written. A module that extends Odoo rather than rewriting it, and comes with documentation and tests, is far cheaper to carry through upgrades.

Customization debt: the cost you don’t see on the invoice

Every customization carries a small ongoing cost: it has to be understood, tested and carried forward every time Odoo moves on. Like financial debt, a little is fine. Too much quietly limits what you can do.

You probably have customization debt if:

• You’re two or more major versions behind because upgrading “feels too risky”
• Nobody on the current team knows what half the custom modules do
• Several modules change the same standard feature in different ways
• Studio changes and custom code overlap on the same screens
• Staff avoid new Odoo features because they “don’t work with our setup”

The fix isn’t to stop customizing. It’s to be deliberate about which tool each change uses, and to write it down.

A simple rule: the lightest tool that does the job

Before approving any change, work down this ladder and stop at the first step that solves the problem:

1. Standard Odoo. Does an existing feature already do this if you change how you work slightly?
2. Configuration. Can settings, user rights or existing options handle it?
3. Studio. Is it a field, view, simple rule or report tweak?
4. Custom module. Only when the first three genuinely can’t do the job.

This standard-first sequence is the same one used in M+ Software’s guide to Odoo customization in Indonesia, which also walks through the risks and costs of each step for businesses there.

The ladder matters even more in markets with local requirements. In Southeast Asia, tax reporting formats, e-invoicing rules and local document layouts often change on their own schedule, separate from Odoo’s release cycle. Businesses implementing Odoo with a regional partner such as M+ Software tend to keep these localisation changes separate from the rest of their customizations, so a tax rule update doesn’t have to wait for a full version upgrade, and the other way round.

Before your next upgrade: a quick checklist

Whether you’re planning a move next month or next year, these steps make it far less painful:

1. List every customization. Note what it does, who asked for it, and whether it was built in Studio, as a custom module or as a third-party app.
2. Ask if each one is still needed. Newer Odoo versions often add features that make old customizations unnecessary. Retiring them is the cheapest upgrade work there is.
3. Check third-party apps. Confirm each vendor supports the version you’re moving to.
4. Flag high-risk modules. Anything that overrides core behaviour, handles accounting or connects to outside systems needs extra testing time.
5. Test on a copy first. Run the upgrade on a duplicate database and have real users walk through their daily tasks before switching over.
6. Document as you go. A short note per customization saves hours at the next upgrade.

The takeaway

Studio and custom modules aren’t rivals; they’re tools for different jobs. Studio keeps simple changes light and relatively upgrade-friendly. Custom modules handle the requirements that truly set your business apart, as long as they’re built cleanly and documented.

The businesses that upgrade smoothly aren’t the ones with no customizations. They’re the ones that chose the lightest tool each time, and kept track of what they built.