Odoo appeals to many businesses for a good reason. It brings sales, inventory, accounting, manufacturing, eCommerce and more into one system, and it is flexible enough to adapt to very different processes. That flexibility is also its main trap. Because almost anything can be changed, it is tempting to change almost everything, and companies often end up with an Odoo system so modified that nobody dares to upgrade it.
The skill in a good Odoo project is not knowing how to customise. It is knowing when not to. This article gives you a practical way to decide between configuring, customising and leaving things alone, explains how to keep your system upgrade-friendly, and covers how to choose the people who will work on it. If you need hands-on help, see our page on how to hire Odoo developers.
The three levels of change
Think of Odoo adjustments as three levels, from cheapest and safest to most expensive and risky.
Level 1: Configuration. Changing settings, enabling features, editing templates and using the options Odoo already provides. No code is written.
Level 2: Light customisation. Small additions through Odoo's own tools: custom fields, automated actions, simple views and report adjustments. Little or no programming.
Level 3: Custom development. New modules or significant changes written in code, such as new business logic, integrations or entirely new applications.
The golden rule: use the lowest level that solves the problem. Every step up adds cost now and maintenance later.
Level 1: Configuration first
Odoo ships with a great deal of capability, and many businesses use a fraction of it. Before any code is written, check whether the feature already exists. Common examples include:
- Pricing rules, discounts and pricelists in sales
- Reordering rules and multi-step routes in inventory
- Approval workflows on purchases
- Email templates and document layouts
- Access rights and user groups
- Taxes, fiscal positions and payment terms in accounting
It is surprisingly common for a "custom requirement" to turn out to be a setting nobody noticed. A short review of your process against Odoo's standard features, by someone who knows them well, often removes half the customisation list.
Configuration also has a hidden benefit: it is preserved through upgrades far more reliably than code.
Level 2: Light customisation
When configuration cannot reach, small additions often can. Typical examples:
- Custom fields on products, customers or orders to capture information unique to you
- Automated actions that send reminders, assign tasks or update records when something happens
- Custom reports and print layouts for quotations, invoices and delivery notes
- Adjusted views to hide clutter and show what your team uses
These changes are small, contained and usually easy to carry forward through upgrades. They often deliver most of the value of a customisation project at a small fraction of the cost.
Level 3: Custom development
Custom modules are appropriate when the need is real and cannot be met otherwise. Good reasons include:
- A business rule that is central to how you earn money and not supported by Odoo
- Integration with another system, such as a payment provider, shipping service or mobile app
- A workflow that spans several modules in a way the standard features cannot handle
- A genuinely new application for something specific to your industry
- Performance or reporting needs that go beyond the standard tools
When you do build, it should be done carefully. The most important principles:
- Never modify core code. Changes to Odoo's own files make every upgrade a fight. Instead, extend through separate modules that follow Odoo's inheritance system.
- Keep modules small and focused. One module should do one job and be easy to understand.
- Follow Odoo conventions. Standard structure, naming and patterns make modules readable by any experienced Odoo developer.
- Document what and why. Notes on what each module does and the business reason behind it save hours later.
- Write tests for critical logic. Especially for accounting, stock and pricing rules.
What to leave alone
Some parts of Odoo are better left as they are, even when it is possible to change them.
- Core accounting logic. Mistakes here affect your financial records and audit trail. Adapt through configuration and reports wherever possible, and involve your accountant in any change.
- Stock valuation and costing mechanics. Small changes can cascade through inventory values.
- Standard workflows that already fit. If 80 percent works, adapt your process slightly instead of rewriting the system.
- Anything you cannot explain the purpose of. If nobody can say why a change is needed, it probably is not.
A useful question to ask at every decision point is: "If we did this the standard way, what would actually go wrong?" Often the answer is "a bit of inconvenience", which is cheaper than permanent customisation.
The cost of over-customising
Heavy customisation looks attractive during the project and painful for years afterwards.
| Problem | What happens |
|---|---|
| Difficult upgrades | Each new Odoo version requires rewriting and retesting custom code, often at high cost |
| Stuck on old versions | Businesses delay upgrades, then fall behind on features, fixes and security |
| Developer dependence | Only the original developer understands the system |
| Fragile system | Changes in one place break others unexpectedly |
| Higher support cost | Every issue takes longer to diagnose |
| Slower new features | Standard improvements in Odoo cannot be adopted easily |
The aim is an Odoo that stays close to standard, with small, well-documented additions that can be carried through upgrades without drama.
Planning for upgrades from day one
Odoo releases new major versions regularly, and each brings improvements and security updates. Plan for that from the start.
- Keep a list of all customisations. What each one does, why it exists and who owns it.
- Prefer standard solutions. They upgrade automatically with the platform.
- Test upgrades on a copy. Never upgrade a live system first.
- Budget for upgrade work. Custom modules will need attention with each major version.
- Review customisations periodically. Remove those that are no longer needed, or that newer standard features now replace.
A customisation that is cheap to build but expensive to carry is not cheap.
Common customisation areas, and our advice
Sales and CRM. Start with pipeline stages, pricelists and quotation templates. Custom approval rules and layouts are usually light changes. Heavy rewrites of the sales process deserve a second opinion.
Inventory and purchasing. Use routes, reordering rules and barcode features before considering custom development. Warehouse-specific flows are a good reason for custom modules, but keep stock valuation standard.
Accounting. Configure taxes and localisation first. Add custom reports and exports for local requirements. Be very conservative about changing how entries are created.
Manufacturing. Bills of materials, work orders and quality checks cover a great deal. Custom work usually centres on shop-floor screens or integrations with machines.
eCommerce and website. Odoo's website tools can handle a lot. Custom checkout steps, product configurators and integrations are common additions, but keep storefront changes modular. For broader thinking on online stores, see our eCommerce website cost guide.
Integrations. Payment, shipping, marketplace and mobile app connections are well-suited to custom modules, built through Odoo's external APIs or connectors.
Migration from older versions or other systems
Many Odoo projects are really migration projects: moving from an old Odoo version, from another ERP or from spreadsheets. A careful approach looks like this.
- Audit the current system. What data exists, what is in use, what is obsolete.
- Clean before moving. Duplicates and outdated records are cheaper to remove before migration.
- Decide what to replace with standard features. Old customisations are often unnecessary in newer versions.
- Migrate in a test copy first. Compare totals, balances and sample records.
- Plan the cutover. Choose a quiet period, and define how to handle transactions during the switch.
- Train your team. Adoption decides success more than technology.
Migration is also the best time to remove customisation you do not need.
Is Odoo the right choice at all?
Sometimes the honest answer is no. Odoo works very well for businesses whose processes fit a modular ERP. It may be less suitable if your core workflow is highly unique, if you need a custom customer-facing product or if you need only one narrow function. In those cases a purpose-built system may fit better.
Our article on custom software vs off-the-shelf sets out a framework for that decision, and our custom software development page describes when we recommend building instead. We are happy to say when Odoo is the better path, and when it is not.
Choosing an Odoo developer or partner
Good Odoo work depends heavily on the people. Look for these signs.
- They ask about your process first. Before proposing modules, they want to understand how you work.
- They propose configuration before code. A developer who reaches for code immediately is costing you money.
- They never touch core code. Ask directly.
- They document and test. Customisations should be explained and verified.
- They plan for upgrades. They can describe how their work survives a version change.
- They work on a copy first. No changes to your live data without testing.
- They are honest about fit. They tell you when Odoo is not right.
Our guide to choosing a software development company offers further questions that apply to any technical partner.
Managing a customisation project
A sensible sequence for a change project looks like this.
- Map the process. Write down how the work is done today and what should improve.
- Compare with standard Odoo. Identify what already works, what needs configuration and what truly needs code.
- Prioritise. Rank the gaps by business value. Start with the top few.
- Build in stages. Deliver small pieces, test with real users and learn.
- Train and support. People must understand changes for them to succeed.
- Review later. After a few months, see what is used and what is not.
This mirrors the staged approach we recommend for any software project, which we explain in what is an MVP. Start with the core of what matters, then build outward.
A checklist before approving any customisation
- What problem does this solve, and how often does it occur?
- Could a setting, a custom field or an automated action solve it instead?
- What would happen if we did it the standard way?
- Who will maintain this, and how will it be documented?
- How will it be affected by the next Odoo upgrade?
- What is the total cost, including future upgrades?
- How will we test it before it touches live data?
If you cannot answer these, pause the request.
Final thoughts
The best Odoo systems are not the most customised ones. They are the ones where standard features were used wherever possible, where custom work is small, focused and documented, and where the team can upgrade without fear. Configure first, customise only when you must, and leave alone what already works.
If you would like a second opinion on an Odoo project, whether planning, migration or rescuing a heavily modified system, get in touch. We will review your setup and tell you plainly what to configure, what to customise and what to leave as it is.