Odoo go-live and hypercare checklist for UK teams

Reviewed 5 November 2026. Use this checklist for an Odoo 19 UK release. Assign an owner and evidence link to every applicable item, record explicit non-applicability where appropriate, and keep technical readiness separate from functional acceptance. A checked item should represent inspected evidence, not verbal confidence.

1. Establish release governance

• Release baseline: Confirm the approved blueprint, configuration and code versions, migration mapping versions, integration versions and requirement baseline are identified. Evidence is the controlled release manifest.
• Scope and exclusions: Confirm process owners and the client product owner agree what is and is not in this release. Evidence is the signed scope and exception register.
• Decision authority: Name the go or no-go decision-maker, technical lead, functional lead, migration lead and escalation sponsor. Evidence is the release responsibility record.
• Release calendar: Record workshops, freezes, final extracts, rehearsal, cutover, business close constraints and hypercare reviews without presenting the plan as an unconditional duration promise.
• Change control: Confirm late changes have an impact assessment, test requirement and approval route. Evidence is the current change log.
• Issue triage: Define severity, ownership, communication, escalation and resolution review for cutover and hypercare. Evidence is the published triage route.

Do not allow a serious unresolved decision to be hidden under “general readiness”. Each workstream should report its own evidence and residual risks to the release authority.

2. Complete technical readiness checks

• Environments: Verify intended production and recovery environments, configuration promotion, scheduled actions, storage, monitoring and access are controlled and documented.
• Users and permissions: Test role groups, company restrictions, approval permissions, administrator access and leaver or transfer handling with representative users.
• Integrations: Verify credentials, endpoints, certificates, network access, schedules, retries, duplicate prevention, error queues, monitoring and manual recovery for every flow.
• Bank connectivity: Validate each institution, provider, authorisation owner, feed-start behaviour and account mapping without inferring universal coverage.
• HMRC connection: Verify authorised users and entity context for the intended Odoo 19 UK workflow; include multi-company credential procedures where relevant.
• Documents and outputs: Test invoices, bills, operational documents, emails and reports for content, branding, tax information, delivery and archive behaviour.
• Performance and volumes: Exercise representative transaction and import volumes and investigate errors or unacceptable operational behaviour before release.
• Backup and recovery: Confirm the recovery approach, responsible owner and restoration evidence appropriate to the hosting and operating model.

Technical checks should use the release configuration and realistic access rights. An administrator-only smoke test does not prove that ordinary roles can operate securely.

3. Complete migration readiness checks

• Source freeze: Confirm which records can change, which must stop and how deltas are handled from final extraction through operational start.
• Extract control: Verify final extract names, source filters, timestamps, row counts, control totals and preserved original files.
• Mapping approval: Confirm account, tax, contact, product, currency, dimension and integration mappings have named business approval.
• External IDs: Verify every imported object has a durable source namespaced identifier and a tested create, update, skip or conflict rule.
• Dependency waves: Confirm foundation, masters, documents, balances, payments and history run in the documented order and each wave has an entry gate.
• Repeatability: Demonstrate that corrected files can be rerun without uncontrolled duplicates or loss of accepted target changes.
• Reconciliation: Compare trial balance, receivables, payables, bank, stock and other agreed positions to source evidence at the approved detail level.
• Exceptions: Assign every unresolved source, mapping or import exception an owner and release decision; do not hide differences in a suspense balance.

The migration lead confirms mechanical completion, while finance and operational owners accept business meaning. Both are required for migration readiness.

4. Complete functional acceptance checks

For each priority workflow, execute normal and exception scenarios using migrated or representative production-shaped data. Trace the result to the requirement ID and blueprint decision.

Finance scenarios should cover relevant taxes, credit notes, partial payments, adjustments, close controls and reporting. Operational scenarios should cover the actual purchasing, sales, stock, project, manufacturing or service exceptions that create daily work. Multi-entity scenarios should test company boundaries, shared records and consolidation inputs.

Verify that reports answer their intended control question and reconcile to underlying transactions. A report that renders without error can still contain the wrong population or accounting basis.

Record defects by solution, migration, integration, custom code, source quality or training cause. Retest the fix and the relevant regression path before closing it. Process owners sign the operational outcome rather than merely confirming that a demonstration was attended.

UK VAT scenarios and statutory treatment receive qualified accountant review where required. Odoo 19's VAT100-ready structure and HMRC-listed software status do not replace that review.

5. Confirm training and adoption readiness

