Guides

How to Migrate Odoo Data Without Losing Customisations

The fear that stalls most Odoo upgrades: ‘we’ll lose the custom work that makes the system ours.’ Legitimate fear, solvable problem. This guide covers how customisations actually survive migration: triage, porting, testing and the reconciliation that proves nothing was lost.

We’ve done this across every span from single-version hops to 13-to-17 scale jumps, including custom accounting logic that’s crossed four majors live.

What it takes in practice

  • Inventory everything first. Every custom module, Studio tweak, third-party app and integration, listed with its business purpose. Undocumented customisations are the ones that get lost; the inventory is your insurance.
  • Triage into three piles. Port (still needed, no standard equivalent), retire (newer Odoo does it natively), replace (a maintained OCA/store module now covers it). Typically a third of custom code retires happily, which permanently cuts future costs.
  • Port with the framework, not against it. Porting means adapting to the target version’s APIs and patterns properly, not shimming old code to limp along. Shims compound; clean ports amortise.
  • Migrate custom data explicitly. Custom fields and models don’t migrate themselves: each needs mapping into the target schema with count and value reconciliation proving completeness.
  • Test customisations against real workflows. Staging rehearsal runs your actual processes (the ones the customisations serve) with production data. Acceptance is workflow-by-workflow sign-off, not ‘it installed without errors’.
  • Document what survived and why. The migration ends with an updated customisation register: what exists, what it does, which version it targets. The next migration starts from knowledge instead of archaeology.

How we’d de-risk this for you

The nightmare version of this project is discovering what broke at go-live. We remove that by running the whole migration on a staging copy first, testing every customisation against real workflows, and proving with record counts and value checks that nothing was lost before the cutover. You get the audit and the decision list up front, and a tested rollback path for the day itself. See Odoo migration services.

Common questions

Our original developer is long gone and nothing is documented.
Common. The audit reconstructs purpose from code and user interviews; it takes longer but works. You exit with the documentation you should have had, which is half the project's value.
Can Studio customisations migrate?
Studio changes are data-level and mostly migrate, but they deserve the same triage: plenty of Studio tweaks exist because a past version lacked something the new one has.
What proves nothing was lost?
The reconciliation pack: record counts and value checks per model, plus workflow sign-offs per department. Evidence, not assurance.
Can we keep trading during the upgrade?
Yes. The migration runs on a staging copy while your live system keeps working, and the only interruption is the planned cutover window, scheduled around your quiet hours.

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.

Next step

Ready to fix your ops?

Book a free discovery call. We'll look at your current setup and tell you honestly whether Odoo is the right move and what it would involve.