Odoo Development · advanced · 14 min read
Maintaining Large Odoo Projects
Governance for multi-module Odoo estates: ownership, branching, dependency maps, technical debt triage, documentation, and sustaining teams after go-live.
Last reviewed 2026-07-30 · Estimated effort: 6+ weeks for multi-team change
Table of contents
Large Odoo projects fail slowly: module sprawl, unclear ownership, duplicate integrations, and upgrade fear. Maintenance is engineering governance — not only closing support tickets.
Treat custom addons as a product portfolio: each module has an owner, manifest purpose, dependency diagram, test suite, and debt register entry. Releases ride a train — batch -u and QA — not random hotfixes.
Business continuity overlaps support AMC and the Customization pillar for partner selection; this article focuses on how internal and partner devs keep a big codebase comprehensible years after go-live.
Go-live is day one of the expensive part. Estates with dozens of modules, three integrations, and Studio layers need conventions strangers can follow six months later.
These practices come from sustained programmes — migrations, retail ops, manufacturing — where upgrade and feature work happen in parallel without freezing the business.
Maintain a module catalog spreadsheet or YAML: technical name, business owner, dev owner, depends, last -u date, test coverage note, criticality. No orphan modules without a named maintainer.
Split mega-modules when boundaries clarify — kitech_sale vs kitech_sale_reporting — rather than one 15k-line addon nobody wants to touch.
- ▸CODEOWNERS file in Git for review routing
- ▸Deprecate modules explicitly — uninstall path and data migration
- ▸Flag third-party OCA vs in-house vs Studio-exported
Monorepo for all custom addons is common; tag releases matching prod deploy. Long-lived project branches per Odoo version (17.0) reduce accidental 16.x imports.
Protect main: PR, CI green, one reviewer minimum. Hotfix branch from prod tag, cherry-pick to main — not direct prod commits lost from trunk.
Diagram which modules touch sale, stock, account, and external APIs. Integration mapping tables and cron schedules belong in runbooks support can read.
When two modules override the same method, document order via depends or merge into one override — mysterious super() chains cause upgrade pain.
Log debt items: forked view, sudo hack, missing ACL, untested cron, duplicate Shopify sync. Prioritize by risk × upgrade exposure — not only loudest user complaint.
Budget 15–25% sprint capacity for debt and test improvement on mature estates — prevents freeze before next major version.
New developers need half-day architecture walkthrough: addons_path, top ten modules, deploy runbook, staging access. Pair on first -u and first integration debug.
AMC with partner augments internal team — specify SLAs for prod incidents vs backlog features. Handover docs beat tribal knowledge when staff turnover hits.
- ✓Quarterly dependency and manifest audit — remove unused depends.
- ✓Run cloc or similar to find dead modules with zero prod traffic.
- ✓Standardize logging prefix per module for grep-friendly support.
- ✓Align upgrade rehearsal calendar with Odoo release cadence.
- ✓Keep architecture decision records for big forks (why parallel model).
- ✓Sync functional docs when XML menu or workflow changes — devs are not sole owners.
- !Every vendor adds modules with no naming convention — collision city.
- !Studio and Git both modify same view — priority roulette.
- !No prod module list — staging missing addon for months.
- !Hero developer only person who can deploy — bus factor 1.
- !Feature freeze forever because upgrade project never scheduled.
- !Support tickets patch prod via shell without Git backport.
Large Odoo programmes stay healthy when modules have owners, maps, tests, and scheduled upgrades — not when heroes remember where bodies are buried.
Start with one module catalog and one staging upgrade rehearsal; the compound effect beats big-bang documentation projects.
Core modules
Stable APIs
Industry modules
Vertical logic
Integration glue
Connectors
UI extensions
Views & wizards
- coreind
- coreglue
- indui
Client / Channel
Users & devices
Odoo Application
Business logic
PostgreSQL
System of record
Workers / Cron
Async work
- clientapp(HTTP)
- appdb(ORM)
- appjobs(queue)
Configure and train
Odoo covers ≥80% of the process
Custom module
Competitive advantage depends on it
Integrate
Another system owns the data
Defer / pilot
Scope is speculative
Frequently asked questions
How many modules is too many?
No fixed cap — pain comes from unclear boundaries and untested depends. Ten well-owned modules beat three monoliths with hidden coupling.
Should we split by department or layer?
Prefer bounded context (sales approval, WMS bridge) over horizontal layers (all views module) — Odoo loads by business dependency anyway.
When to refactor vs rewrite module?
Refactor when inheritance and tests exist. Rewrite parallel model only when business agrees data migration cost — see upgrade-friendly patterns first.
How does AMC differ from dedicated dev?
AMC sustains and fixes; dedicated capacity builds backlog. Large estates often need both — governance in this article applies to either model.
Related articles
Writing Upgrade-Friendly Code
Engineering patterns that survive Odoo version upgrades: inheritance over fork, xpath stability, migration scripts, noupdate data, and avoiding private API coupling.
View →Deployment Best Practices
Shipping Odoo modules safely: staging parity, -u vs -i, backups, zero-downtime limits, workers, logging, and rollback playbooks for on-prem and Odoo.sh.
View →Security: Groups and Record Rules
Odoo access rights: ir.model.access.csv, security groups, record rules, field-level restrictions, and multi-company patterns that enforce server-side.
View →Testing Odoo Modules
Automated testing for Odoo addons: TransactionCase, SavepointCase, test tags, mocking RPC, view loading checks, and CI patterns for Odoo 16/17.
View →Inherited a sprawling Odoo codebase?
We audit modules, draw dependency maps, and establish release trains so your team can ship without fear.
