Zenithonsoft

Upgrading Odoo.sh to Odoo 20: Staging Testing, Python 3.13 & Breaking Deprecations

Upgrading a production ERP system is one of the highest-stakes events in enterprise IT.

When your database manages millions of dollars in customer invoices, real-time warehouse inventory, and active payroll, an upgrade cannot be treated as a casual software patch.

For teams hosting their infrastructure on Odoo.sh (Odoo’s cloud Platform-as-a-Service), the platform provides automated tooling to test database migrations. However, pushing a button on an automated script does not guarantee your custom addons, third-party marketplace integrations, or business workflows will function properly on the new version.

With Odoo 20, breaking architectural shifts—including the deprecation of legacy Record Rules (ir.rule), strict bank transaction validation, and the transition to Python 3.12/3.13 runtimes—mean that upgrades must follow a disciplined staging methodology.

Here is a senior architect’s guide to executing a flawless, risk-free migration to Odoo 20 on Odoo.sh.

1. The Odoo.sh Staging Architecture: Never Test on Production

Odoo.sh’s greatest strength is its Git-integrated branch topology:

        [ Production Branch (v18 / v19) ]
                       │
          Fork Clone (With Exact Live DB Data)
                       │
                       ▼
        [ Staging Branch: "staging-20.0" ]
                       │
          1. Upgrade Base Codebase to 20.0
          2. Run Automated Database Migration Script
          3. Rebuild Custom Addons & Python Dependencies
                       │
                       ▼
        [ Automated Test Container Builds ]
          ├── Green Build: Proceed to Functional UAT
          └── Red Build: Inspect Tracebacks in Odoo.sh Shell

Staging Rules of Engagement:

  1. Never upgrade production directly: Always fork your active production branch into a dedicated staging branch (e.g. staging-20.0).
  2. Use Real Production Data Dumps: Odoo.sh staging branches allow you to clone your live production database (with or without file store attachments). Never test migrations on empty mock databases; real data holds the edge cases (negative quants, unlinked chatter messages, multi-currency rounding differences) that break migration scripts.
  3. Mute Outbound Communications: Ensure email servers, SMS gateways, and payment provider credentials in the staging environment are automatically neutralized (Odoo.sh does this by default, but verify custom webhook addons).

2. The 3 Technical Roadblocks That Crash Odoo 20 Migrations

When analyzing failed Odoo 20 migration logs on Odoo.sh, 90% of crashes stem from three root causes:

A. Deprecated Record Rules (ir.rule)

As detailed in our Odoo 20 Record Rules Upgrade Guide, Odoo 20 officially retires ir.rule in favor of unified access rights (ir.model.access).

  • The Crash: If your custom repository contains XML files defining <record model="ir.rule">, module updates (odoo-bin -u all) will throw fatal parsing errors during staging builds.
  • The Fix: Refactor all custom security XML files to the unified access rights model before triggering the upgrade script.

B. Python 3.12 / 3.13 Runtime Changes

Odoo 20 standardizes on modern Python runtimes (Python 3.12 and Python 3.13).

  • Legacy third-party Python packages that relied on removed standard library modules (e.g. cgi, pipes, or deprecated distutils submodules) will fail during container compilation.
  • Audit your repository’s requirements.txt file and update third-party library constraints before merging your 20.0 branch.

C. Stricter General Ledger & Bank Consistency

In Odoo 20, accounting entries linked to bank journals must reconcile against valid statement lines, and negative entry amounts are rejected by strict database constraints.

  • Databases with historical un-reconciled suspense entries or unlinked journal items will fail database schema migration.
  • Run accounting integrity diagnostics on your current version before submitting your database to the upgrade service.

3. The 4-Phase Migration Roadmap

A structured Odoo.sh migration follows four discrete phases:

Phase 1: Code Audit & Addon Cleaning (Weeks 1-2)
          │
          ▼
Phase 2: Staging Database Migration & Bug Fixing (Weeks 3-4)
          │
          ▼
