Khichdi InfoTech
Skip to content

Odoo Migration · intermediate · 11 min read

Odoo Go-Live Checklist

A practical Odoo migration go-live checklist: pre-cutover freezes, backup verification, maintenance runbook steps, smoke tests, integration reopen, and hypercare handoff.

Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice

Table of contents

The go-live checklist is the timed runbook for cutover: pre-maintenance freezes, final backup verification, upgrade execution, module updates, smoke tests, integration reopen, user communication, and hypercare channel activation.

Each line item should have an owner, expected duration from cutover rehearsal, and pass/fail criteria. Checklists without times drift; checklists without owners stall.

Pair this checklist with rollback triggers and signed UAT from testing — go-live is the last gate, not the first validation.

Spreadsheets titled go-live often list vague tasks like upgrade system. Operators need ordered commands, verification steps, and decision points that match the last successful dry run.

Customize this structure to your estate — multi-company, POS, and heavy integrations add rows. Rehearse once end-to-end including communications.

Confirm UAT sign-off on the build tagged for cutover. Freeze non-migration code merges and production configuration changes. Notify integration vendors of maintenance window and freeze expectations. Verify backup jobs succeeded and restore drill date is current.

Publish user communications: downtime start/end (with overrun caveat), read-only periods, helpdesk channel, and what not to do during maintenance (manual spreadsheets replacing ERP without ops approval).

  • Tagged Git release matches last signed staging build
  • Rollback triggers and decision-maker contact sheet distributed
  • Integration freeze acknowledgments from vendors
  • Hypercare roster and escalation path confirmed

Enable maintenance page or read-only mode. Stop inbound integrations and scheduled jobs that mutate data. Take final PostgreSQL backup and filestore snapshot; record size and location. Verify no active user sessions performing financial postings.

Only after backup verification succeeds, begin database upgrade procedure documented from dry runs. Log timestamps for each major command.

Run core database migration path, then module -u sequence from porting runbook. Monitor logs for tracebacks. Do not open to users mid-sequence. Complete post-upgrade data scripts if part of signed plan.

If critical traceback appears, consult pre-agreed fix-forward vs rollback criteria before improvising untested SQL.

Execute critical smoke script: login as key roles, create and post minimal SO/PO/invoice flow, confirm stock move, run one payroll or fiscal step if applicable, print sample report, hit integration health endpoint in staging-equivalent config.

Finance reconciliation spot-check against pre-cutover snapshot. Failed smoke per trigger table stops reopen until resolved or rollback initiated.

Re-enable integrations in agreed order — often master data syncs before transactional webhooks. Remove maintenance page. Activate hypercare channel with triage rules: severity definitions, who assigns developers, when to escalate to rollback review.

Monitor error rates, cron failures, and queue backlogs for 24–72 hours. Hold daily hypercare standups until volume drops to agreed threshold.

  • Time every checklist row from cutover rehearsal — not from estimates.
  • Assign one scribe on cutover night to log times and outcomes.
  • Do not skip smoke tests to meet a cosmetic end time.
  • Open integrations only after core ERP smoke passes.
  • Hand off to hypercare with open issue list and known workarounds.

  • !Checklist copied from a different Odoo version or hosting model.
  • !Missing integration reopen order — duplicate or orphan transactions.
  • !Announcing success before finance smoke completes.
  • !No scribe — post-mortems lack timestamps and facts.
  • !Hypercare roster empty on day one because team is exhausted from untimed cutover.

A rehearsed go-live checklist turns cutover from heroics into a timed sequence with smoke gates and hypercare handoff.

Plan post-migration support capacity before you execute this list — day-one issues are normal; unprepared support is not.

Full cutover checklist visual companion.
  • Owners named
  • UAT scripts signed
  • Rollback documented
  • Hypercare roster ready

Hour blocks: backup, upgrade, smoke, reopen.

  1. T-7d

    Freeze non-critical changes.

  2. T-1d

    Final backup and communication.

  3. T-0

    Maintenance window cutover.

  4. T+1d

    Hypercare and smoke tests.

Cutover completion to hypercare standup loop.
1

Trigger

Business event starts the flow.

2

Execute

Operate in the system of record.

3

Validate

Check outcomes and exceptions.

4

Close

Reconcile and hand off.

Frequently asked questions

How long should the checklist be?

Long enough to be executable — often two to five pages for mid-size estates. If it fits on a postcard, it is probably missing verification steps.

Who runs the checklist?

Operations or technical lead executes steps; programme owner tracks time and go/no-go; decision-maker authorized for rollback per rollback planning.

Should users test during cutover?

No. Only defined testers run smoke scripts before general reopen. Wider access belongs after smoke pass and hypercare channel is live.

Need a cutover runbook built from your dry runs?

We produce timed checklists, smoke scripts, and hypercare handoffs aligned to your last successful staging rehearsal.

Business technology and software delivery