The change is two lines. Every route to it runs through somebody's licence desk.
The requirement is never exotic. One extra field on the sales order. A rule that routes an approval differently above a threshold. A nightly job that flags the orders nobody has touched. What makes it slow is what surrounds it: you are told the change needs the platform's own builder, the builder is in a tier, the tier is priced per user across the whole system, and the change that comes out the other end lives inside a product you rent. So the estimate arrives before the change does, and two years later, when you leave, the change does not come with you.
What you get with customization
The way you change the system is the same way Odoo changes it. When you add a field, reroute an approval or schedule a nightly job, you extend what already ships rather than replacing it, the exact mechanism Odoo's own product is built on, so a change you commission sits in the codebase the way the vendor's own changes do: with an author, a review and a way back out. The if-this-then-that automation layer is in Community too, switched off in a fresh database and one install from live, not held behind a tier.
One thing is held behind the paid tier here, and it is worth naming plainly: Odoo's point-and-click builder, the drag-and-drop screen. Its code is withheld from Community, and it is the whole of what the tier holds back: a builder interface, not the ability to change the system.
We would rather tell you that on this page than at the second workshop. There is no drag-and-drop builder in what we deploy. Buying one means putting every backend user onto the Enterprise subscription, which is priced per user for the whole system and never per app. Our answer to customisation is not a cheaper builder, it is that the thing being customised is yours. The change lives in a codebase you keep, not inside a platform you rent, and that difference is the product.
What the licence lets you keep
This is the one legal claim on this site, so it is worth getting exactly right.
Odoo Community is open source, with no per-user fee. Its copyleft reaches Odoo's own core code: modify the core itself and the modified core has to be published under the same terms. It does not reach a separate module you write against it, that module is yours, it can stay closed, and it can be sold.
The free community add-ons are a different object, and the difference matters if you intend to build something you own. Their licence carries a network clause: running one is unrestricted, but modifying one obliges you to publish the source of your change to the people who connect to your system over the network. So a customer who wants sellable intellectual property writes a new module against the open-source core rather than forking a community add-on. That is a decision made at the moment the code is written, and it is one of the first conversations we would have with you.
What is the difference between ERP customization and configuration?
Configuration is changing how a system behaves using the settings it already ships with: turning a feature on, defining an approval threshold, adding a tax rule, setting up a template. The behaviour you get is one the vendor anticipated and supports, and it survives upgrades because the vendor is maintaining it. Customization is changing what the system does beyond what its settings allow, new fields, new logic, new documents, new integrations, which means new code or platform-specific scripting, written by someone, owned by someone, and maintained by someone through every subsequent release. The practical test is not how the change was made but who is responsible for it afterwards: a configured behaviour is the vendor's responsibility, a customized one is yours. This is why "can this be configured rather than customized" is worth asking of every requirement in a migration, and why the honest answer for a genuinely unusual business process is usually no.
Does customizing Odoo require the Enterprise edition?
No. Odoo's point-and-click customisation tool, Odoo Studio, is an Enterprise app: in the Community edition it ships only as a description with the code withheld, so it is not part of what we deploy. What is withheld is the builder interface, not the ability to change the system. The mechanisms underneath it are all in Community: view inheritance, which extends a screen rather than replacing it and which Odoo's own product already leans on heavily; server actions, which hold code; scheduled jobs; record-level access rules; and the automation-rules layer, which is in Community and simply switched off in a fresh database, one install from live. The distinction that matters when reading any comparison of the two editions is between a feature whose code is genuinely absent and one that is merely not yet turned on, because only the first tells you anything about what the licence costs.
If there is no drag-and-drop builder, how does a change actually get made?
It is written as a module, a self-contained package of code that extends the system without altering its core, and deployed like any other software change. In practice the change goes through the same route as the rest of an engineering organisation's work: it lives in a repository, it is reviewed, it is tested, it is deployed, and it can be reverted. That is slower than clicking a field into place, and it is more durable, because a change with an author, a commit and a review is a change someone can reconstruct in two years. The trade-off is real in both directions and worth stating plainly: point-and-click customisation is genuinely faster for small changes, and its cost is that the resulting behaviour is a configuration inside a vendor's tool rather than an artefact you hold. Which of the two matters more depends on how much of your business logic is unusual, and that is a question to answer before choosing a platform rather than after.
If I customize an open-source ERP, who owns the code?
You do, subject to the licence of whatever you built on, and for Odoo Community that licence is the LGPLv3, which was chosen specifically so that the answer is favourable. LGPL's copyleft reaches the library it covers: modify Odoo's own core code and the modified core must be published under the same terms. It does not reach a separate module written against it, so a module you commission is your property, may remain closed-source, and may be licensed or sold. The important qualification concerns modules published by the Odoo Community Association, which are generally licensed AGPL-3 rather than LGPL: AGPL adds a network clause, so running one is unrestricted, but modifying one obliges you to make the modified source available to people who use the system over a network. The consequence is a design decision rather than a legal risk, if the intention is proprietary, sellable software, it should be written as a new module against the LGPL core rather than as a fork of an AGPL one.
What happens to customizations during an ERP implementation or migration?
They generally do not travel, and this is one of the largest hidden costs in any ERP migration. Customizations written in a platform's own scripting language are expressions of that platform's data model and event system; they are not portable artefacts, and there is no export that turns them into something another system can run. What is portable is the intent, the rule the business actually needs, which means an implementation is the moment every customization has to be re-justified rather than re-implemented. Three questions do most of the work, and they are worth asking before the project starts rather than during it: what is each customization actually for, which ones are now covered by configuration in the new system, and which are genuinely unusual enough to rebuild. That is uncomfortable and it is also the only honest framing, because the alternative, promising like-for-like reproduction of an unspecified body of custom code, is a promise no one can keep.