OT
Odooers Team 10 min read • Technical Deep Dive

The problem? They'd built their Odoo customizations in Studio—because that's what Odoo sold them on. "No-code customization." Easy. Fast. Anyone can do it.

Here's what actually happened.

Their dev builds wouldn't run. Every single time they spun up a development instance, it crashed. Studio field missing a description. Studio calculation failing on empty data. Studio conflict with a module update. Pick your poison—there was a new error every week.

So they couldn't use dev instances. Which meant they had to run everything through staging environments instead. Which meant higher Odoo.sh costs. Which meant slower development cycles. Which meant their "quick and easy" Studio customizations were now costing them thousands in infrastructure just to work around.

Then came the upgrade.

We had to delete the Studio fields entirely and rebuild them as proper custom modules. Not migrate—delete and rebuild. Hours of work reverse-engineering what someone had clicked together in a GUI, figuring out what it was actually supposed to do, and recreating it in code that wouldn't explode on contact with Odoo's upgrade scripts.

This wasn't an edge case. This is what Studio does.

And the wildest part? Odoo's own support team tells people not to use it.

What Odoo's Support Team Actually Says About Studio

I'm not being hyperbolic. This is a documented response from Odoo's support team to a customer experiencing Studio-related crashes:

"To avoid this issue, avoid using Studio during strong activity hours...use custom Odoo.SH code to add fields rather than using Studio."

Read that again. Odoo's own support team is telling customers to use code instead of their own Studio product.

When a vendor's support team recommends against using their own module, you should listen.

How Studio Corrupts Your Registry (And Crashes Your Server)

Here's the technical reality that the "no-code" marketing doesn't mention.

When you add a field or modify a view in Studio, that change doesn't live in a version-controlled code file like normal Odoo customizations. It lives in your database—scattered across tables like ir.model.data, ir.model.fields, and ir.ui.view.

This means Studio changes bypass Odoo's normal module loading process. And when you make Studio changes while other users are working on the same model? The Odoo forums document what happens:

"Sometimes corrupts the registry, which blocks the access to the records, which ends up corrupting the whole process of retrieving data from the database, thus making the instance inaccessible."

Your whole system goes down. Not a single form. Not one module. The entire instance becomes inaccessible.

Odoo's support confirmed this is a "known issue on Odoo.SH."

Known. Issue.

If you've seen errors like these, you've already experienced this:

ERROR database odoo.modules.loading: Some modules have inconsistent states, 
some dependencies may be missing: ['studio_customization']
Module loading web_studio failed: file web_studio/security/ir.model.access.csv 
could not be processed

These aren't obscure bugs. They're predictable consequences of Studio's architecture.

Your Dev Builds Are Probably Broken Right Now

This is what killed my UK client's workflow, and it might be killing yours too.

Odoo.sh has a specific way of handling development branches. You create a branch, it spins up a fresh instance with demo data, you develop and test, you merge. Clean and simple.

Except Studio customizations don't exist in your code repository. They exist in your production database. So when Odoo.sh creates a dev instance, those x_studio_ fields aren't there. Your development environment doesn't match production. Tests fail. Modules that depend on Studio fields crash on load.

Developers trying to make this work report the same thing over and over:

"When Odoo.sh is running tests, I can see that customizations are recognized but it seems that not all models are loaded. Usually I end up with failures like certain model or field is not defined."

So you have two choices:

  1. Restore production data into every dev branch — Slower, more expensive, and you're now developing against real customer data (hello, GDPR concerns)
  2. Abandon dev branches entirely and work in staging — Which is what my UK client was forced to do, at significant extra cost

Neither option is acceptable. Both are inevitable with Studio.

The Upgrade Will Cost You $20,000 to $100,000

Odoo releases a major version every year. If you're on a supported version, you need to upgrade regularly. And here's where Studio goes from "annoying" to "financially devastating."

Odoo's migration platform tries to migrate Studio customizations. But as Dutch partner Odoo Experts explains:

"Because each user of Odoo can make their own unique customizations, it is impossible for the migration platform to migrate everything correctly. So you see that multiple Studio customizations cannot be migrated and must be recreated after migration."

