At some point you inherit a system. A client moves to you, a previous team is gone, a project changes hands. You are now responsible for an Odoo deployment you did not build, and soon someone will ask you to change it. The first week decides whether that change is informed or reckless. This playbook is how we spend it. The governing rule: understand before you touch.
Day 1: Establish the ground truth
Before reading any code, establish what is actually running.
- What Odoo version, what edition, on what hosting.
- The exact list of installed modules on production, not the repository's contents.
- Where the code lives, whether all of it is in version control, and whether production matches the repository. Production drifting from the repository is common, and it is the first thing to know.
- Where backups are, how recent they are, and whether anyone has ever tested a restore.
Day 2: Map the custom modules
Read every custom module's manifest first, then its models. You are building a map, not auditing yet. For each module, write one sentence: what it does. Note which models it adds and which it extends. By the end of the day you should be able to describe the customisation layer to someone else. If a module resists a one-sentence description, that is itself a finding.
Day 3: Trace the critical business flows
Pick the two or three flows the business actually runs on: order to cash, the core operational process, month-end. Follow each one through the system, from the action that starts it to the records it ends with. This is how you learn which customisations are load-bearing. A module nobody can explain that sits in the middle of order to cash is a very different risk from one that sits off to the side.
Day 4: Find the workarounds and the silence
Talk to the people who use the system daily. Ask one question: where do you not trust it, and what do you do instead. Every spreadsheet kept alongside Odoo, every manual re-check, every "we just know to do this" is evidence about where the system does not fit. Separately, check what is not instrumented: is there logging, are there alerts, would anyone know if a scheduled job stopped. Silence is a risk you inherit too.
Day 5: Write the inheritance memo
End the week with a short written memo, for yourself and the client:
- What the system is: version, modules, hosting, the shape of the customisation layer.
- What is load-bearing: the customisations the critical flows depend on.
- What is unexplained: modules or logic nobody could account for. Not yet problems, but not yet safe either.
- What is fragile: no tested backups, no staging, no monitoring, drift between repository and production.
The memo is the deliverable. It converts a week of reading into a shared, written understanding.
The note for the file
The pressure when you inherit a system is to prove value fast by changing something. Resist it for a week. The first change you make is the moment you take ownership of the system's behaviour. Spend five days earning the right to make it, and every change after that is informed instead of hopeful.