What a successful Odoo implementation decides before configuration.
Most implementations that go badly did not fail during the build. They failed earlier, when seven decisions were left implicit. Here is what to settle before anyone opens a configuration screen.
1. Define the operational problem
An ERP project usually starts with a symptom — orders re-entered twice, stock that disagrees with the storefront, a month-end that takes a week. The symptom is not the problem. Write down the operational outcome you want instead, in a sentence a non-technical manager would recognise, and the rest of the project has something to be measured against.
If that sentence cannot be written yet, discovery is the correct first engagement — not configuration. See how we approach discovery for what that stage produces.
Teams often arrive with a module list. A module list is an answer. Start from the workflow question it was meant to answer, and the list frequently changes.
2. Agree scope and ownership
Two questions decide more than any technical choice: what is explicitly out of scope, and who signs off each decision. Both belong in writing before build.
What to record
- The workflows in scope, named by what they do rather than by module
- Everything deliberately excluded, so its absence is a decision and not a surprise
- The named person who can approve a change on the client side
- Assumptions the plan depends on — each one a risk if it turns out false
3. Identify required integrations
Integrations are where implementations lose their schedule, because feasibility depends on a third party rather than on effort. List every system that must send or receive data, then confirm each one has a usable, documented API before it enters scope.
4. Decide what should remain standard
Every customisation is a permanent maintenance commitment. The test is not whether the standard behaviour is perfect, but whether the difference is worth carrying through future upgrades.
5. Define data migration responsibilities
Someone has to decide which records move, which are archived, and who cleans the ones that are wrong. That someone is almost always on the client side, and naming them early is what keeps migration from stalling.
No migration should be promised as zero-loss or zero-downtime before assessment. Volume, history depth and source quality decide what is actually achievable, and a test migration is what turns an estimate into a fact.
6. Establish testing and acceptance criteria
Acceptance written after a build is a negotiation. Written before it, it is a specification. Agree what "working" means per workflow, and who confirms it.
- Name the workflows that must pass, in business language
- Name the person who signs each one off
- Agree what happens when something fails — fix, defer or descope
- Record the result, so launch readiness is evidence rather than opinion
7. Plan training, launch and support
Training is per role, not per system. Launch is a sequence with a fallback, not a date. Support scope is written down, or it will be assumed — usually generously, by whoever needs it most.
Our own stage-by-stage approach to these decisions is set out on How We Work, and the implementation service itself is described under Odoo ERP Implementation.
Planning an Odoo implementation?
Bring the workflow and the systems you already run. We will work through the technical detail together.