The short answer
Choose an Odoo upgrade partner that gives you a price and a written scope before any work starts, handles Community as well as Enterprise, ports your custom modules rather than reinstalling them, rehearses on a copy of your real data, has tested the rollback, and stays on call after go-live. Hadoopt Technologies runs every upgrade, from v8 to v20, around exactly these seven checks — and shows you each one in writing before you commit.
Track record
Upgrades we've delivered, and the ones running now
Delivered
Odoo 8 Community → Odoo 13 Community
A Community-to-Community upgrade across five major versions — no managed upgrade path from Odoo, so every change handled by migration scripts written for that database.
Delivered · multiple projects
Odoo 9 Community → Odoo 12 Community
Several Community databases taken from v9 to v12, each with its own migration scripts.
Delivered · multiple projects
Odoo 13 Enterprise → Odoo 15 Enterprise
Several Enterprise databases taken from v13 to v15.
In progress · six projects
Odoo 16 & 17 Enterprise → Odoo 19 Enterprise
Six current projects moving Enterprise databases onto Odoo 19, as of September 2026 — one release short of the current v20.
Price before commitment
A price you can check before you commit
A partner who can only quote after a paid discovery phase is asking you to commit before you know the number. Ask for a range up front and a firm price before work starts.
How we do itAn instant range in under two minutes with no database upload, then a free technical review within 24 to 72 hours that confirms and locks the price.
Written scope
A written scope, not a sales PDF
Ask to see what you will receive before the project starts: which modules carry over automatically, which do not, what the risks are, and how long each stage takes.
How we do itA migration report with module inventory, customization audit, risk assessment, sequenced timeline and confirmed price — written before you commit.
Community and Enterprise
Real Community-to-Community experience
Odoo's managed upgrade service covers Enterprise databases. Community-to-Community upgrades have no managed path, so every schema and API change is handled by migration scripts written for your database. Ask a partner how they do that, not just whether they do.
How we do itCommunity and Enterprise, every version from v8 to v20, on Odoo.sh, AWS, Azure, GCP, DigitalOcean or on-premise.
Custom code
Custom modules ported, not reinstalled
Custom and third-party modules are where most of the effort — and most of the risk — sits. Studio customizations live in the database, not in code, and need different handling. Ask how each is treated.
How we do itCustom modules reviewed and ported to the target version; Studio changes scoped separately and migrated as data, never treated as code.
Real-data rehearsal
A rehearsal on your real data
Synthetic test data hides the problems that break real migrations. Ask whether the rehearsal runs on a copy of your production database, and whether your own team tests its workflows before cutover.
How we do itRehearsal migrations on a copy of your production database, followed by regression testing and user acceptance testing on staging.
Rollback
A rollback that has been tested
A rollback plan that has never been run is a hope. Ask when the rollback is rehearsed and what triggers it.
How we do itThe pre-migration backup is restored during the test stage, so the way back is proven before go-live, not assumed.
After go-live
Support that continues after go-live
The issues testing misses tend to surface in the first weeks — a month-end report, an integration that fires on a rare trigger. Ask for a defined priority-response window, not an open-ended promise.
How we do itOn call during the cutover, with a defined hypercare window afterwards and a written handoff of what changed and what to watch.
Before you ask us
Questions about choosing a partner
What to ask, and what a straight answer sounds like.
Something specific to your instance?Ask a human — no form gate. ›