The Four-Layer Odoo Architecture That Makes Upgrades Safe
Most Odoo implementations fail their first major upgrade. Everything was built in one layer, and upgrading Odoo means untangling every customisation from every other customisation.
Why Upgrades Break Traditional Implementations
In a monolithic Odoo implementation, custom models inherit directly from core models. Views override core XML templates. Automated actions reference internal field names. When Odoo SA changes any of these in a new version, the customisations break.
The Four Layers
L1: Odoo Core Platform. Never modified. Upgrades apply cleanly because nothing has been changed.
L2: Base Architecture Module. Custom models, security groups, API abstraction. Version-controlled and reusable. These reference L1 through defined interfaces, not internal implementation details.
L3: Implementation Module. Business-specific workflows and views. Isolated per engagement. Upgrading L1 or changing L2 does not break L3 because the dependencies flow in one direction.
L4: Client Configuration. Company settings, user permissions, email templates. Changes without code. No developer required.
How an Upgrade Works
- Upgrade L1 (Odoo Core) in the development environment
- Run the L2 test suite against the new version
- Fix any L2 compatibility issues (typically minimal)
- Validate L3 business logic against updated L2
- Deploy to staging, then production
The entire process is version-controlled and reproducible. No archaeology required.