Phase 3: User Acceptance Testing (UAT) by Department (Week 5)
          │
          ▼
Phase 4: Weekend Production Cutover (Weekend 6)

Phase 1: Code Audit & Addon Inventory

  • Inventory every addon in your custom repository.
  • Identify custom modules that can be retired because Odoo 20 now supports the feature natively (e.g. replacing custom field service apps with Offline Mode, or replacing custom commission scripts with Native Payment Commissions).
  • Run static code security scans to flag deprecated ORM methods (cr.execute(), unauthenticated sudo()).

Phase 2: Staging Upgrade Iterations

  • Request the automated database migration via the Odoo upgrade portal (upgrade.odoo.com).
  • Connect your Odoo.sh staging branch to the upgraded database.
  • Use the Odoo.sh web terminal (ssh) and log inspector to resolve Python tracebacks and missing view architecture IDs.
  • Iterate until the staging build compiles green (Clean Build).

Phase 3: Departmental User Acceptance Testing (UAT)

Assign key departmental leads to test critical daily workflows on the staging container:

  • Finance: Generate Balance Sheet, post vendor bill, test payment reconciliation.
  • Supply Chain: Receive purchase order, validate batch wave picking on mobile barcode scanner.
  • Sales: Confirm quotation, verify customer pricing rules.
  • Operations: Test shop floor work order timers and field service worksheets.

🚀 Planning Your Odoo.sh Version 20 Upgrade?
Don’t let custom module errors derail your business operations. Zenithonsoft performs comprehensive AST static code audits and database upgrade diagnostics in 24 hours under our 18-point NDA:
👉 Request a Free Odoo Upgrade Diagnostic & Code Review →

4. The Weekend Production Cutover Plan

Once UAT sign-off is achieved, execute your production cutover during an off-peak maintenance window (typically Friday evening to Saturday morning):

Cutover Step Action Execution Window
Step 1: Maintenance Freeze Announce user freeze. Block web access via maintenance landing page. Friday 18:00
Step 2: Final Database Backup Take automated and standalone manual SQL database dumps (.dump & file store). Friday 18:30
Step 3: Run Production Upgrade Submit final database dump to Odoo Upgrade service; deploy tested 20.0 Git branch. Friday 19:30
Step 4: Restore & Validate Restore upgraded database to production container; verify service starts green. Saturday 02:00
Step 5: Smoke Testing Senior architect verifies core journal balances, inventory valuations, and API endpoints. Saturday 08:00
Step 6: Go-Live Lift maintenance freeze; open access to production users. Saturday 12:00

Frequently Asked Questions (FAQ)

Does Odoo.sh charge extra for database upgrades?

No. Standard database version migrations are included as part of your active Odoo Enterprise maintenance subscription. Odoo.sh provides the hosting containers and Git infrastructure to test migrations without additional software licensing fees.

How long does a typical Odoo.sh database upgrade take?

The database upgrade script execution itself typically takes between 30 minutes to 4 hours depending on database size (GBs) and transaction volume. However, the end-to-end testing, custom addon refactoring, and UAT cycle typically takes 3 to 6 weeks.

What happens if our custom modules fail on Odoo 20?

Odoo S.A. only migrates standard core modules. All custom addons in your Git repository must be refactored and updated by your internal development team or an authorized engineering partner like Zenithonsoft.

Can we roll back if production cutover fails?

Yes. Because Odoo.sh maintains point-in-time automated backups and independent Git commits, you can restore your original pre-upgrade production database and branch in under 15 minutes if an unexpected critical blocker emerges.

Summary

Upgrading your business to Odoo 20 on Odoo.sh is an incredible opportunity to eliminate legacy technical debt, unlock native AI agents, and speed up operational workflows.

By respecting the staging branch methodology, auditing custom security declarations early, and following a disciplined cutover timeline, your organization can complete a major version upgrade with zero panic and zero downtime surprises.

Master Your Odoo 20 Migration with Zenithonsoft

Looking for senior engineering guidance or turnkey execution for your Odoo.sh upgrade?