Odoo customization: Studio, custom modules and upgrade cost

Odoo customization has three layers, and each costs more to keep than the one before: configuration, which means the standard product’s own settings; Studio, Odoo’s no-code toolbox; and custom modules written in Python and XML. Use the lowest layer that does the job, because every layer above it adds work at each upgrade.

This guide follows the Odoo 20.0 documentation and links the page behind each claim. It covers what each layer can do, what it costs when you upgrade, and the cases where the right answer is not to customize. Which edition you run changes the options, and we compare the two in Odoo Community vs Enterprise.

The three layers of Odoo customization

Layer	What you do	Who does it	At upgrade
Configuration	Turn on and set the options the apps already have	Your team or your implementer	Standard applications are covered by Odoo’s upgrade service on Enterprise
Studio	Add or change fields, views, models, automation rules, webhooks, PDF reports, approval rules and security rules without code	A trained non-developer	Covered while Studio stays installed and its subscription stays active
Custom modules	Python and XML that extend Odoo’s own models and views by inheritance	A developer	The database cannot be upgraded until your module exists for the target version

Sources: Studio documentation, inheritance tutorial and upgrade documentation. The last column is about Enterprise’s upgrade service; we explain it below.

Configure before you customize

Many gaps are settings nobody switched on. Before you ask for a change, find the app’s documentation for your version, turn the option on in a test copy of your database, and see whether it does what you need.

Our inventory guide has a good example. A one-, two- or three-step receipt and delivery flow looks like a customization, but Odoo’s routes documentation says two warehouse fields are all you set; you do not write the rules by hand. We cover it in Odoo inventory management. Configuration is part of the standard product, so it is the cheapest layer to carry forward, although the upgrade service does not clean up pre-existing data and configuration.

Also ask whether the process, not the software, should change. A step that exists only because the old system needed it is not a requirement. On our Odoo page we say we customize as little as possible and would rather fit the process to the tool when we can. That is our advice, not Odoo’s rule, but it is cheaper than the alternative.

Studio: no code, with a plan attached

Odoo’s documentation describes Studio as a toolbox for customizing Odoo without coding knowledge. You open an app, toggle Studio on, and add or modify fields, views, models, automation rules, webhooks, PDF reports, approval rules and security rules in any app. The Studio page adds drag-and-drop fields, editing of documents such as invoices, triggers and automated actions, approvals that check critical actions before they run, menu changes, fields that are conditionally invisible, required or read-only, and an XML editor for advanced report changes.

That is a lot of what most companies call customization: an extra field on a customer, a screen with fewer columns, an invoice layout, an approval before a large purchase order. We reach for Studio first for exactly these.

Two practical points:

• It is tied to a plan. Odoo’s pricing page lists “Odoo Studio” on the Custom card, not the Standard card, and its FAQ says the free plan can take Studio as its one app. The Studio documentation says installing it on a Standard plan triggers an upsell to Custom. Price that before you plan to use it.
• Its upgrade cover has conditions. Under the upgrade service’s terms, Studio customizations are covered as long as Studio remains installed and its subscription stays active. Dropping Studio later changes that.

The Studio documentation does not list functional limits, so test your requirement in a copy before you promise it. Keep a short list of what you built with Studio, what for, and who asked. A year on, nobody remembers.

Custom modules: code that extends Odoo

When a setting or Studio cannot do it, a developer writes a module. Odoo’s inheritance tutorial describes two ways to extend a model that another module defines. The common one declares _inherit with the existing model’s name, and the module can then add fields, override fields, add constraints, add methods or override existing methods. The other, delegation, links each record to a parent model’s record.

Views work the same way. The tutorial says that instead of modifying existing views in place, Odoo provides view inheritance: an extension view points to its parent with inherit_id, and its xpath elements select and alter the parent’s content, with a position such as inside, replace, before, after or attributes.

Two rules follow, and we hold ourselves to both:

• Extend; never edit Odoo’s own files. A change made inside Odoo’s code has to be redone at every update. A module that inherits sits beside Odoo’s code and can be carried forward.
• Call the parent. When you override create(), write() or unlink(), the tutorial says it is “very important to always call super() to avoid breaking the flow.”