• Role-based learning: Confirm each user population has practised its own start-to-finish workflows and exceptions with representative data.
• Local champions: Name champions for each function or location and confirm they know first-line triage and escalation.
• Operating guides: Provide concise instructions for daily work, period close, integration exceptions, bank reconciliation and HMRC-related review where applicable.
• Access readiness: Confirm users can sign in, see the intended companies and menus, and perform their assigned approval and operational actions.
• Adoption measures: Define the operational reports that will show whether the process is being used, such as invoice completion, approval usage, receipt matching or stock transaction completion.
• Feedback route: Give users one controlled route for issues, questions and improvement requests so new requirements are not confused with defects.

Attendance is not the same as competence. Ask local champions and process owners to observe representative tasks and identify where additional coaching is needed.

6. Run and review a mock go-live

Use the intended runbook, controlled production-shaped data and the people who will perform the real release. Where appropriate, rehearse on a production copy with access and sensitive information controlled.

Execute final extraction, dependency-ordered imports, configuration promotion, integration switching, bank and HMRC checks, reconciliation, user smoke tests and the go or no-go review. Record actual waiting time, failures, manual workarounds and unclear ownership.

Test at least one critical failure route. The team should know whether to correct and rerun, extend a freeze, invoke a documented fallback or stop. A rehearsal that tests only the happy path leaves the most important decision unpractised.

Afterwards, update the runbook and repeat any materially changed step. Record remaining risks and the evidence required to close them. Rehearsal output informs readiness; it does not guarantee elapsed implementation time or operational savings.

7. Control the final cutover runbook

The final runbook should be executable by someone other than its author. Use ordered tasks with named primary and backup owners, prerequisites, expected evidence and completion confirmation.

Include the source freeze announcement, final extracts, configuration and code release, import waves, integration and bank switches, access verification, financial and operational reconciliation, smoke tests, communications and hypercare handover.

Include decision points explicitly. State which failures stop the release, who can approve a workaround and what additional reconciliation or follow-up that workaround requires. Avoid informal changes in a chat channel that never reach the controlled runbook.

Preserve final logs and approvals. If a manual intervention is necessary, record the reason, record identifiers, before-and-after evidence and any follow-up needed to restore repeatability.

8. Make the go or no-go decision on evidence

The release review should show technical and functional status separately. Summarise critical defects, migration reconciliation, integration results, user readiness, statutory-review dependencies, operational constraints and residual risks.

A green technical report cannot compensate for an unaccepted trial balance or a warehouse process that fails its principal exception. A willing business sponsor cannot compensate for unknown production access or unrecoverable integration credentials.

Record the decision, attendees, evidence reviewed, conditions and follow-up owners. If the decision is conditional, define exactly when and how those conditions are checked. If the release is stopped, preserve the work completed and update the next rehearsal scope from the failure evidence.

9. Operate hypercare against a visible triage model

Classify issues by operational effect and urgency. Define what blocks accounting or operations, what has a controlled workaround and what is a new requirement rather than a defect. Assign each issue to solution, migration, integration, source-data, training or third-party ownership.

Hold scheduled reviews with the client product owner, local champions and relevant technical owners. Use the issue log and operational reports to identify repeated confusion, unused approvals, failed postings, unmatched bank items or work completed outside Odoo.

Third-party issues need a clear escalation route and evidence package. Bank providers, HMRC, integration vendors and internal IT have different responsibilities; the triage record should not label every external error an Odoo defect.

Support channels, service windows and response expectations follow the approved operating agreement. Hypercare does not imply an unapproved support level or unlimited new development.

10. Define hypercare exit and hand over ownership

Exit when the agreed operating evidence is stable and residual items have named long-term owners. Review transaction completion, reconciliation status, integration health, user adoption, critical defects, recurring questions and any deferred requirements.

Hand over configuration and exception documentation, integration runbooks, migration mappings and external IDs, reconciliation evidence, training materials, support routes and the decision log. Confirm credential and ownership transfers are complete without sharing secrets in the documentation pack.

Run a retrospective across solution, migration, testing, training and governance. Convert lessons into blueprint changes, support priorities or a separately estimated optimisation phase. Do not relabel unresolved release defects as optimisation to close the programme.

The final acceptance record should distinguish operational acceptance, remaining support items and future enhancements. That gives the organisation a controlled basis for ongoing ownership rather than a vague statement that go-live is complete.

Educational sources and product boundary

The checklist reflects practices discussed in public OXP2026 sessions on implementation responsibilities, migration and import practice and testing, adoption and go-live readiness. They are educational sources, not Oakland references or evidence of a result at a featured organisation.

Use Odoo 19 United Kingdom localisation and Odoo 19 bank synchronisation for current product boundaries. Odoo 20 announcements require a separate evaluation and must not be used as evidence of current Odoo 19 readiness.