How we implement Odoo: phases, timeline and checklist
Ten phases in four stages: design, build, proof and run. This page says what each phase produces, who signs it off, and what has to be true before a go-live date is agreed. It is the method Brainvire uses, written down so you can hold us to it.
Ten phases inside four stages — design, build, proof and run — each ending in a written output with a named owner on your side and ours. The same method runs for one company or a dozen; what changes is how often each phase repeats.
Not a template that ignores what you already run, and not a substitute for Odoo’s own manual. Odoo S.A. publishes the authoritative user and developer documentation; where a step depends on how Odoo behaves, we link to it rather than paraphrase it.
Small implementations run 8 to 12 weeks, mid-market 12 to 24 weeks, and multi-entity enterprise rollouts 6 to 12 months. A version upgrade on its own runs 3 to 8 weeks. Those are Brainvire’s planning bands, not figures published by Odoo.
An Odoo functional consultant, a solution architect, a data lead and a technical consultant. On your side: a sponsor who can settle a disagreement, a process owner per flow, a data owner per migrated object, and named testers.
/ What a method is for
What goes wrong when an Odoo project skips a phase?
Four failures, and none of them is a fault in the software. Each one is a phase that was skipped, or an output nobody was asked to sign.
Configuration starts before anyone maps the work
Requirements become whatever the person in the room remembers. The database fills with settings nobody can trace back to a decision, and no one can say why a field exists.
Standard or custom is settled mid-build
Each gap is answered by whoever hits it first, so custom code arrives unbudgeted and is discovered again, painfully, at the next Odoo version.
Migration is treated as a task, not a phase
Mapping starts weeks before go-live, the first load is also the real one, and the opening balances are argued about after users are already in the system.
The date is set before the testing is
Acceptance is compressed to protect a date, so the checks are marked green on the strength of a plan. The defects do not disappear; they move into the first month live.
Trusted by enterprise Odoo teams worldwide
/ The four stages in order
How does an Odoo implementation run from kickoff to go-live?
Four stages, a named owner at each, a written output before the next begins. The bands below are Brainvire’s planning figures, not numbers published by Odoo:
Design: map, fit-gap, architect
We document how each flow runs today, run it against a working Odoo database, and classify every difference as a process change, configuration, Studio or custom code. Company structure, edition and hosting are decided here — the stage Odoo consulting covers on its own.
Build: configure, extend, integrate
Configuration first, then Studio where there is no new logic, then custom modules only where the register said so. You walk your own flows at the end of every iteration.
Proof: migrate, test, train
Each object is imported at least twice and reconciled to the source. Your people run acceptance scripts on a neutralized copy, and training uses your own data, not demo records.
Run: cut over, hypercare, hand over
The cutover is rehearsed first, then run from a runbook naming the rollback point and the go or no-go owner. Hypercare keeps the build team on the system through the first period close, before ownership moves to support and managed services.
/ Phase by phase
What does each phase produce, and who signs it off?
Ten phases, ten written outputs. Each closes a question that otherwise gets answered mid-build by whoever is in the room. Nothing here is a slide deck, and nothing moves on until the named owner has signed what came before. Data is a phase of its own for a reason: every record we load carries an external identifier, so a rehearsal can be re-run without duplicating anything, and open orders and counted stock are always the last three loads.
| Phase | The written output | Who signs it off |
|---|---|---|
| 01 · Discovery | A current-state map of order-to-cash, procure-to-pay and record-to-report, with the manual workarounds marked | Signed off by your process owners |
| 02 · Fit-gap | Every difference from standard Odoo, classified as a process change, configuration, Studio or custom code, and owned | Signed off by your sponsor |
| 03 · Architecture | Company and database structure with the multi-company rules named, the edition, the hosting decision, and the phase-one app list | Signed off by your sponsor and IT owner |
| 04 · Configuration | A database you can open: chart of accounts in your reporting shape, fiscal positions, warehouse rules, approval limits | Signed off by the process owner for each flow |
| 05 · Extension | Studio changes and custom modules, each carrying the register line that justified it and what it costs to carry at the next version | Signed off by your sponsor |
| 06 · Integration | Each interface run against a test endpoint, with the failure path exercised as well as the happy path | Signed off by your IT owner |
| 07 · Data migration | A field mapping per object, two rehearsed loads through Odoo’s import tool, and a reconciliation to the source that finance has checked | Signed off by your data owner and finance |
| 08 · Testing | Acceptance scripts per role, run by your people on a neutralized copy, every defect fixed and re-tested rather than noted | Signed off by your named testers |
| 09 · Cutover | An hour-by-hour runbook naming every step, its owner, the rollback point, and who gives the go or no-go | Signed off by your sponsor |
| 10 · Hypercare | A defect log closed down, the first period closed with our team in the room, and a runbook written from your configuration | Signed off by your system owner |
Feature names follow the Odoo 18 documentation; the durations and delivery bands here are Brainvire’s own planning estimates. None of this runs on production: an Odoo.sh project has production, staging and development branch stages, and Odoo neutralizes every non-production database — outgoing email, planned actions, bank synchronization, payment providers and delivery methods are switched off, so a test cannot reach a customer. On your own servers we build the same three copies first; see Odoo hosting. Upgrading instead? Odoo’s upgrade service converts the standard database — see Odoo migration. Design without the build is Odoo consulting.
/ Responsibilities
Who does what during an Odoo implementation?
Three parties, and one thing all three share. Named here so nobody discovers a boundary in week nine.
The delivery team, and what it owns
An Odoo functional consultant, a solution architect, a data lead and a technical consultant. They own the process map, the fit-gap register, the configuration, the custom modules, the migration scripts and the cutover runbook — each handed over as a document you keep.
The four roles we ask you to name
A sponsor who can settle a disagreement, a process owner per flow, a data owner per migrated object, and testers who run acceptance on their own work. Projects stall when these four go unnamed, not when a team is small.
What the publisher does, and does not
Odoo publishes the product and the documentation, and its upgrade platform converts a standard database to a new version. Odoo states that additional modules built in-house or by partners, without a maintenance contract, are not covered. Porting those is our work, and we say so up front.
Testing, and the go or no-go
We write the acceptance scripts and fix what fails. You run them against how the business actually works and say whether the result is right. The date follows what that testing shows — the one part of the method we will not compress to hit a calendar.
/ Go-live readiness
What is on the go-live checklist?
Eight checks, and a date is agreed only once all eight are true. Each has an owner on your side, because a go-live only the implementer has signed is not a decision.
| Check | What done looks like | Who signs it off |
|---|---|---|
| Data | The final load rehearsed end to end and reconciled to the source, with opening balances agreed line by line | Finance and the data owner |
| Processes | Every phase-one flow run start to finish by the people who will run it in production | Process owner per flow |
| Access | The role and access model applied and tested: each user finishes their own work and reaches nothing else | Sponsor and IT owner |
| Integrations | Every interface run against a test endpoint, including what happens when the other system returns nothing | IT owner |
| Reports | Statutory and management reports produced from Odoo and compared line by line with the ones you produce today | Finance |
| Environments | Production separated from staging and development, and a restore actually performed rather than only scheduled | IT owner |
| Training | Named users trained on your own data, not demo records, with a one-page written reference per role | Process owner per flow |
| Cutover | The runbook rehearsed, the rollback point named, and one person named to give the go or no-go | Sponsor |
An amber check does not stop a program; it moves a date. The failure we see most often is the reverse — a date held fixed while checks are marked green on the strength of a plan rather than a test.
/ The method, on the record
Where has this method been used?
Three Brainvire programs, each testing a different part of the method: a rollout sequenced across many sites, a consolidation onto one system, and a platform decision taken before the build. More in the case study library.
700+sites targeted across 12 countries, going live on a rolling basisPuma Energy
A convenience-store network across 12 African markets standardized on one Odoo 18 ERP and POS core. The rollout was sequenced down a legal entity, dealer and site hierarchy, with two launch tracks — fast and full — so country-specific fiscal localization layered onto a common chart of accounts instead of each market becoming its own project.
Read the case →
CURE International
A non-profit hospital network was upgraded to Odoo 16 and consolidated onto one system: centralized inventory and purchasing across eight hospitals, automated stock records with user-based access, structured approval workflows, and custom label printing for drug dispensing where a country required it.
Read the case →
Fuel cell power manufacturer
The client was running Odoo SaaS version 14. Brainvire moved the system to Odoo.sh, then built on it: a central material shortage report, a SolidWorks integration so 3D design data feeds manufacturing, a customized work-in-progress account and an approval mechanism with rules per level. Architecture first, extension second, in that order.
Read the case →
/ Questions we are asked
Odoo implementation methodology FAQs.
What are the phases of an Odoo implementation?
Ten phases inside four stages. Design covers discovery, fit-gap and architecture. Build covers configuration and any custom modules. Proof covers data migration, testing and training. Run covers cutover, hypercare and the handover to a support team. Each phase ends in a written output with a named owner on your side and ours.
How long does an Odoo implementation take?
Brainvire plans small implementations at 8 to 12 weeks, mid-market at 12 to 24 weeks and multi-entity enterprise rollouts at 6 to 12 months. A version upgrade on its own runs 3 to 8 weeks. Those are our planning bands, not figures published by Odoo. Scope, data quality and how quickly decisions get made move them more than anything technical.
What happens in the first phase?
We sit with the people who run each flow and write down what actually happens today, including the steps that only exist in a spreadsheet. That current-state map is then run against a working Odoo database, and every difference is classified as a process change, configuration, Studio or custom code. Nothing is configured until that register is agreed.
Who from our team has to be involved?
A sponsor who can settle a disagreement, one process owner per flow, a data owner for each object that migrates, and the people who will run user acceptance testing on their own work. On our side, an Odoo functional consultant, a solution architect, a data lead and a technical consultant. Availability of your process owners is the usual constraint on a date.
How does our data get into Odoo?
Through Odoo's own import tool, from CSV or Excel files built out of your current system. Each object is imported at least twice before go-live: once to prove the mapping, once as a rehearsal against a cut-off. Records carry an external identifier so a re-run updates rather than duplicates, and finance reconciles balances to the source before anyone signs.
How do you test an Odoo implementation before go-live?
On a copy, not on production. Odoo neutralizes any non-production database, which switches off outgoing email, planned actions, bank synchronization, payment providers and delivery methods, so a test cannot reach a real customer. Your own people then run each phase-one process end to end, and what fails is fixed before a date is agreed.
Do you build on a staging environment?
Yes. On Odoo.sh a project has three branch stages, production, staging and development, so work is built on development, proved on a staging copy of real data, and only then merged to production. Where Odoo runs on your own infrastructure or on Odoo Online we set up the equivalent copies before configuration starts.
What happens on go-live day?
It is rehearsed first. The cutover runbook is written hour by hour, names who does each step, names the point at which we would roll back, and names the person who gives the go or no-go. The real cutover then runs in the quietest window your business has, with the final data load reconciled before users are let in.
What is hypercare, and how long does it last?
Hypercare is the period straight after go-live when the implementation team stays on the system: daily triage, fixes to configuration, and the first month-end closed with us in the room. Its length is agreed before cutover and written into the plan. We do not publish one number, because a single entity and a twelve-country rollout do not need the same cover.
Can you take over an Odoo implementation that has already started?
Yes, and it starts with an audit rather than a plan. We read the database, the custom modules, the integrations and the hosting, then write down what is standard Odoo, what is Studio, what is code and what is undocumented. Some of the existing configuration usually survives; some is reversed. The audit sets what any date can promise.
/ Next step
Have your implementation plan read by someone who has run one.
- A senior architect replies within one business day
- Your details are never shared or sold
- An NDA can be signed before we hear any detail
US +1 (631) 897-7276 · Gulf +971-54-737-4253 · Singapore +65-9086-0319 · India +91-22-6116-3300.
Trusted by 2,000+ brands worldwide
“Brainvire has helped our business grow. We feel like it’s a true partnership. They’re always present. It’s been seven great years, looking forward to more.”
Book a working session
Send us the plan, or tell us what you run today and what you want Odoo to take over.