Before you commission a module, look in the Odoo Apps store. Someone may already publish what you need, such as a connector or a local accounting rule. Remember that an extra module, whether built in-house or by a third party, is outside the upgrade service unless it has a maintenance contract, as the next section explains.

Test every module on a copy of your database with real data, not on production. Hand the developer your actual edge cases: the odd customer, the credit note, the order in a second currency.

What customization costs at upgrade

This is where customizations get expensive, and the reason to choose the lowest layer. Odoo’s upgrade documentation says:

• Each major version is supported for three years, so a database will be upgraded on a schedule.
• A database with custom modules cannot be upgraded until a version of those modules is available for the target version. Their maintainer updates them, and Odoo recommends doing that in parallel with requesting an upgraded test database.
• If a change in a new version breaks a customization, fixing it is the responsibility of the maintainer of your custom module.
• With Odoo Enterprise, upgrading to the most recent version is free, under the Enterprise Subscription Agreement. Standard applications and Studio customizations are covered; developments are covered only under a maintenance of customizations subscription.
• Not covered: cleaning pre-existing data and configuration, upgrading additional modules without a maintenance contract, and training on the new version.

The pricing page lists custom code maintenance as not included in any plan. So the free upgrade covers Odoo’s product. The cost of the code you added is yours, in a quote or in staff hours.

The documentation also recommends testing the upgraded copy across key business flows, integrations, exports, automated actions and server actions, and rehearsing the production upgrade the day before go-live because the upgrade scripts change over time. Every customization you add is one more thing to put on that list.

On Community, the upgrade service is not part of the picture.

When customizing is a bad idea

• A setting or the standard flow already does it. Check configuration first, in a copy of your database.
• You are copying the old system. Matching a familiar screen or an old report layout is a habit, not a requirement. Ask what decision the screen supports.
• Nobody will own it. A module with no named maintainer fails the first upgrade, since the maintainer is the one who must update it.
• The feature needs a plan or edition you have not chosen. If it depends on Studio across all apps, you are looking at the Custom plan. If you are on Community, you are writing code. Decide the edition first.
• It reaches into stock or accounting. In our experience, changes to how stock moves or how entries are posted are the hardest to carry from one version to the next. Prefer a report or an extra field to a changed calculation.
• A third-party module exists but nobody maintains it. Cheaper to adopt, but you inherit the same upgrade problem.

A sensible order of work

1. Write the gap as one sentence: who needs what, how often, and what it costs today.
2. Look for a setting. Read the app’s documentation for your version and try it in a copy.
3. Consider changing the process if that costs less than building.
4. Try Studio for fields, views, reports and simple automations, if your plan includes it.
5. Write a module only for what remains, with a specification, tests on a copy and a named owner.
6. Record each customization: what it does, why, who maintains it and which version it was last tested on.
7. Rehearse the upgrade on a copy before the real one, with the people who use the system.

Frequently asked questions

Can Odoo be customized?

Yes, in three ways: configuration, Studio and modules that extend Odoo through inheritance.

What is the difference between Odoo standard and custom?

Standard is what Odoo ships and upgrades. Custom is anything you add on top, whether Studio, a module written for you or a third-party module. The upgrade documentation treats them differently: standard applications are covered, while custom modules need a maintainer.

Do customizations break when you upgrade Odoo?

They can. A database with custom modules cannot be upgraded until those modules exist for the target version, and Odoo’s upgrade page says fixing a customization broken by a new version falls to its maintainer. Test on a copy first.

Do I need a developer, or is Studio enough?

Studio covers fields, views, reports, automations and approvals. Anything beyond that needs a developer. Studio is listed on the Custom plan, per the pricing page.

Does Odoo’s support cover my customizations?

Not custom code: the pricing page lists custom code maintenance as not included.

If you are deciding what to configure, build or leave alone, talk to us with your list of gaps. We will tell you which layer each belongs in, and how we handle this in our Odoo implementation and support work.