How to Update Odoo Database: Complete Step-by-Step

Updating your Odoo database means upgrading your business data to a new Odoo version--from v18 to v19, or across multiple versions. This is a structured migration, not a simple swap. Your data schema transforms, custom modules are tested, and nothing goes live until everything works. When done correctly, you keep all your data intact. When rushed, you risk downtime and data loss.

Why Database Updates Matter (and Aren't as Scary as You Think)

Odoo releases a major new version every year. Each version includes bug fixes, security patches, and new features. If you're running v16 or older in 2026, you're paying a 25% surcharge for legacy support--and it's only temporary. Updates are not optional: they're a cost of using business software.

But here's what makes teams nervous: your database is live. Your sales team is in it right now. Your accounting data lives there. The upgrade process feels risky because it IS--if done carelessly. The good news: the process itself is mature, tested, and well-documented. Thousands of companies upgrade their Odoo databases every month without incident. The difference between them and companies that struggle is preparation, not luck.

Odoo officially supports three upgrade paths: online (SaaS), Odoo.sh (managed PaaS), and self-hosted. Each has different complexity, different risk, and different lead times. Knowing which one you're running shapes the entire procedure.

What to Know Before You Update: Hosting Types & Complexity

Your hosting model determines your update path. Here's the reality:

Odoo Online (SaaS): Odoo handles everything. You get a staging environment, you test, you click upgrade. No servers, no command-line, no filestore management. This takes 1-2 hours including testing. Complexity: minimal.

Odoo.sh (Managed): You control code (via git branches), Odoo controls infrastructure. Backup and restore are built in. You can test on a staging branch before merging to production. Complexity: medium. Requires git literacy but abstracts away server management.

Self-Hosted: You own the entire stack--server, database, filestore, code, backups. Upgrading means running commands, managing migrations, testing locally, and cutting over yourself. Complexity: high. A mistake here can lock you out of your own database.

The official Odoo Upgrade Service is free for Enterprise customers. Community users can use OpenUpgrade (open-source, community-maintained) or pay for a partner to handle it. Most teams on Odoo Online don't touch the upgrade process directly; it's nearly automatic. Most teams on self-hosted spend 2-4 days testing before going live.

Backup Your Database: The Non-Negotiable First Step

Before any upgrade, back up your database. This is your safety net. If the upgrade fails, a rollback saves you.

For Odoo Online: Odoo maintains daily backups automatically. You can also download a backup manually from Settings > Database Backup. Do this now. Keep it somewhere safe, outside your Odoo account. This takes 10 minutes.

For Odoo.sh: Backups are automatic and versioned in git. Before upgrading, tag your current branch with a backup name (e.g., git tag backup-before-v19). You can restore this tag instantly if needed. This takes 5 minutes.

For Self-Hosted: You need three backups:

Database dump (SQL): pg_dump -U odoo dbname > backup.sql
Filestore folder: tar -czf filestore-backup.tar.gz /var/lib/odoo/filestore/
Custom modules folder: tar -czf custom-addons-backup.tar.gz /var/lib/odoo/addons/custom/

Copy all three to an external drive or cloud storage. Do not skip this. If the upgrade corrupts your database, you'll need the SQL dump to recover. This takes 30 minutes.

Verify your backup works by attempting a partial restore. If you can't restore it, it's not a backup--it's just a file.

Updating on Odoo Online: The Easiest Path

Odoo Online handles 95% of the upgrade logic for you.

Step 1: Go to Settings > System Updates. You'll see your current version and available upgrades.

Step 2: Click "Prepare Update." Odoo creates a staging copy of your database (same data, separate environment). This takes 15-30 minutes depending on your database size. You can access the staging version instantly at a separate URL.

Step 3: Test the staging database thoroughly. Run your most critical workflows: create an invoice, post a payment, run a sales report, check custom fields, test integrations. If your integrations broke, you'll know here, not in production. Spend 30-60 minutes testing.

Step 4: If everything works, click "Apply Update" in production. Odoo stops your current database, runs the upgrade process (15-30 minutes), and brings it back online. Your users will see a maintenance message during this window.

Step 5: After the upgrade completes, log in immediately and run the same tests on production. The upgrade is irreversible once committed, but Odoo's tools are reliable enough that issues are rare. This takes 20 minutes.

Total time: 2-3 hours including testing. Downtime: 15-30 minutes.

Updating on Odoo.sh: Medium Complexity

Odoo.sh is a middle ground: managed infrastructure but version-control workflows.

Step 1: Create a staging branch. In your Odoo.sh console, create a new branch (or use an existing staging branch). Ensure it's synchronized with your production database state.

Step 2: Update the branch's __manifest__.py or version file to the new Odoo version. Commit and push to git. Odoo.sh detects the change and rebuilds the environment.

Step 3: Test on the staging branch. Run your critical workflows. Custom modules should be re-tested because Odoo.sh's database state is a copy, not live data. Spend 1-2 hours testing.

Step 4: When ready, create a pull request or merge request from staging to production. Before merging, review which modules are being installed/removed. Merge to production.

Step 5: Odoo.sh performs the upgrade on production (15-30 minutes). Your site goes offline briefly. After the upgrade, test production immediately.

Total time: 4-6 hours including testing. Downtime: 15-30 minutes.

Updating Self-Hosted Odoo: The Full Walkthrough

Self-hosted upgrades are the most hands-on. You need server access, database admin rights, and time.

Step 1: Backup (again) - You already backed up, but backup once more before touching anything. Database dumps can be large; if your database is 50GB, this takes 1-2 hours.

Step 2: Set up a staging environment - If possible, clone your production server to a separate staging server. If that's not feasible, create a separate PostgreSQL database on the same server (copy the production database). This ensures you test with real data, not a snapshot.

Step 3: Update Odoo code - Download or pull the new Odoo version to your staging directory. For v18 to v19, this means downloading the v19 codebase. Do NOT overwrite your production code yet.

Step 4: Run the upgrade - On the staging environment, run:

odoo-bin -d staging_db --upgrade all -i base --stop-after-init

This command tells Odoo to upgrade the database and install/update all modules. The process runs 30-60 minutes depending on database size and custom modules. Watch the logs for errors.

Step 5: Test staging thoroughly - Logging in is not enough. Test:

Sales workflows (create quote, convert to order, generate invoice)
Accounting (post journal entries, reconcile bank statements, generate reports)
Custom reports and fields
Integrations (API calls, webhooks, third-party app connections)
User roles and permissions

This should take 2-4 hours. If an error appears, you have a record of it and can roll back to your backup without production impact.

Step 6: Upgrade production - Once staging passes all tests:

Stop the production Odoo service: systemctl stop odoo
Backup the production database one final time
Swap your production code for the new version
Run the upgrade command on production (same as step 4)
Start the production service: systemctl start odoo
Test production immediately

Total time: 1-2 days including testing. Downtime: 1-2 hours during the upgrade window.

Testing Your Upgraded Database: Pre-Go-Live Checklist

After the upgrade completes (on any platform), you must test before users access the system. Here's a checklist:

Functional Tests:

Create a sales order, confirm it, generate a delivery, create an invoice, register payment. This tests the core sales cycle.
Create a purchase order, receive goods, generate an invoice, post it. This tests procure-to-pay.
Reconcile a month's bank statements using the reconciliation tool.
Run your most critical reports (sales by product, aging report, cash flow forecast).
Test any integrations: Stripe, PayPal, Shopify, Slack, ERPNext, or custom APIs.

Data Integrity Tests:

Check that customer counts, product counts, and invoice counts match your pre-upgrade expectations. A quick SQL query helps: SELECT COUNT(*) FROM res_partner WHERE customer=true;
Verify that multi-currency transactions are still correct if you use them.
Check that archived records are still archived.

Permissions Tests:

Log in as a salesperson, warehouse manager, accountant, and admin. Verify each role sees what they should and can't access what they shouldn't.
Test any custom access rules or field-level permissions.

Custom Code Tests:

If you have custom modules, run their automated tests if they exist.
Trigger any automated workflows (e.g., invoice reminders, stock reorder alerts) and confirm they execute.

UI/UX Tests:

Walk through the web interface. Buttons should work, forms should save, dashboards should load.
Test on mobile if your team uses the mobile app.

If any test fails, do not go live. Roll back to your backup, fix the issue (or contact your Odoo partner), and test again. This process catches 90% of upgrade problems before they hit your production users.

Common Update Errors & How to Fix Them

Error: "Module X not found" - A custom module was deleted or moved. Check that all custom modules are in the correct directory and that their __manifest__.py file lists dependencies correctly. If the module is no longer needed, remove it from the --upgrade command.

Error: "Database version mismatch" - Your database version doesn't match the Odoo version you're running. This usually means the upgrade process was interrupted. Restore from your backup and try again.

Error: "Filestore out of sync" - After upgrading, attachments or images don't load. The filestore folder wasn't copied correctly during migration. Ensure the filestore path in your Odoo config matches the location of your backed-up filestore.

Error: "Timeout during upgrade" - Large databases can exceed default timeout limits. Increase the upgrade timeout in your Odoo configuration or run the upgrade during an off-hours window when the database is quieter.

Custom module breaks after upgrade - Custom code written for v18 may not work on v19. Common causes: ORM API changes, security rules, deprecated methods. The module's developer (or an Odoo partner) needs to review the code and adapt it to the new version. This is why you test on staging first.

Why Managed Hosting Removes This Burden

If you're using Odoo Online or Odoo.sh, you skipped most of the above complexity. That's not an accident--it's by design. When you use Opsily's managed Odoo hosting on Odoo Online or Odoo.sh, you eliminate database backup management, filestore synchronization, and custom server configuration. You focus on testing your business workflows, not on infrastructure.

For teams running self-hosted Odoo, the upgrade process is a tax on your infrastructure. Every version bump means downtime, staging environment management, and rollback preparation. As your team grows, that tax gets higher. Switching to managed hosting (Odoo Online, Odoo.sh, or a managed cloud host like Opsily) removes the upgrade complexity entirely. You test, you click upgrade, and your host handles the rest.

The tradeoff is cost: managed hosting costs more per month than self-hosted. But that cost includes backup management, automated updates, security patches, and infrastructure scaling. For most growing teams, that's a bargain compared to the engineering time spent on infrastructure.

Frequently Asked Questions

What is the difference between Odoo Online, Odoo.sh, and self-hosted upgrades?

Odoo Online upgrades are fully managed by Odoo (click a button, test staging, approve production). Odoo.sh upgrades use git version control but are still managed (Odoo runs the database migrations). Self-hosted upgrades are manual and require server access and database administration skills.

Can I upgrade my Odoo database without losing data?

Yes, if you follow the process. Backups protect you. The upgrade process transforms your data schema but does not delete records. Custom data fields are preserved. If something fails, you restore the backup and try again.

How long does an Odoo database upgrade take?

Odoo Online: 2-3 hours including testing. Odoo.sh: 4-6 hours. Self-hosted: 1-2 days. Most of the time is testing, not the upgrade itself (which takes 15-30 minutes).

What happens to custom modules during an upgrade?

Odoo attempts to re-install custom modules on the new version. If a module's code is incompatible (rare), it fails and you'll see an error. That's why you test on staging first. Your Odoo partner can adapt the code if needed.

How do I test an upgrade before going live?

Use staging: Odoo Online provides a staging database, Odoo.sh uses git branches, self-hosted uses a cloned database. Run your critical workflows (sales, invoicing, accounting). Test integrations. Check permissions. If it works in staging, it'll work in production.

When is it safe to upgrade to a new Odoo version?

Odoo supports each major version for 3 years. Versions older than 3 years carry a 25% legacy support surcharge. Versions younger than 6 months may have new bugs. The sweet spot: upgrade 6-12 months after a major version releases.

What is the Odoo Upgrade Service vs. OpenUpgrade?

The Odoo Upgrade Service is official, free for Enterprise users, and handles the migration on Odoo's infrastructure. OpenUpgrade is open-source, community-maintained, and free but requires more manual work. Community users typically use OpenUpgrade or hire a partner.

Can I downgrade after an upgrade?

No. Odoo upgrades are one-way. Once you upgrade from v18 to v19, there's no downgrade path. That's why staging testing is critical--it's your only chance to catch problems before committing.

The Bottom Line

Odoo database updates are not risky if you follow a process: backup, test on staging, approve for production. The process differs by hosting type--Odoo Online is nearly automatic, Odoo.sh is semi-automatic, self-hosted is manual--but the principle is the same. Test before you commit.

The real cost is time: 2-3 hours for a managed platform, up to 2 days for self-hosted including testing. If your team runs self-hosted Odoo, consider whether that upgrade tax is worth the infrastructure control. For most teams, Opsily's managed Odoo hosting eliminates the complexity. Start exploring your options at our Odoo hosting page to compare.

How to Update Your Odoo Database: Step-by-Step Guide