Odoo.sh Upgrade Workflow Tracker

ERPWeb Test Client — Test Odoo 16 to 19 Upgrade — Odoo 16 to Odoo 19

Back to Project Upgrade Report Work Packages Action Plan Risk Summary Dependency Summary Latest Scanner Findings Projects Dashboard
0% Execution checklist progress
17 Open checklist items

Next: Confirm latest production backup exists

0 Blocked checklist items
6 Odoo.sh environments / branches

Environment Status

Planned: 6 Ready: 0 In Progress: 0 Blocked: 0 Validated: 0 Archived: 0

Checklist Status

To Do: 17 In Progress: 0 Blocked: 0 Done: 0 N/A: 0

1. Odoo.sh Branch & Environment Plan

Use this to plan the exact Odoo.sh environments used during the upgrade cycle. This is tracking-only and does not modify Odoo.sh automatically.

Planned Production

10. Production - Current Live Database

Reference live environment. Do not modify directly during upgrade preparation. Used for final backup, restore source, and go-live comparison.

Source branch: production · Target branch: - · Odoo version: 19.0

Validation notes:

Confirm latest production backup exists before starting any upgrade test.
Planned Staging

20. Staging - Current Version Restore Copy

Restore a fresh copy of production on the current Odoo version to validate baseline behaviour before upgrade work.

Source branch: production · Target branch: staging-current · Odoo version: 19.0

Validation notes:

Confirm login, key menus, custom modules, scheduled actions, website, email behaviour, and integrations before upgrade testing.
Planned Upgrade/Test Upgrade

30. Upgrade Test Branch

Main Odoo.sh branch/environment used to run Odoo upgrade tests, apply custom module fixes, and repeat upgrade cycles.

Source branch: staging-current · Target branch: upgrade-test · Odoo version: 19.0

Validation notes:

Track each upgrade run result, module fixes, server errors, failed tests, and retest status.
Planned Development

40. Developer Fix Branch

Developer working branch for custom module fixes identified by scanner findings, failed upgrade tests, and UAT feedback.

Source branch: upgrade-test · Target branch: upgrade-fixes · Odoo version: 19.0

Validation notes:

Only merge tested fixes back into the upgrade test branch after review.
Planned Staging

50. Client UAT Branch

Client-facing UAT environment after technical blockers and major upgrade errors have been resolved.

Source branch: upgrade-test · Target branch: uat · Odoo version: 19.0

Validation notes:

Client must validate core flows and sign off before go-live planning.
Planned Backup/Restore Copy

60. Rollback Backup / Restore Point

Document the final pre-upgrade backup and restore point required before go-live.

Source branch: production · Target branch: pre-upgrade-backup · Odoo version: 19.0

Validation notes:

Confirm backup timestamp, restore feasibility, and rollback owner before go-live.

2. Upgrade Execution Checklist

This checklist tracks the full ERPWeb upgrade execution flow from backup through post-live validation.

Backup & Restore Safety

To Do

10. Confirm latest production backup exists

Before any upgrade execution, confirm that a recent production backup exists and can be restored if needed.

Acceptance criteria:

Backup timestamp recorded. Backup source confirmed. Responsible person confirmed. Restore location or Odoo.sh backup point identified.
To Do

20. Restore production copy to baseline staging

Create or refresh a staging environment from production before upgrade testing.

Acceptance criteria:

Staging restored successfully. Users can log in. Current-version behaviour is confirmed before upgrade changes.

Odoo.sh Branch & Environment Planning

To Do

30. Define Odoo.sh branch and environment plan

Confirm which Odoo.sh branches will be used for production, baseline staging, upgrade testing, developer fixes, UAT, and rollback.

Acceptance criteria:

Branch names captured. Purpose of each branch is clear. Owner/status captured for each environment.
To Do

40. Confirm target Odoo version and upgrade route

Confirm source and target Odoo versions and whether upgrade will use Odoo.sh upgrade tools, Odoo upgrade service, or manual migration steps.

Acceptance criteria:

Source version confirmed. Target version confirmed. Upgrade method documented. Known version-specific risks reviewed.

