Odoo implementation: what it is, and when you are ready for it
Most writing about ERP implementations is about software. In practice almost no project trips over the software. It trips over time, people and decisions. This page is about that part.
What is an Odoo implementation?
An Odoo implementation is the process of setting up your business processes in Odoo: from fit-gap and scope, through configuration, data migration and testing, to go-live and aftercare. For a mid-sized company staying close to the standard it typically takes around three months, with a one-off investment driven mostly by user count and the amount of customisation. The biggest variable is not the software but the availability of an internal owner who is allowed to make decisions.
What decides whether an implementation succeeds
Five things we kept seeing across 80+ implementations. None of them is about functionality.
-
An owner with hours, not with a title
The project moves as fast as the person driving it internally. Anyone doing that on the side of a full job becomes the bottleneck by default. Count on at least one day a week, more at the peak. This is the one factor we will say is almost always decisive.
-
Decisions within the week
An implementation is a chain of small choices: what do we call this, who is allowed to do that, which field is mandatory. If every choice waits a week for a meeting, the plan slips by exactly that many weeks. Pushing mandate further down the organisation is the cheapest acceleration available.
-
Standard unless, and meaning it
Everyone says "standard where possible". The difference shows the first time the standard feels uncomfortable. Companies that then adapt their process go live sooner and pay structurally less maintenance. Customisation is not a sin, but it should be a choice with a reason, not a reflex.
-
Data is an organisational question
Technically, migrating is rarely the problem. The problem is that nobody wants to decide which of the three customer lists is the truth. Assign an owner per data type who is allowed to say: this comes along, this does not. Do that in week one, not week eight.
-
A reason why now
Projects with a hard trigger (a contract ending, a system retiring, a financial year) hit their date more often. Without that pressure an implementation keeps slipping one sprint, until nobody remembers when it was supposed to be done.
Is your organisation ready to start?
Five questions about the factors that most often decided, in our projects, between going live on time and running months over. No lead form, no email: you see the outcome immediately.
- 1 of 5
Is there an internal owner with time?
The strongest predictor in our projects. Not someone who fits it in, but someone with hours blocked in their calendar.
- 2 of 5
Is that person allowed to decide?
Every week waiting on a decision is a week of delay. Mandate matters more than job title.
- 3 of 5
How do you view the Odoo standard?
Companies that adapt their process to the standard go live faster and pay less. Customisation is fine, but as a deliberate choice.
- 4 of 5
What state is your data in?
Data migration is rarely technically hard and often organisationally hard: who decides what comes along?
- 5 of 5
Do you have a reason to start now?
A hard deadline (a contract, a financial year, a system being retired) creates rhythm. Without one, projects tend to drift.
-
Do not start yet
On this basis an implementation becomes expensive and frustrating. That is not a judgement on your company: it only means the preparation is not done. Arrange an owner with time and mandate first. That is cheaper than a project that stalls halfway.
Almost ready, close one gap first
The basics are there, but at least one weak spot will show up during the project as delay. Fix it before you start, or make it an explicit risk in the plan.
Ready to start
This is the profile of projects that go live in around three months. The next step is scope: decide what is in phase one and what deliberately comes later.
Your weakest point right now:
What it costs your own team in hours
Almost every quote tells you what the partner costs. Almost nobody tells you what it costs you. These are indicative hours for a standard three-month project at a company of fifteen to twenty-five users. It is the line item most often forgotten, and the only one you cannot buy in.
| Role | When | Hours |
|---|---|---|
| Internal project owner Roughly one day a week. This is the role you cannot halve without doubling the lead time. | Throughout, peaking around testing and go-live | 70 - 100 |
| Key user per process (3 to 5 people) They know how the work actually goes. Without them you design a process that is right on paper and wrong in practice. | From fit-gap through testing | 20 - 35 each |
| Data owner Someone allowed to decide, per data type, what comes along. Often the same person as the project owner at smaller companies. | Peaks during the migration weeks | 10 - 20 |
| Board or sponsor Few hours, large effect. Mainly needed to settle the calls the project owner is not allowed to make alone. | Every two weeks, plus the go/no-go moments | 8 - 15 |
| Other end users Put this in the calendar rather than fitting it in, otherwise the training room is half empty on the day. | Training and acceptance testing | 4 - 8 each |
| Total internal, indicative | 200 - 300 hours | |
That looks like a lot, and it is. It is still cheaper than the alternative: a system configured on assumptions instead of on how you actually work. The hours go in either way - the question is whether they are in the plan up front or show up afterwards as delay.
Who does what
Most disappointment comes not from bad work but from a wrong expectation about who is on the hook for what. So, explicitly:
On your side
- Deciding what a process should look like, and doing it within the week.
- Naming the key user per process and giving them the time.
- Determining which data comes along and which you leave behind.
- Bringing your own people with you: explaining why this is happening, not just what changes.
- Taking the acceptance test seriously, with real orders and real invoices.
On our side
- The fit-gap: translating what you do into what Odoo does as standard, and where it rubs.
- Configuring, integrating and building what genuinely has to be custom.
- Running the data migration technically, including a trial conversion.
- Training, and explaining the system in your language rather than in Odoo terms.
- Keeping scope, planning and budget moving in step with each other.
The dividing line is simple: we know how Odoo works, you know how your business works. An implementation is the moment those two meet. A partner who says they will just do it without you is selling you a system you are not going to use.
The five most expensive misconceptions
In our experience these five cost the most money, and all of them are avoidable up front.
-
"We will replicate our current process one to one."
Then you pay for customisation to rebuild habits that often exist because of a limitation in your old system. It pays to ask, per process: do we do this because it is good, or because it could not be done otherwise? That single conversation usually returns more than any feature.
-
"The implementation partner does it."
We configure, integrate and migrate. But we cannot decide how your order process ought to run, and we do not know which of your three customer lists is correct. Without internal hours the implementation becomes a series of assumptions.
-
"We will decide that later."
Deferred decisions are the quietest cost in a project. Every open choice usually blocks more work than it appears to, and deciding later often means configuring twice. Better a decision you adjust in a month than a month without one.
-
"Going live with everything at once is more efficient."
It sounds logical and rarely works out that way. Everything at once means every problem coincides with every other problem, in the same week, while your organisation is still learning to work. Phasing costs slightly more time on paper and delivers a calmer go-live in practice.
-
"After go-live we are done."
The first months after go-live decide whether the system is genuinely used or whether Excel creeps back. Expect a period of adjustment: reports that need to be slightly different, permissions that chafe, processes missing a step in practice. That is not failure, that is the normal final twenty percent.
When you are better off not starting yet
We would rather say this up front than halfway through. In these situations we advise waiting, even when it costs us the project:
- Nobody has been freed up to drive it internally.
- The board has not yet agreed on the direction.
- You are in the middle of an acquisition, a move or a reorganisation.
- The goal is "off that old system" with no picture of what should be better afterwards.
- The expectation is that the new system will work exactly like the old one.
None of these is final. They are simply cheaper to solve before the start than after it.
Further reading per question
This page is about the decision. For the detail we have separate, deeper pages:
- How long does an Odoo implementation take? Three months as the base, and what exactly adds to it.
- What does an Odoo implementation cost? How the price is built up and why it drops per user.
- Implementation checklist: 26 checkpoints The operational list per phase, from preparation to aftercare.
- The TARGET method How we steer projects so they stay on time and in scope.
- Implementation calculator An indication of cost and lead time for your user count.
- Implementation benchmark What other partners charge, with figures from 50 quotes.
Frequently asked questions about Odoo implementations
How long does an Odoo implementation take?
For a mid-sized company staying close to the standard, around three months is a realistic base, from kick-off to go-live. More modules, more customisation, more sites or slow decision-making add to that. In practice lead time is set more often by internal availability than by build time.
Work back from your go-live date How long does an implementation take exactly?
What do I need internally for an Odoo implementation?
At minimum an internal owner with roughly one day a week freed up and the mandate to make process choices, plus someone per process who genuinely knows the current way of working. On top of that, an owner per data type who may decide which records come along. Without those roles the project moves at the speed of the board's calendar.
Can you roll out Odoo in phases?
Yes, and usually that is wise. Start with the core that removes the most pain - often sales, stock and finance - and add manufacturing, projects or e-commerce in a second phase. Phasing lowers risk and keeps the organisation engaged, as long as you record up front what deliberately comes later.
How we fix scope and phasing (TARGET) The checklist per phase
What usually goes wrong in an ERP implementation?
Rarely the software. In our projects delay almost always comes from the same place: no internal owner with time freed up, decisions that sit for weeks, or the wish to rebuild the old system exactly instead of adapting the process to the standard. Data migration stalls on who decides which records are the truth, not on the technology.
Should we adapt our processes to Odoo or the other way around?
Standard where you can, custom where you must. Processes that do not make you distinctive are better adapted to the standard: faster live, lower cost and easier to update. For the processes where you genuinely differentiate, customisation is worth the investment. The point is making the choice deliberately, not avoiding customisation.
Not sure whether you are ready?
Put your outcome to someone who has seen it more often. We will say honestly if you are better off waiting - that sometimes costs us a project and saves you a failure.
Odoo Gold Partner · Amsterdam · 80+ implementations