“Odoo migration” means different things depending on who you ask. For some, it's upgrading from Odoo 17 to 18. For others, it's moving their entire instance to a different cloud provider. And for Odoo.sh customers hitting cost limits, it's switching to self-hosted infrastructure. Each scenario has different risks, timelines, and procedures.
3 Types of Odoo Migration
Before you plan anything, figure out which type of migration you're dealing with. Each requires a different approach.
Upgrade your Odoo software to a newer release. Involves database schema changes, module compatibility checks, and custom code updates. The most technically involved type of migration.
Move your existing Odoo instance to a different server or cloud provider. Same version, same data, new infrastructure. Common when switching providers for cost or performance reasons.
Leave a managed platform like Odoo.sh and run Odoo on your own infrastructure. Requires exporting your database and filestore, setting up a new server, and reconfiguring your deployment pipeline.
Version Upgrade: What's Involved
A version upgrade touches every layer of your Odoo instance. The database schema changes between versions, module APIs shift, views get restructured, and custom code may need updates.
Version Compatibility Matrix
| Source | Target | Direct Upgrade? | Notes |
|---|---|---|---|
| Odoo 14 | Odoo 15 | Yes | End of life. Upgrade recommended. |
| Odoo 15 | Odoo 16 | Yes | End of life. Upgrade recommended. |
| Odoo 16 | Odoo 17 | Yes | Stable upgrade path. |
| Odoo 17 | Odoo 18 | Yes | LTS target. Recommended for production. |
| Odoo 18 | Odoo 19 | Yes | Latest release. AI agents, industry packages. |
| Odoo 16 | Odoo 18 | No | Must go 16 → 17 → 18 sequentially. |
| Odoo 17 | Odoo 19 | No | Must go 17 → 18 → 19 sequentially. |
Sequential upgrades only. Each version must be completed before starting the next. Running 14 to 19 means five separate upgrade cycles.
Server Migration: Moving to a New Host
Server migration is the simplest type: same Odoo version, same data, new infrastructure. People do this when switching cloud providers, moving to a region closer to users, or upgrading to a more powerful server.
Set up the target server
Provision a new server with the same Odoo version, PostgreSQL version, and module set. Match the Python version and system dependencies. OEC.sh automates this: connect your cloud account and deploy.
Database dump and restore
Run pg_dump on the source database, transfer the dump file to the new server, and restore with pg_restore. For large databases (10GB+), use the custom format (-Fc) and parallel restore (-j 4) to speed things up.
Copy the filestore
Rsync or SCP the entire filestore directory to the new server. This includes all attachments, images, and uploaded files. Miss this step and your Odoo instance will look broken because records reference files that don't exist.
Verify and test
Start Odoo on the new server with the restored database. Test critical workflows: login, sales orders, invoices, reports, email sending. Check that all attachments load correctly.
DNS cutover
Lower TTL to 300 seconds 24 hours before the move. When ready, freeze writes on the old server, take a final dump, restore on the new server, update DNS, and verify propagation.
Platform Migration: Leaving Odoo.sh
Odoo.sh is convenient, but it gets expensive at scale and limits your infrastructure choices. Moving to self-hosted Odoo on your own cloud account saves 40-70% on monthly costs and gives you full control.
For a detailed walkthrough with screenshots and specific commands, see our dedicated Migrate from Odoo.sh guide.
Migration Planning Checklist
No matter which type of migration you're doing, these three phases keep things organized and reduce risk.
Pre-Migration
During Migration
Post-Migration
Common Migration Pitfalls
These mistakes cause the most damage during migrations, and all of them are preventable.
| Issue | Impact | Prevention |
|---|---|---|
| Custom module incompatibility | Upgrade fails or produces errors after migration | Audit all custom modules before starting. Test each against the target version in staging. Budget time for code updates. |
| Missing filestore in backup | All attachments, images, and uploaded files disappear | Always backup the filestore directory alongside the database dump. Verify the backup includes /var/lib/odoo/filestore/ or your custom path. |
| PostgreSQL version mismatch | Database restore fails or produces encoding errors | Match PostgreSQL major versions between source and target. If upgrading PostgreSQL, do it as a separate step, not simultaneously with Odoo. |
| DNS propagation delays | Users hit the old server for hours after cutover | Lower DNS TTL to 300 seconds (5 min) at least 24 hours before migration. Verify propagation with multiple DNS checkers before decommissioning. |
| Skipping the staging test | Discover problems in production with no rollback | Always run the full migration on a staging copy first. Verify all workflows, reports, and integrations before touching production. |
| Data freeze window too short | Users modify data during migration, causing inconsistencies | Communicate the maintenance window clearly. Block write access during database dump/restore. Keep the window as short as possible. |
Odoo Version Upgrade Paths
Knowing what changed in each version helps you assess the scope of your upgrade and prepare for module compatibility issues.
Odoo 17 to 18
- Manufacturing module overhaul with improved work center scheduling and MRP planning
- Point of Sale redesign with faster checkout and offline support improvements
- Accounting: new bank reconciliation engine with auto-matching
- Website builder performance improvements and new themes
- Long-Term Support (LTS) release with extended maintenance window
Odoo 18 to 19
- AI agents across modules: automated data entry, smart suggestions, anomaly detection
- Industry-specific packages pre-configured for manufacturing, retail, services
- Revamped spreadsheet integration with real-time ERP data
- Improved multi-company workflows and inter-company transactions
- Performance optimizations reducing page load times by 20-30%
For detailed feature breakdowns, see our Odoo 18 LTS and Odoo 19 pages.
How OEC.sh Simplifies Migration
OEC.sh doesn't run Odoo's version upgrade scripts for you (those are Odoo-specific and depend on your database). What it does is eliminate the infrastructure complexity that makes migration risky and time-consuming.
- Clone production to staging in one click. Test the full migration without risking live data
- Provision a new server in 5 minutes on your own cloud account, no manual setup
- Automated backups before, during, and after migration. Rollback is always available
- Deploy the same Odoo configuration to the new server with no config drift
- Built-in monitoring to verify the new instance is healthy post-migration
- DNS management to handle cutover with minimal downtime
The biggest migration risk is doing it on live infrastructure with no rollback. OEC.sh gives you a safety net: clone your instance, test the migration, then cut over when ready. If anything goes wrong, your original production instance is untouched.
Frequently Asked Questions
How long does an Odoo version upgrade take?
A straightforward version upgrade (e.g., Odoo 17 to 18) with no custom modules typically takes 2-8 hours including testing. With custom modules, budget 1-4 weeks for code updates, compatibility testing, and staged rollout. Database size matters too: a 50GB database takes longer to transform than a 5GB one.
Can I skip Odoo versions when upgrading?
No. Odoo supports sequential upgrades only (16 to 17, then 17 to 18, then 18 to 19). Each version upgrade applies specific database schema changes that build on the previous version. Skipping versions risks data corruption and broken module dependencies.
Will I lose data during an Odoo migration?
Not if you follow proper procedures. Take a full backup (database + filestore) before starting. Test on a staging copy first. The most common cause of data loss is forgetting the filestore, since the database dump alone does not include attachments, images, or uploaded documents.
How do I migrate from Odoo.sh to self-hosted?
Export your database and filestore from the Odoo.sh dashboard, set up a new server with the same Odoo version and modules, restore the database, copy the filestore, verify module compatibility, and update DNS. OEC.sh automates the server setup portion. See our detailed guide at /migrate/from-odoo-sh.
What is the difference between Odoo migration and Odoo upgrade?
People use the terms interchangeably. Technically, 'upgrade' means moving to a newer Odoo version (e.g., 17 to 18), while 'migration' covers any move: version upgrade, server change, or platform switch. This guide covers all three.
Does OEC.sh handle Odoo migration automatically?
OEC.sh automates the infrastructure side: provisioning servers, deploying Odoo, cloning production to staging, and managing DNS. Database schema changes for version upgrades still run through Odoo's upgrade scripts. OEC.sh gives you a safe staging environment to test upgrades before cutting over production.
Migrate Odoo Without the Risk
Clone your production instance to staging, test the migration, and deploy to a new server on your own cloud account. Free plan available.