Code Preparation

To Do

50. Review scanner action plan and work packages

Review the generated scanner findings, risk summary, dependency summary, action plan, and developer work packages.

Acceptance criteria:

Critical/high work packages assigned. Missing dependencies reviewed. Estimated hours reviewed. No blocker ignored without a note.
To Do

60. Prepare custom modules for upgrade branch

Apply custom module fixes needed for the target Odoo version in the developer or upgrade branch.

Acceptance criteria:

Custom modules updated. Manifest versions checked. Deprecated APIs reviewed. XML/view and JS issues reviewed. Code committed to the correct branch.

Database Preparation

To Do

70. Capture database-specific upgrade risks

Document database-specific concerns such as large tables, custom fields, studio changes, scheduled actions, website data, accounting localisation, and integrations.

Acceptance criteria:

Key business modules listed. Known customisations captured. Integration risks captured. Large/critical data areas identified.

Upgrade Execution

To Do

80. Run first upgrade test

Run the first upgrade test against the restored copy and record errors, failed modules, logs, and immediate blockers.

Acceptance criteria:

Upgrade run completed or failed with logs captured. Errors recorded as work packages or checklist notes. Next technical action identified.
To Do

90. Repeat upgrade cycle until technical blockers are cleared

Repeat upgrade runs after developer fixes until the database upgrades and starts cleanly enough for technical testing.

Acceptance criteria:

Upgrade environment starts. No critical startup errors. Main apps install/load. Remaining issues documented.

Technical Testing

To Do

100. Run technical smoke tests

Validate login, menus, custom modules, views, reports, scheduled actions, permissions, mail, website, and key integrations.

Acceptance criteria:

Smoke test checklist completed. Failures logged. Blocking failures fixed or assigned.
To Do

110. Validate core business flows

Test the client’s important flows such as sales, purchases, inventory, accounting, manufacturing, POS, website, helpdesk, or project depending on the project.

Acceptance criteria:

Core flows tested. Evidence or notes captured. Critical flow failures resolved before UAT.

Client UAT

To Do

120. Prepare client UAT environment

Prepare a stable upgraded environment for client testing with clear test instructions and known limitations.

Acceptance criteria:

UAT branch/environment ready. Client users can access. Known issues documented. UAT instructions shared.
To Do

130. Capture client UAT sign-off

Confirm client testing is complete and capture sign-off or remaining agreed issues.

Acceptance criteria:

Client sign-off captured or pending issues documented. No unapproved go-live blockers remain.

Go-Live

To Do

150. Prepare go-live checklist

Confirm final backup, downtime window, responsible people, Odoo.sh steps, DNS/email/integration checks, and post-live validation tasks.

Acceptance criteria:

Go-live window confirmed. Final backup plan confirmed. ERPWeb and client owners confirmed. Post-live validation checklist ready.
To Do

160. Execute upgrade go-live

Perform the approved production upgrade according to the agreed plan and record timing, outcome, and issues.

Acceptance criteria:

Production upgraded. Critical services checked. Go/no-go decision recorded. Any emergency fixes documented.

Rollback Planning

To Do

140. Prepare rollback plan

Document how ERPWeb will roll back if go-live fails, including backup source, responsible person, decision window, and communication plan.

Acceptance criteria:

Rollback steps documented. Rollback owner confirmed. Decision deadline confirmed. Client communication plan confirmed.

Post Go-Live Validation

To Do

170. Validate after go-live

Run post-live checks for login, menus, key workflows, scheduled actions, integrations, email, website, reports, and user access.

Acceptance criteria:

Post-live checks completed. Client confirms system is usable. Any post-live issues assigned and tracked.

How ERPWeb Should Use This Page

Before development: confirm backups, create baseline staging, define branches, then assign code work packages.

During upgrade: run upgrade tests, capture blockers, fix custom modules, rerun scans, and keep this checklist updated.

Before go-live: UAT sign-off, rollback plan, final backup, and go-live checklist must be complete.

This page is tracking-only. It does not connect to Odoo.sh API or execute upgrade actions automatically.