Every buyer asks for a week-by-week plan and most vendors invent one. The honest version is that an Odoo project has six phases and three published time bands, and the calendar is set by six deliverables rather than by six week numbers. Which week you are in matters less than which deliverable is signed.
Here is what we publish, and it is the same on our pricing page: single-module Starter projects run 3-4 weeks. Multi-module Growth projects run 8-12 weeks. Enterprise multi-country rollouts run 4-9 months with phased go-lives. That last band is the scope-based tier, not the Odoo edition.
Inside every one of those bands, the same six phases run in the same order.
The six phases and what closes each one
| Phase | What you hold at the end | The gate |
|---|---|---|
| Discovery and process mapping | A written process map, a numbered gap list, and the module list that follows from it | Every gap has a number against it |
| Solution design and gap resolution | A signed scope where every gap has a disposition and a cost | Scope signed before build starts |
| Configuration and prototype | A prototype database your team can click through, plus a defect and change log | Pilot transactions run end to end |
| Data migration and reconciliation | A signed reconciliation pack showing each control total in both systems | Control totals agree in both systems |
| Training, UAT and cutover | A completed UAT sign-off, the cutover runbook, and a live system | Go or no-go called against criteria |
| Hypercare and handover | Documentation, a trained administrator, and either a support contract or a clean exit | Administrator can run it without us |
Read that table as the schedule. If a phase has not produced its deliverable, the project is not in the next phase, whatever the plan on the wall says.
Phase 1: discovery and process mapping
The goal is to get the current process on paper and decide which parts of it deserve to survive. That means walkthrough sessions per function: sales, purchasing, warehouse, finance, HR, whichever are in scope. It means recording the exceptions, not the happy path, because the happy path is never what breaks a rollout. It means listing every report someone actually reads, and who reads it. Where there is a physical operation, it means walking it: the warehouse, the shop floor, the counter.
One output decides more of the budget than anything else in the project: identifying the numbers the business is managed by, because those decide the chart of accounts and the analytic structure.
This is also the phase where the go-live date gets chosen against your operating calendar, while it is still cheap to move.
Phase 2: solution design and gap resolution
Every gap from discovery gets one of four dispositions: configure, customise, change the process, or leave out of scope. Custom items are estimated individually so they can be cut individually. The chart of accounts, the numbering conventions and the product coding scheme get agreed, in that order. User roles and record-level access are defined before any user is created. The integration boundary is fixed: which system is master for customers, for stock, for prices.
The deliverable is a signed scope where every gap has a disposition and a cost. That document is the contract. Requests raised after it are quoted as change requests, which is the only honest way to keep a fixed price fixed. The same discipline is set out at more length in how to scope an Odoo project.
Phase 3: configuration and prototype
Now the software gets touched. The company, warehouse, journal and pricing structure get built. A representative slice of masters gets loaded, and the word that matters is representative: your awkward products, not your simple ones. Pilot transactions run end to end, from order through to the ledger entry. There is a weekly demo against the process map, with the gap list as the checklist.
Custom work starts here, against a system that already runs the standard flow. That ordering is deliberate. Requests raised on day one are usually descriptions of the old system, and a real share of the original custom list gets withdrawn without argument once people have run the standard behaviour first.
Phase 4: data migration and reconciliation
Extract from the legacy system, then clean and de-duplicate before loading, never after. Map every legacy field to a target field in writing, including the ones you decide to drop. Load in dependency order: partners, products, then balances, then open documents. Reconcile control totals against the old system and sign them off with whoever closes your books. Agree a cut-off date and freeze changes in the legacy system from that point.
This phase runs long more often than any other, and almost never for a technical reason. It runs long because the meaning of a legacy column is rarely written down anywhere, and finding the person who knows takes days. A repeatable import that logs its own errors, such as Import / Export Power Tools, keeps the midnight spreadsheet off the critical path. It does not remove the cleaning.
Phase 5: training, UAT and cutover
Role-based training runs on your configured system with your data, not on a generic instance. User acceptance testing is scripted and run by the people who will use the system daily, including the ones who were sceptical about the change, because the project team knows the intended path and will not find the problems. Defects get triaged into blockers, fix-before-go-live, and phase two. The cutover runbook is written with timings, owners and a rollback point. Then a go or no-go call against agreed criteria, not against the calendar.
The published bands assume this phase gets real user time, blocked out in calendars in advance. When it does not, the date moves. There is no third option. Our training service exists because this is the phase teams most often try to absorb internally and most often underestimate.
Phase 6: hypercare and handover
Daily triage in the first weeks, tapering as volume settles. Configuration issues that only appear under real load get fixed. The reports people actually opened get tuned, and the ones nobody opened get retired. Administrator handover covers users, access, backups and scheduled actions. A written phase two backlog is built from everything deferred during UAT.
The published bands include one month of hypercare on the smaller projects and three months on the larger ones. One more scheduling point: refresher sessions belong after the first period close, when the questions are real ones, not at go-live when nobody has met month-end yet.
What the bands actually compress
A 3-4 week single-module project does not skip phases. It shortens them, because there are fewer functions to walk, fewer gaps to disposition, and a smaller legacy footprint to reconcile. What it cannot skip is the signed scope and the reconciliation pack. Those two documents are what make a short project short rather than a fast start followed by a long tail.
An 8-12 week multi-module rollout adds custom modules and reports, more functions in discovery, and a data migration with more dependency layers. It also adds the thing that most often surprises buyers: reporting. Reporting is where scope quietly doubles, so the short list the business genuinely cannot close a month without becomes a condition of go-live and the rest becomes phase two.
The 4-9 month band exists because multi-country and multi-company programmes go live in phases. You pay for a bridge period where two systems are both partly true. That is a real cost, and it buys a first go-live small enough to succeed. Where you trade also lands local requirements on the critical path. A market running a clearance model, such as Saudi Arabia, puts an outside systemโs validation response inside your order-to-cash before you can call anything live.
The two dates to fix first
Fix the cut-off date, when the legacy system stops accepting changes. Fix the go-live date, chosen against your period close and your peak weeks. Everything else in the plan is derived from those two, and both are cheapest to choose in phase one.
Two hard things at once turns a normal defect into a crisis. A go-live on a period close or in a peak trading week is the most avoidable scheduling mistake in this kind of project.
What actually moves the timeline
Not the configuration. Configuring Odoo is finite work and well understood. The variable is how quickly decisions get made and how clean the legacy data is.
So the two things that shorten your project sit on your side of the table: a named decision maker per function with authority to change a process rather than just describe it, and a legacy extract with somebody attached who can explain what the odd columns mean. Without authority in the room, every gap becomes another meeting and the timeline drifts by weeks with nobody doing anything wrong.
The full engagement structure, including what we exclude in writing, is on the Odoo implementation service page. If you are upgrading rather than implementing, the shape is different and it is set out under migration and upgrade.
FAQs
How long does an Odoo implementation take? Single-module projects run three to four weeks. Multi-module rollouts run eight to twelve weeks. Multi-country and multi-company programmes run four to nine months with phased go-lives. The variable is almost never the configuration. It is how quickly decisions get made and how clean the legacy data is.
Can we start with one module and add more later? Yes, and for most teams it is the better call. Starting narrow gets you a live system with real numbers in it, and the second phase is scoped by people who now know the software. Settle the chart of accounts early, because changing it after the ledger has entries in it is painful.
What happens if we find a gap during the build? It goes on the same gap list as everything from discovery, gets a disposition and a number, and you decide whether it enters this phase or the next one. Nothing is absorbed silently, because absorbed work is what turns a fixed price into a dispute.
Who does the data migration, us or you? We do the mapping, the load and the reconciliation. You supply the extract and someone who can explain what the legacy fields actually mean. Cleaning is a shared job, and it is the part teams underestimate most.
What does hypercare include? Daily triage and fixes for the issues that only surface under real volume, report tuning, and administrator handover. The published bands include one month on the smaller projects and three months on the larger ones. After that it moves to a support agreement, or to you.
Written by
Odoo developer at Way4Tech. 120 modules published on the Odoo apps store. Writes the Odoo posts on this site.
Profile and published work