Moving an older Odoo implementation to Odoo 20 is not simply the same upgrade with a larger version number.
The more versions between the source system and Odoo 20, the more likely the project includes accumulated custom code, obsolete workarounds, old third-party modules, integration debt, stale configuration and business processes that have changed since the ERP was first implemented.
The right first step is therefore not estimating migration hours.
It is establishing what the current system really is.
Support-date note: Do not publish a hard-coded end-of-support or hosting cutoff from an old blog post. Odoo support/hosting timelines can change. Verify the current official Odoo support and hosting policy for the source version immediately before publication.
Why older-version upgrades are different
A recent-version upgrade may involve a relatively narrow framework delta.
An older implementation can contain years of:
- custom modules;
- Studio customization;
- inherited views;
- custom reports;
- scheduled/server actions;
- API integrations;
- accounting/localization behavior;
- data workarounds;
- abandoned features;
- manual processes built around system limitations.
Migrating all of that without challenging it can reproduce years of technical debt on a new version.
Phase 1 — Discover the actual system
Create an upgrade inventory.
Version and hosting
- source Odoo version;
- Community/Enterprise;
- Online/Odoo.sh/on-premise;
- infrastructure;
- database size;
- filestore size.
Customization
- custom addons repositories;
- third-party modules;
- Studio;
- custom views;
- reports;
- automation;
- security rules.
Integrations
- mobile apps;
- portals;
- payment;
- shipping;
- marketplace;
- attendance;
- BI;
- accounting/banking;
- middleware;
- APIs.
Business processes
Interview actual users.
Documentation written years ago may not represent how the system is used today.
Phase 2 — Classify every customization
Use four categories:
Keep
Still required and worth maintaining.
Replace with standard Odoo 20
The target version now solves the requirement natively.
Redesign
Requirement remains, but the old technical implementation is no longer appropriate.
Retire
Unused or obsolete.
This classification can reduce upgrade cost more than any code-migration shortcut.
Phase 3 — Identify version-gap hotspots
For a large version jump, review cumulative changes in:
- ORM;
- views;
- JavaScript/Owl;
- POS;
- website;
- reports;
- accounting;
- stock/MRP;
- API/integration layer;
- security;
- translations.
Do not assume a module can be migrated by fixing only the first version-to-version difference.
The target is Odoo 20 behavior.
Phase 4 — Review integrations before the test upgrade
Older integrations deserve special attention because their dependencies may be deprecated.
For example, current Odoo documentation says the legacy external RPC APIs are deprecated, the db service is removed in Odoo 20, and common/object are currently scheduled for removal in Odoo 22.
An older integration estate may also contain:
- unsupported client libraries;
- hard-coded passwords;
- admin users;
- obsolete TLS/network assumptions;
- undocumented cron scripts.
Treat integration modernization as its own workstream.
Phase 5 — Request a test upgrade
Follow Odoo’s current official process for the source version and hosting model.
Do not assume a path is available because Odoo 20 itself is released.
Once the test database exists:
- review Upgrade Report;
- inspect disabled views;
- deploy/migrate target-version custom code;
- handle filestore where applicable;
- begin business testing.
Phase 6 — Build a risk-based test plan
Prioritize workflows by business impact.
Tier 1 — business stopping
Examples:
- invoicing/accounting;
- sales/order fulfillment;
- warehouse;
- manufacturing;
- POS;
- payroll;
- critical external API.
Tier 2 — major operational impact
Examples:
- CRM automation;
- approvals;
- field service;
- purchasing;
- reporting;
- customer portal.
Tier 3 — lower impact
Examples:
- cosmetic view changes;
- convenience reports;
- non-critical automation.
Test depth should follow impact, not module count.
Phase 7 — Reconcile data
For older systems, sample records across time periods.
Check:
- very old historical records;
- currently open records;
- archived records;
- multi-company data;
- migrated custom fields;
- attachments;
- accounting balances;
- stock/valuation;
- taxes;
- users/security.
Historical data often reveals migration problems that new test records cannot.
Phase 8 — Decide what changes users need to learn
An upgrade across several versions can change workflows significantly even when custom code is minimal.
Plan:
- role-based release notes;
- short training;
- updated SOPs;
- screenshots;
- manager sign-off;
- hypercare/support after go-live.
Odoo’s standard technical upgrade scope should not be confused with user training/change management.
Phase 9 — Rehearse from a fresh production copy
A long migration project can drift.
Before production:
- request/create a fresh test upgrade;
- deploy the final target-version code;
- run migration scripts;
- run automated tests;
- run critical UAT;
- measure cutover time;
- document manual steps;
- validate integrations.
Do not estimate production downtime from the first migration attempt.
A practical complexity assessment
Instead of calling a project “easy/medium/hard” based only on database size, assess objective factors:
| Factor | Questions |
|---|---|
| Version gap | How many major versions? |
| Custom modules | How many, and how invasive? |
| Core overrides | Do they alter Accounting/Stock/MRP/HR? |
| Third-party apps | Are target versions maintained? |
| Integrations | How many external writers/readers? |
| Data | Volume, age, quality, attachments? |
| Multi-company | Shared products, currencies, inter-company flows? |
| Website/POS | Revenue-critical public/frontline workflows? |
| Testing | Are business owners available? |
| Documentation | Is current behavior documented? |
This produces a much better estimate than “X AED per module” or “two weeks per version.”
Common mistakes
- Migrating every old customization.
- Assuming database size equals complexity.
- Ignoring undocumented integrations.
- Combining hosting move, edition change, redesign and version upgrade without a reason.
- Testing only recent records.
- Underestimating user workflow change.
- Hard-coding support dates from stale sources.
- Setting a go-live date before the first realistic test upgrade.
Support status vs upgradeability
Do not confuse an unsupported version with an impossible upgrade.
Odoo's historical supported-version documentation explicitly states that older unsupported versions can still be upgraded. For a current project, verify the exact source-version support status and Odoo 20 target availability before promising a date.
Do you need to upgrade through every intermediate version?
For the standard database, use Odoo's current supported upgrade service/path for the source database rather than assuming each intermediate version must become a separate production deployment.
Custom code is different: developers still need to account for cumulative framework/application changes between the old implementation and Odoo 20.
Separate three layers:
- standard database upgrade;
- custom code/data migration;
- business-process acceptance.
Turn discovery into a real upgrade scope
After the inventory, produce four deliverables:
1. Application map
Every standard/custom/third-party module and whether it stays.
2. Integration map
Every external system, owner, protocol, credential model and test plan.
3. Business-process map
Critical flows by department and the people who will accept them.
4. migration backlog
Every code/data/configuration task required to reach Odoo 20.
This is the point where an estimate becomes defensible.
Decide whether to combine modernization work
An older-version project often exposes other desired changes:
- hosting migration;
- Community → Enterprise;
- chart/localization changes;
- company restructuring;
- website redesign;
- API modernization;
- data cleanup.
Combining everything can reduce duplicated effort, but it also multiplies variables during testing.
A useful rule:
combine changes when they are technically coupled; separate them when independent rollback/testing would reduce risk.
For example, an API migration forced by target-version compatibility may belong in the upgrade. A complete website rebrand usually does not need to share the same cutover.
Data cleanup: before or after?
Do not automatically clean every historical issue before upgrading.
Classify data problems:
- blocks the standard upgrade;
- breaks target-version business logic;
- creates legal/accounting risk;
- cosmetic/low-impact.
Fix blockers and correctness issues deliberately. Large optional cleanup projects can often be separated so they do not delay the version upgrade.
Create a go/no-go gate
Before production, require evidence:
- test upgrade completes;
- required custom modules pass;
- critical integrations pass;
- financial/stock reconciliation passes;
- Tier-1 workflows accepted by owners;
- production steps rehearsed;
- measured downtime fits the agreed window;
- support/hypercare team is available.
If a Tier-1 workflow has no owner or test result, the project is not ready merely because developers say the database starts.
Post-upgrade hypercare
For a large version jump, plan the first days after go-live.
Track:
- authentication/access issues;
- integration failures;
- scheduled jobs;
- accounting discrepancies;
- inventory exceptions;
- performance;
- user workflow confusion;
- errors/warnings.
Define severity and ownership before go-live so production issues do not become an unstructured group chat.
FAQ
Can an old Odoo database move to Odoo 20?
Potentially, but verify the current official upgrade path for the exact source version, edition and hosting model.
Do we have to upgrade through every intermediate version manually?
Do not assume either direction. Use Odoo’s current supported upgrade process for the exact source database. The engineering work for custom modules still needs to account for the cumulative target-version changes.
Is an older database harder because it has more data?
Data volume matters, but customization, integrations, business complexity and historical technical debt can matter more.
Should we rewrite custom modules or migrate them?
Classify them first: keep, replace with standard Odoo 20, redesign or retire.
Should we upgrade and redesign everything at once?
Usually separate risks unless there is a deliberate reason to combine them. A controlled upgrade with clearly scoped redesign is easier to test.
Can Odoo 14 be upgraded to Odoo 20?
Odoo documentation has historically stated that older unsupported versions can still be upgraded. Verify current Odoo 20 eligibility for the exact database and hosting model, then assess custom code/integrations.
Can Odoo 15 or 16 move to Odoo 20?
Use the current official upgrade path rather than assuming you must operate each intermediate version separately. Custom modules still need target-version migration.
What makes an old Odoo migration expensive?
Usually customization, third-party modules, integrations, data quality and business complexity—not simply database age or size.
Final takeaway
An older Odoo → Odoo 20 project is a modernization exercise, not merely a database conversion.
The best result is not “everything old survived.”
It is:
the business-critical behavior survived, obsolete customization disappeared, necessary customization was rebuilt on supported patterns, integrations have a clear future, and the team can operate confidently on Odoo 20.
Planning an Odoo 20 project? Octivex Tech helps businesses with Odoo upgrades, custom module migration, integrations and AI-enabled workflows. Explore our Odoo services or contact our engineering team to discuss your environment.