Customising an ERP without getting stuck on the next version

“Can we do it like before?” is the most expensive question in an ERP project. Technically, almost anything can be developed. But every development adds to the bill of every upgrade, and an over-customised ERP ends up frozen on an old version.

Level 1: adapt the process

The gap between your way of working and the software standard has two possible origins: a real business rule, or a habit. A habit can change. The standard of an ERP like Odoo or Dolibarr reflects the practice of thousands of companies; aligning with it costs training, not development. Scoping does this sorting, and the requirements document notes for each rule whether it is legal, contractual or simply habitual.

Level 2: configure

Without writing code, an ERP can be tuned a lot: extra fields, value lists, validation rules, process stages, quote and invoice templates, filtered reports. On Odoo, the Studio app, reserved for Enterprise, takes this configuration far: forms, views, simple automations.

Studio has one limit worth knowing: what it creates lives in the database and follows the publisher’s upgrades, but an accumulation of undocumented rules becomes hard to understand. The same discipline applies: every addition has a written reason.

Level 3: develop

Some rules justify a development: a business-specific price calculation, an integration without a connector, a specific regulatory document. In that case:

1. 01An isolated module

   Never modify the publisher’s code.

2. 02Short

   The business rule, nothing else.

3. 03Tested

   Automatic tests that tell whether the upgrade broke it.

4. 04Documented

   Why it exists, who asked for it, what it does.

Odoo’s developer documentation describes this module-based organisation. Dolibarr follows the same logic with its external modules.

The real cost of a development

A development costs three times: when it is written, at every version upgrade, and every time a new person has to understand it. Odoo releases a major version a year; a custom module must be checked, often adapted, at every step. Over five years, this maintenance cost often exceeds the writing cost.

Before approving a development, ask: does what it saves each year cover its maintenance? If the answer is uncertain, stay at level 2.

Community modules

OCA modules for Odoo or DoliStore modules for Dolibarr cover many needs without development. They have one advantage, shared maintenance, and one risk, an author who stops following versions. Check that a module is maintained on recent versions before adopting it, and keep their number limited.

The sign you have gone too far

A version upgrade postponed year after year because it “would break too much”. It is the symptom described in Why ERP projects fail. The way out is an inventory of developments, removing those no longer used, and replacing those the standard now covers.

A rule to write during scoping

The best moment to set the three-level rule is scoping, before the first workshop. Written into the requirements, it gives everyone the same reflex: when a request comes in, look first in the standard, then in configuration, and develop only with a written reason and a quantified gain. Workshops get shorter, and the list of developments stays readable. The complete ERP guide places this rule in the whole project. In our CRM and ERP offer, every proposed development is justified in writing and priced, maintenance included.

Frequently asked questions

Sources

1. Odoo developer documentation (new tab)odoo.com