Every Odoo instance has to come down occasionally. A security patch, a module upgrade, a new integration, a database maintenance task: at some point the system needs to be touched while nobody is working in it. Teams that handle this badly treat each one as a surprise and absorb the disruption. Teams that handle it well have a standing window, a checklist, and a way back if the change misbehaves.
The changes that actually need a window
Not everything needs one, and knowing the difference saves a lot of unnecessary disruption.
- Configuration changes such as a new pricelist, a report tweak, or a user permission can normally be made on the live system. The caution is timing, not downtime: nobody should be editing an accounting configuration during month-end close.
- Module installs and custom code deployments do need a window. Odoo reloads its registry when a module is updated, and users who are mid-transaction get interrupted.
- Patch updates to your current major version are usually short, but they still require a restart.
- Version upgrades, moving from one major Odoo version to the next, are not a maintenance window at all. They are a project with their own testing cycle, and treating them as an overnight task is the most common way they go wrong.
- Infrastructure work such as storage expansion, a host move, or database maintenance sits with your hosting provider, but you still need to know when it is happening.
Choosing the window
The instinct is to pick the quietest hour of the week. That is right, but "quiet" is specific to your business, not to a generic calendar. A group with entities in more than one country rarely shares a single weekend, so choose the window against the entity that would be hurt most by an outage, and check it against the calendar that finance keeps rather than the one on the wall.
Things worth avoiding: month-end and quarter-end close, payroll runs, tax filing deadlines, warehouse cutoff times, and whatever your busiest retail hours are. If you run e-commerce or a customer portal on the same instance, remember that those stop too, and they have no working hours at all.
One more practical point: an overnight window needs somebody awake who can decide to roll back. A 2 a.m. slot with one engineer and no authority to abort is worse than a Saturday morning slot with the right people available.
What to do before the window opens
Most of the work happens before the clock starts.
- Rehearse the exact change on a staging copy of production, not on a demo database. Bugs hide in real data, real access rights, and a real chart of accounts.
- Take a fresh backup immediately before you start, and know how long a restore actually takes. A backup you have never restored is an assumption.
- Write the rollback step down before you need it, and set an abort deadline. If the change is not finished and verified by that time, you roll back rather than keep going.
- Prepare the checks you will run afterwards. Not "the site loads", but the things your business does: confirm a sale order, post an invoice, print a delivery note, open the report finance looks at first every morning.
- Agree who is on the call and who makes the call. One person decides.
What the window itself looks like
A clean window follows the same shape every time. Announce it and confirm users are out. Pause scheduled actions so a cron does not fire against a half-updated database. Take the backup. Apply the change and watch the log rather than the clock. Run your business checks. Reopen, then keep watching for an hour, because a slow degradation looks fine for the first five minutes.
The step most often forgotten is outbound email and queued jobs. If they were paused during the work, everything that piled up can leave at once when you reopen, and your customers experience the maintenance window as a burst of duplicate-looking notifications. Release that queue deliberately.
What "zero downtime" usually means
Be skeptical of a provider who promises no interruption at all. An Odoo module update takes locks on the database and reloads the registry. You cannot do that with users mid-transaction and pretend nothing happened. What a good provider can honestly offer is a short window, at a time you chose, with a rehearsed change and a tested way back. That is a different promise from zero downtime, and it is the one worth having in writing. If your agreement covers planned maintenance, check whether those windows are excluded from the uptime commitment, because they usually are. Our managed support and SLA service exists for exactly this kind of ongoing operational work.
On Plemo managed Odoo hosting, the pieces that make a window survivable are part of the platform: automated backups, point-in-time recovery, and a staging environment where the change gets rehearsed before it is scheduled. The plan is still yours to make. The tooling only decides how expensive it is to be wrong.