Eight early warning signs an Odoo rollout is going wrong

Projects rarely fail suddenly. They fail slowly, in ways that look like normal friction at the time, and then arrive as a crisis at cutover. Here are the signals we watch for, what each one turns into, and what to do while the fix is still small.

1. The scope is a list of module names

What it looks like. The statement of work says sales, inventory and accounting. Maybe it has user counts.

What it costs. A scope written as module names prices nothing. Every disagreement later becomes an argument about whether something was included, and both sides are sincere, because the document does not say.

The fix. Write scope as outcomes and gaps, with a disposition against each gap: configure, customise, change the process, or leave out. Every custom item gets its own number so it can be cut individually rather than the whole request being deferred. That list is the contract. It is also the only honest way to keep a fixed price fixed, because new requests after sign-off get quoted as change requests instead of being absorbed quietly into the timeline.

2. There is no named decision maker per function

What it looks like. Workshops are attended by people who can describe the current process but cannot change it. Every gap ends with “I will check.”

What it costs. Weeks, with nobody doing anything wrong. This is the most common cause of drift we see, and it is invisible on a status report because everyone is busy.

The fix. A named person per function with authority to change a process, not just describe it, plus a project owner on your side who can free those people up when the schedule needs them. We treat that as a condition of starting rather than a nicety.

3. Data is being cleaned inside the new system

What it looks like. Records are loaded early “so people can see it”, and corrections are being made in Odoo.

What it costs. The mess lands in front of users in their first week, which is exactly when they decide whether to trust the system. On an upgrade it is worse: a fix made in a converted copy is lost at the next conversion and reappears at cutover.

The fix. Clean in the extract, before it touches the target. Correct data issues at source in the live system so every subsequent load is cleaner, and prove the result with control totals reconciled against the old system and signed off by whoever closes your books.

4. Customisation is being agreed before anyone has run the standard flow

What it looks like. A custom list assembled in week one, mostly describing how the previous system behaved.

What it costs. Every customisation is a maintenance cost paid again at each upgrade. Code that extends standard behaviour ports quickly. Code that replaces standard behaviour, or that was written as edits to core, is expensive at every version.

The fix. Ask teams to run the standard behaviour first, then defend each request against one question: what breaks in the business if the standard behaviour is used instead. A real share of the original list gets withdrawn without argument, and nobody loses anything.

5. UAT is being run by the project team

What it looks like. Testing is a walkthrough led by the consultant, with the client team watching and nodding.

What it costs. The project team knows the intended path and will not find the problems. The defects surface in week one of live, at volume, with customers attached.

The fix. Scripted testing run by the people who will use the system daily, on their own logins with their own access restrictions, including the ones who were sceptical about the change. The sceptic usually knows something the sponsor does not, which is why we interview them deliberately.

6. Nobody owns the exception queue

What it looks like. Everyone agrees that rejected e-invoices, failed carrier bookings or unmatched bank lines will “be handled”.

What it costs. Rejections that belong to everybody belong to nobody. The list grows until it is its own project, and in a clearance e-invoicing market it grows into a compliance problem rather than a backlog.

The fix. Name the role before go-live, with a daily routine attached. Transient failures retry automatically with backoff. Anything needing a decision waits for a human rather than being silently dropped, and submission failures raise an alert, because a failed submission with no alert becomes a problem weeks later. This is the part of our e-invoicing work that clients most often try to cut and most often regret cutting.

7. Go-live is scheduled on a period close or a peak week

What it looks like. The date was chosen because it was the end of a quarter, or because someone wanted the new system live before the busy season.

What it costs. Two hard things at once turns a normal defect into a crisis. Your finance team cannot close last month and learn a new system in the same fortnight.

The fix. Choose the cutover date against your operating calendar in the first phase, while it is still cheap to move. Go or no-go is called against agreed criteria, not against the calendar. For payroll specifically, going live at the start of a cycle also avoids loading year-to-date figures for every employee.

8. Integrations and reports are being left until last

What it looks like. The plan tests the core flows first and pushes interfaces, document layouts and financial reports to the end.

What it costs. Credentials, endpoints and payload shapes all break on an upgrade or a rebuild, and each one has an external party attached whose response time you do not control. Reports are worse, because a report can run without error and still return a different number, and finance will find it at the first close.

The fix. Retest integrations during validation, not on go-live day. Compare key reports side by side against the old system for the same period before sign-off. On an upgrade, also check the things that break quietly: document layouts, access rights and scheduled actions.

The pattern behind all eight

Every one of these is a decision that was cheap early and expensive late. Structure, chart of accounts and analytic design. Who decides. Who owns data. Which reports are conditions of go-live. What happens on a bad day. None of them are software problems, and none of them get better by waiting.

If you are already mid-project and two or three of these are ringing, the cheapest next step is usually not more build. It is a short, external read of where the project actually is, which is what an Odoo health audit or a framed consultancy engagement is for. If you are still at the planning stage, the same list works as a checklist against whatever proposal you are holding, whether the work is a fresh implementation or a version upgrade.

One last thing worth saying plainly. A project where nobody has told you anything uncomfortable is not a project that is going well. It is a project where the uncomfortable things are being saved up.