9 Odoo Upgrade Mistakes That Cause Downtime

1. Never timing a full rehearsal

The cutover window is decided by one number: how long the whole sequence actually takes on production-sized data. Teams that have not measured it pick a number that feels reasonable, and the gap between that and reality is where outages come from.

Run the complete sequence once, timed, on a full copy. Restore, upgrade, install modules, run the checks. Note where you waited. That total, plus real contingency, is the window.

2. Forgetting the filestore in the timing

Databases upgrade at one speed and filestores copy at another. A business with years of attached PDFs and product images can spend more of the window moving files than converting data, and file copying is the step nobody includes in the estimate because it is not the interesting part.

Time it separately. If it dominates, that changes the plan, and it is far better to learn that during a rehearsal than at 1am.

3. Leaving scheduled actions enabled

A restored copy carries every scheduled action from production, and they start running as soon as the instance does. Now your test database is sending reminders, generating recurring invoices, pulling from bank feeds and triggering reordering rules, against data that is mid-conversion.

Disable scheduled actions on any restored database before it is reachable. On go-live night, disable them during the conversion and re-enable deliberately once the checks have passed, rather than letting the first cron of the new era run against a database you have not finished validating.

4. Not muting outbound email

The same problem, with a worse audience. A restored database has working mail configuration and a queue that may still contain unsent messages, so it will happily email real customers from a test system.

Disable outgoing mail before starting any restored copy. This one is worth a written step in the runbook rather than a habit, because it is unrecoverable and it happens to experienced teams.

5. Leaving integrations pointed at a database mid-migration

External systems do not know you are upgrading. Webhooks arrive, sync jobs run, and a payment provider or marketplace keeps posting into a database that is halfway through conversion.

Pause integrations at the start of the freeze window and resume them deliberately afterwards, in a known order, with someone watching the first cycle. Resuming everything at once at the end of a long night is how a partial sync becomes a reconciliation problem.

6. Going live at the worst possible moment

Immediately before month end removes the finance team's ability to absorb anything unexpected. Peak trading season removes the warehouse's. Friday evening means a problem found on Saturday waits until Monday for whoever could have fixed it in ten minutes.

Pick a quiet period, mid-week, with the people who built the customisations available the following day. This costs nothing and prevents more downtime than any technical measure on this page.

7. Not verifying the data freeze held

A freeze that was announced is not a freeze that happened. The overseas office, the night shift and the one person who works from a phone reliably miss the message, and their records are written into a database being converted underneath them.

Announce it, then verify it. A count of records created in the last hour, taken just before the conversion starts, tells you in seconds whether the freeze is real.

8. Treating the upgrade as a chance to change other things

Upgrade the version. Do not also change hosting, switch edition, restructure the chart of accounts, roll out new processes or enable three apps that looked useful.

Every additional change multiplies the number of possible explanations for anything odd, and diagnosis under time pressure is where windows overrun. Each of these is cheap on its own week and expensive in the same night as everything else.

9. No plan for the day after

The system being up is not the same as the business working. On the first morning, users hit changed screens, altered layouts and moved menu items, and support demand spikes precisely when the technical team is at its most tired.

Plan for it. Tell people what changed before the cutover, not after. Have someone available who can answer questions rather than only fix defects, and make it clear where questions go. A business unable to work because nobody knows where the button moved to is down, whatever the monitoring says.

The pattern underneath all nine

None of these are technical failures. Every one is a decision about sequencing, timing or communication that was left implicit and then made under pressure at 3am by whoever was awake.

The fix is the same in each case: decide in daylight, write it down, and rehearse the sequence once with a stopwatch. That rehearsal is also what produces an honest rollback deadline, and it pairs with the validation checklist that tells you whether to use it. For the failures that make numbers wrong rather than systems slow, see what actually breaks.