That's not "some edge cases fail." That's "expect to rebuild your customizations every single upgrade."

Real numbers from the industry:

  • Odoo migrations typically cost $20,000 to $100,000+ for medium businesses
  • Heavy customization (read: Studio) is the primary cost driver
  • One documented case: $15,000 spent and 170+ hours invested over 16 months without achieving a working system

Odoo's own documentation acknowledges this. They warn developers to "avoid changes and wrong configurations that might be present in the production database (like studio customization)" because they "can raise unwanted issues in this stage of the upgrade process."

Their solution? Problematic Studio views get silently disabled during upgrades. You don't get a warning. You just discover later that half your customizations are gone.

The Math That Should Make You Angry

Let's do the Odoo Studio value calculation that nobody at Odoo wants you to do.

What you're paying:

  • Studio requires Enterprise Custom Plan: ~$37/user/month
  • Standard Enterprise (no Studio): ~$31/user/month
  • Studio premium: $6/user/month

For a 50-user company:

  • Studio licensing premium: $3,600/year
  • Over 5 years: $18,000 just for access to Studio

What Studio actually costs:

  • Upgrade migration every 2-3 years: $20,000-$100,000
  • Lost dev productivity from broken builds: ???
  • Extra staging environments: $500-2,000/month
  • Emergency fixes when registry corrupts: $5,000-15,000 per incident

What custom module development costs:

  • Building the same functionality in code: Often less than one upgrade migration
  • Future upgrades: Dramatically simpler because code follows Odoo's upgrade patterns
  • You own the code. Forever. Even if you leave Odoo Enterprise.

Studio isn't saving you money. It's deferring costs until they're 10x larger and someone else's emergency.

When Studio Is Actually Fine

I'm not dogmatic about this. There are exactly three situations where Studio makes sense:

1. Prototyping in test environments

You want to quickly mock up what a customization might look like before committing to code? Studio is great for that. Click around, show stakeholders, get buy-in. Then delete it and build it properly.

2. PDF template customization

This is genuinely Studio's strength. The report designer is solid, and PDF templates don't carry the same upgrade risk as field and logic customizations.

3. Minor UI tweaks you'll never upgrade

Hiding a field, making something required, changing visibility rules—if you're certain you'll never upgrade this instance and the change is purely cosmetic, Studio probably won't hurt you.

Everything else? Build a module.

What You Should Do Instead

The alternative to Studio isn't "hire expensive developers for everything." It's "build customizations that won't destroy your system."

Here's what sustainable Odoo customization looks like:

Modular organization: Different functionality lives in different modules. CRM enhancements go in crm_enhance. Sales modifications go in sale_enhance. Each module can be tested, version-controlled, and upgraded independently.

Version control: Your customizations live in Git. You can see who changed what, when, and why. You can roll back. You can branch. You can review.

Automated testing: Odoo has a testing framework. Custom modules can have tests. Studio customizations cannot be tested—at all.

Predictable upgrades: Code-based customizations follow Odoo's documented upgrade patterns. Partners and developers know how to migrate them. The process is boring, which is exactly what you want.

This isn't theoretical. It's how every serious Odoo implementation is built.

Already Stuck With Studio? Here's Your Path Out

If you're reading this with a sinking feeling because you recognize your own system, you're not alone. I've migrated more companies off Studio than I can count.

The process isn't magic:

  1. Export and audit your Studio customizations
  2. Identify what's actually needed vs. what was experimental
  3. Rebuild critical functionality as proper modules
  4. Migrate your data (field names and types can often stay the same)
  5. Remove Studio dependencies

It takes time. It takes expertise. But it's dramatically cheaper than your next failed upgrade.

Let's Find Out How Bad It Is

Here's my offer: a free 30-minute diagnostic call.

We'll look at your Odoo setup, I'll tell you honestly what you're dealing with, and you'll get a clear picture of your Studio risk. No pitch, no pressure. If you don't have a problem, I'll tell you that too.

After the call, I'll send you a short report with what I found and my recommendations. If you want help fixing it, we can talk about that. If you want to handle it yourself or take it to another partner, the report is yours to use however you want.

Book Your Free Studio Diagnostic →