Use Studio when you are already on Odoo Enterprise and the change is configuration: fields, layouts, report tweaks, approvals and simple automation rules. Odoo's upgrade service carries those forward while Studio stays installed and your subscription is active. Write a custom module when the change is logic, an integration, something you need in Git with tests, or when you run Community, which has no Studio. Judge both by what they cost over the next two or three upgrades, not by what they cost to build.
Our Studio guide for Odoo 19 covers what Studio can do, feature by feature. This post is about the trade-off: licensing, upgrades, version control and the costs that show up later.
Studio and custom modules side by side
| Studio | Custom module | |
|---|---|---|
| Edition | Enterprise only (licensed OEEL-1) | Community or Enterprise |
| Odoo Online plan | Custom plan, or One App Free with Studio as the app | Not allowed on Odoo Online |
| Hosting | Online, Odoo.sh or on-premise | Odoo.sh or on-premise |
| Who builds it | A trained functional user | A developer |
| Where it lives | In the database | In files, ideally a Git repository |
| Review and tests | None built in | Code review, automated tests, CI |
| Upgrades | Covered by Odoo's upgrade service, with conditions | Code must be ported by you or your partner |
Licensing: what each one needs from your Odoo plan
Studio is an Enterprise app. Odoo's pricing page says that installing Studio on a paid database moves it to the Custom plan, and describes Custom as the plan for companies that customise Odoo "through Odoo Studio, agentic AI, custom developments or through the API". The free One App Free plan is the exception: Studio can be the one app you choose.
Custom modules have their own plan logic. Odoo Online does not accept them, so code means Odoo.sh or your own servers. Odoo's pricing page only offers those hosting options on the Custom plan, and Odoo.sh hosting is charged on top. So on Enterprise, Studio and custom code both put you on Custom; the plan is not the deciding factor between them.
On Community there is no plan and no Studio. Your options are configuration, Properties fields on records such as contacts, leads and tasks, automation rules in developer mode, and modules. Our Community vs Enterprise comparison covers the wider trade-off.
Upgrades: who pays to carry each change forward
Odoo's upgrade documentation lists what its upgrade service covers: all standard apps; all customisations created with Studio, as long as Studio is still installed and the subscription is active; and developments covered by a maintenance of customisations subscription. It also says the service is limited to the technical conversion of the database.
Two consequences follow. First, uninstalling Studio to save money after the build is a false saving if you still depend on what it made, because that is the condition for upgrade cover. Second, custom modules sit outside the standard upgrade unless you buy that maintenance cover. Their source has to be ported to the target version before the database can be upgraded, and testing the result is yours either way.
How much porting costs depends on how a module touches standard code:
- Cheap to port: new models, new views, a few extra fields, a report.
- Moderate: overrides of standard methods such as invoice posting or stock moves, because the method you override may change.
- Expensive: copied-and-edited standard code, patches to core JavaScript, or modules that depend on other third-party modules that have to be ported first.
Studio is not free at upgrade time either. Its view changes are inherited views that point at elements of the standard screen, so a redesigned screen in a new version can leave a Studio change needing rework. Automation rules that use Execute Code are Python stored in the database, and Odoo will not rewrite them for you if the API they call changes. See our release cycle post for how often you will face this.
Price a customisation over the next two upgrades, not over the week it takes to build.
Version control, testing and environments
This is where the two differ most, and it is often underrated at the start of a project.
A Studio change takes effect the moment you save it. There is no diff to review, no record of why it was made beyond the chatter, and no automated test that fails when someone breaks it. Moving work from a staging copy to production means repeating it by hand, or using Studio's Export and Import, which packages your customisations as a generated module. That is a snapshot of data, not a history you can read.
A module in Git gives you the opposite. Every change has an author, a reason and a review. Tests run before deployment. Staging and production run the same commit, so what you tested is what goes live. On Odoo.sh, each branch becomes a build, with automated tests on development branches. Self-hosted, you get the same with any CI system.
The cost is speed and skill. A field that takes two minutes in Studio might take a developer an hour with review and deployment. For a handful of fields that is a poor trade. For a pricing rule that decides what customers are charged, it is cheap insurance.
Signs a Studio customisation should become a module
- An automation rule uses Execute Code, or several rules depend on running in a set order.
- A Studio app now needs to post journal entries, reserve stock or call another system.
- The same change has to exist in several databases and stay identical.
- Something broke and nobody can say who changed what, or when.
- An upgrade test showed Studio screens needing rework on most of the apps you use.
Moving a mature Studio customisation into a module is a project in its own right. The fields exist with data in them, so the module has to take them over without losing that data, and every rule has to be rebuilt and tested. It is cheaper to make the call early than after two years of Studio growth.
A decision process for each change request
- Ask whether standard Odoo already does it. A setting, a report filter or a different process often removes the request.
- Try Properties fields and plain automation rules. They need no Studio and no code.
- If you are on Enterprise and the change is a field, layout, report or simple rule, use Studio. Log it in a shared list with its owner and reason.
- If it touches money, stock, integrations or volume, write a module. Keep it in Git, with at least one test for the behaviour that matters.
- Before each upgrade, review the Studio list and the module list. Remove what nobody uses, and estimate the rest.
Integrations are almost always module work; our post on Odoo's API explains why a server-side method is usually needed. For a review of an existing mix of Studio and code, our implementation team can price it over your next upgrade.
Questions we get asked
Does Odoo Studio need the Custom plan?
On paid Odoo plans, yes. Odoo's pricing page says installing Studio automatically moves a database to the Custom plan. The exception is the free One App Free plan, where Studio can be chosen as the single app. Studio is an Enterprise app and is not available in Odoo Community, where customisation means configuration, Properties fields, automation rules or custom modules.
Are custom modules covered by Odoo's upgrade service?
Not by default. Odoo's upgrade documentation says the service covers standard apps, Studio customisations while Studio is installed and the subscription is active, and developments covered by a maintenance of customisations subscription. Other custom modules must have their code ported to the target version, by your team or a partner, before the database can be upgraded, and then tested on the upgraded copy.
Can Studio customisations be kept in Git?
Not in a useful way. Studio stores its changes in the database and applies them as soon as you save. Its Export option produces a generated module you could commit, but it is a snapshot of data rather than readable, reviewable code, and it has no tests. If you need history, code review and automated tests for a change, build it as a custom module in a Git repository.
Is Studio cheaper than a custom module?
To build, usually yes, because a trained functional user can make simple changes in minutes without a developer. Over time it depends on the change. Fields, layouts and simple rules stay cheap because Odoo's upgrade service carries them. Complex rules with embedded code, or Studio apps that grow into business logic, cost more to maintain than a module would, because nothing tests or documents them.