---
title: "Odoo customization: Studio, custom modules and upgrade cost"
description: "Odoo customization in three layers: configuration, Studio and custom modules. What each does, what it costs at upgrade, and when not to customize at all."
url: "https://www.noordev.com/blog/odoo-customization/"
lang: "en-CA"
---

[Blog](https://www.noordev.com/blog/)

# Odoo customization: Studio, custom modules and upgrade cost

By Sara L, Blogger · Published October 26, 2026

![Illustration of two people at screens showing a point-of-sale keypad, a checklist and a product list, with the Odoo logo and two gears above them](https://www.noordev.com/assets/blog/odoo-customization/hero.webp)

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](https://www.noordev.com/blog/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](https://www.odoo.com/documentation/20.0/applications/studio.html), [inheritance tutorial](https://www.odoo.com/documentation/20.0/developer/tutorials/server_framework_101/12_inheritance.html) and [upgrade documentation](https://www.odoo.com/documentation/20.0/administration/upgrade.html). 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](https://www.odoo.com/documentation/20.0/applications/inventory_and_mrp/inventory/shipping_receiving/daily_operations/use_routes.html) says two warehouse fields are all you set; you do not write the rules by hand. We cover it in [Odoo inventory management](https://www.noordev.com/blog/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](https://www.noordev.com/odoo/) 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](https://www.odoo.com/documentation/20.0/applications/studio.html) 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](https://www.odoo.com/app/studio) 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](https://www.odoo.com/pricing) 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](https://www.odoo.com/documentation/20.0/administration/upgrade.html) 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](https://www.odoo.com/documentation/20.0/developer/tutorials/server_framework_101/12_inheritance.html) 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](https://apps.odoo.com/apps). 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](https://www.odoo.com/documentation/20.0/administration/upgrade.html) 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](https://www.odoo.com/pricing) 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](https://www.odoo.com/documentation/20.0/applications/studio.html) and [modules that extend Odoo through inheritance](https://www.odoo.com/documentation/20.0/developer/tutorials/server_framework_101/12_inheritance.html).

### 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](https://www.odoo.com/documentation/20.0/administration/upgrade.html) 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](https://www.odoo.com/pricing).

### Does Odoo’s support cover my customizations?

Not custom code: the [pricing page](https://www.odoo.com/pricing) lists custom code maintenance as not included.

If you are deciding what to configure, build or leave alone, [talk to us](https://www.noordev.com/contact/) 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](https://www.noordev.com/odoo/) work.

Want this done for your business?

[See the service](https://www.noordev.com/odoo/)

[All posts](https://www.noordev.com/blog/)