“How long is this going to take?” is the second question in every system decision, right after “what does it cost”. The honest answer for Odoo: a standard implementation stands in about three months - and after that, everything adds up. More users, heavier modules, custom work, integrations, data migration: each of those choices makes the project longer, and one factor makes everything shorter. This is what really drives the timeline, why we deliberately do not run it as an agile project, and how to count back from a hard date like 1 January. Want to run your own numbers straight away: the go-live planner does it in a minute.
The short answer: three months, if you stay standard
An implementation of the core processes - CRM, sales, purchasing, accounting - for a normally sized team stands in roughly three months. That is not a marketing number but a conditional one: it holds as long as the scope stays standard, the data migration is limited, and someone on your side genuinely frees up time.
Why can it go that fast? Because for those core processes, Odoo is simply finished. You configure, you set up, you migrate a manageable set of master data - but you build nothing. Every week in such a project goes into making choices, not into writing software.
It also means the reverse: every step outside the standard has a price in time. That is not an objection - sometimes your process is worth the custom work - but it belongs on the table before the planning gets promised.
What adds up
The timeline of an Odoo project is no mystery. It is additive, and the line items are almost always the same.
Users. More people means more processes touched, more training, more opinions and more testing. An implementation for two hundred people is fundamentally different work than one for fifteen.
Heavier modules. eCommerce and Manufacturing are the two classics. A webshop touches product data, stock, payments and shipping at once; manufacturing touches bills of materials, routings and planning. Both work excellently in Odoo - but both are a project inside the project.
Custom work. From a small screen tweak to your own calculation engine: custom work has to be designed, built and tested. The range is wide, and precisely why its size should come out of a fit-gap analysis rather than a gut feeling.
Integrations. Every connection to an external system - a webshop, a logistics provider, EDI with a buyer - brings a second party with its own pace. Integrations are rarely big work per piece, but they stack, and you are not the only one setting the tempo.
Data. The most invisible line item. If your customers, products and open items are clean, migration is a task. If they first need deduplicating and cleaning, it is a sub-project. Anyone who grew up in Excel usually already knows which side they are on.
Multiple entities. Multi-company is not a checkbox: every additional entity brings its own configuration, its own flows and intercompany traffic, and multiplies the coordination.
Add it up and you understand the range you see everywhere: three months standard, six to nine with serious scope, towards twelve for large multi-company projects.
The biggest accelerator is not technology but a person
If we could pass on one thing from all our projects, it is this: the availability of your internal project lead sets the pace more than any technical choice.
Every implementation lives on decisions. Which fields are mandatory? Who can see what? Is this exception worth configuring or do we abolish it? A project lead who genuinely gets time for this - and mandate - answers those questions in days. A project lead who fits it in on Friday afternoons answers them in weeks. Multiply that by the hundred decisions every project asks, and you see where plannings die.
That is why we ask about it explicitly up front, and why it weighs heavily in our planner: from at least four hours a week on a small project to “as much as needed” on a large one. It sounds like a detail. It is the lever. And the project lead does not stand alone: who belongs next to them per process is covered in what is a key user.
Why we do not run it as an agile project
Many implementation partners work agile: sprints, a backlog, discovering along the way what is needed. We deliberately do the opposite. The fit-gap analysis at the start produces a scoping table that turns the project into a predictable waterfall project.
Per process it is fixed what works standard, what is configuration and what genuinely has to be built - including the definition of done, before anything gets built. Deviating is allowed, but then we know what we are deviating from. The consequence for the timeline is exactly what you want: a plan that is right up front instead of one that emerges along the way, and a fixed price per phase instead of an open end. “Discovering along the way” sounds flexible, but it is the most expensive way to find out your scope was bigger than you thought.
Counting back from 1 January
Most deadlines are wishes; the book-year boundary is a real one. Live per 1 January means starting clean: no half a book year in the old system and half in the new, no double administration for your accountant.
If you want to be live on 1 January, you count back. First subtract two months of buffer - for test findings, new wishes that surface once people see the system, and plain overrun. That buffer is not pessimism; every go-live without one trades quality under pressure, exactly in the weeks that decide whether users embrace the system. What remains is the room for your actual scope. Start after the summer and a standard project fits comfortably. If your full scope does not fit, there is one dial left - and it is the most important one in this whole story.
Scope is a dial: phasing
“Not feasible” barely exists. What does exist: not everything at once. The answer is phasing - live with the core processes first, the heavier parts right after. Accounting in the new system per 1 January and the webshop integration in February is not a failed plan; it is a good one.
Phasing also takes risk out of the project: a smaller first go-live is a manageable go-live, and your team gets to know the system while phase two is being built. Nearly every “unfeasible” date becomes feasible once the question changes from “when can everything” to “what genuinely has to stand by that date”.
In short
A standard Odoo implementation stands in about three months; users, heavier modules, custom work, integrations, data and additional entities add on top, up to six to nine months for serious and towards twelve for large projects. The biggest accelerator is an available internal project lead. With a fit-gap and a scoping table we deliberately turn it into a predictable waterfall project. And for a hard date like 1 January: count back, keep two months of buffer, and use scope as a dial. The go-live planner runs your situation in a minute.
Want to know whether your date is feasible? Fill in the go-live planner for a first estimate, or book a free Odoo scan - and we will map scope, phasing and planning together.
Read more: What does an Odoo implementation cost? · The TARGET method · What is a key user? · From Excel to Odoo · Odoo directly or via a partner