Migrations & Upgrades
Odoo 13 to 17 Migration
Odoo 13 systems are veterans: pre-OWL frontend, pre-redesign interface, years outside the support window. If you’re running one, it’s because it was built well and did its job, and because migrating felt daunting. Fair on both counts, and the jump to a modern version is entirely doable with the right process.
This is genuinely a re-implementation-scale project, and pretending otherwise is how these migrations fail. We plan them as what they are.
What moves, and how
- The scale, honestly. Four-plus major versions of framework change: the JavaScript layer was rewritten (OWL), views and reporting evolved, and standard workflows shifted. Custom frontend code from 13 gets rewritten, not patched; backend logic ports with care.
- Feature absorption is huge here. A large share of 13-era customisations exist because 13 couldn’t do things 17 does natively. The audit typically retires a satisfying chunk of your custom code, permanently lowering maintenance cost.
- Data migration path. Standard data migrates through the official upgrade chain reliably even across this span; custom models and fields get explicit mapping and reconciliation. Deep history versus read-only archive is a scoped decision.
- Process discipline matters most. Full staging rehearsal with production data, workflow-by-workflow validation checklists, phased training, planned cutover with rollback. The bigger the jump, the more the process is the product.
- Why 17 as the target. For very old systems, 17 (rather than 19) is sometimes the pragmatic target when key third-party modules lag; otherwise we’ll recommend the newest version your stack supports. The audit decides with evidence.
How a version upgrade runs
- Upgrade audit first. Every customisation, third-party module and data object inventoried and sorted: port it, drop it, or replace it with what newer Odoo now does natively. The audit report is the basis for the quote, and it’s yours whether or not you proceed with us.
- Fixed quote with an hours breakdown per module. The number arrives after the audit, not before, because guessing at an upgrade is how projects overrun. Deprecated features get flagged as decisions rather than surprises at go-live.
- Full rehearsal on staging with production data. The migration runs end to end on a staging copy, and your team runs real workflows against a sign-off checklist until nothing surprises them.
- Reconciliation before trust. Record counts and value checks per model prove the data crossed intact. Evidence, not assurance.
- Planned cutover with a rollback path. A scheduled window around your trading calendar, a step-by-step runbook, and a tested way back if the window goes wrong.
Common questions
Is it cheaper to re-implement fresh than migrate?
Sometimes genuinely yes, especially if processes have drifted far from the old build. We cost both paths in the audit and recommend the cheaper honest one; we have no preference between selling you a migration or an implementation.
How long does a jump this size take?
Months, not weeks, for a customised system: audit, port/rebuild, migrate, rehearse, train, cut over. You'll get the plan with phases and hours before committing.
Can we keep trading during the project?
Yes, everything happens on staging until the rehearsed cutover window, which we schedule around your trading calendar.
Not sure where to start? Book a free discovery call and we’ll map your current setup, or request a free Odoo health check if you’re already running Odoo.