Every Odoo team hits the same awkward moment: you need to run a database migration, deploy a risky change, reconcile inventory, or cut over to a new fiscal year — and users keep transacting against a system that is mid-surgery. Odoo core has no first-class "close the shop for thirty minutes" switch. The nearest options are all blunt: take the server process down (which returns raw HTTP errors and looks like a real outage), unpublish the website (which does nothing for the backend, the portal, or the /web login), or drop an Nginx maintenance page in front (which locks out your own admins along with everyone else and can't be toggled from inside Odoo). The result is either data written during an unsafe window, or a self-inflicted outage with no branding, no messaging, and no controlled way back in for the person actually doing the work.

Maintenance Mode is a build-to-order Odoo module that gives you a real, application-level maintenance switch scoped to exactly what you choose: the public website, the backend /web client, the customer portal, or all of them. Technically it is implemented as a small config model (an res.config.settings extension plus a dedicated maintenance.window model built on models.Model) that a request-level hook consults on every inbound request. When the mode is active, an override of ir.http._dispatch (the pre-handler in 17.0/18.0/19.0) intercepts the request and serves a branded QWeb template with an HTTP 503 Service Unavailable status and a correct Retry-After header, so search crawlers back off cleanly instead of de-indexing your pages. Nothing reaches the controllers or the ORM write path while the gate is closed.

The behaviour is designed for the people who run the deploy, not just the people locked out by it. An allowlist — driven by ir.model.access.csv plus record rules on the window model — lets nominated users, specific groups, or requests carrying a secret bypass token or an IP on an allowlist continue to log in and work normally while everyone else sees the holding page. That means your admin, your integrator, and your QA tester can verify the release on the live database before you re-open the doors. You get a compute field showing current state, an activation reason and ETA that render into the holding-page copy, optional scheduled windows (start/stop timestamps enforced by an ir.cron automated action so a window opens and closes itself overnight), and an audit trail of who toggled the mode and when. XML-RPC/JSON-RPC traffic can be independently gated or exempted, so a scheduled integration doesn't hammer a closed instance — or, if you prefer, keeps syncing while human traffic is held.

Because this is built to order, we start from your actual topology — single company or multi-company, Community or Enterprise, self-hosted or Odoo.sh, behind Cloudflare/Nginx or not — and tailor the scope: which surfaces are gated, what the bypass mechanism is, how the holding page is branded and localized, and whether windows are manual, scheduled, or triggered by your deploy pipeline over the RPC API. You review the working module on a staging copy of your database during UAT, we hand over the source and the git repository, and only then do we deploy to production with a rollback plan in hand.

Delivery is typically two to four weeks from confirmed scope, depending on how many surfaces and integrations are in play. Pricing starts from $249 (indicative, single-company base scope); multi-company gating, per-website scoping, deploy-pipeline integration over XML-RPC/JSON-RPC, and bespoke branding/localization of the holding page increase the quoted scope. You get a firm fixed quote after a short scoping call — never a surprise.