Odoo Migration & Upgrade
An upgrade is a rehearsal problem. The first conversion is never the one you go live on.
Safe database + code migration from Odoo 10 through 18 to the latest version, including custom modules, historical transactions, and user-uploaded attachments.
Two things move in an upgrade and they move differently. The database has to be converted so that older records still mean what they meant. The custom code has to be ported so it still attaches to a version of Odoo that has changed underneath it. Doing both at once, once, on the live system, is how upgrades earn their reputation.
We convert repeatedly instead. The first conversion exposes the data problems, the second proves the fixes, and by the final rehearsal the whole cutover is a script with known timings. Your team validates against a converted copy while the old system is still running, so sign-off happens before anything is at stake.
The honest part of the conversation is the custom code. Modules that extend standard behaviour port quickly. Modules that replace it, or that were written as edits to core, cost real money at every version, and an upgrade is the moment to decide whether they are still worth carrying. We report that per module before you commit.
What is included
- โ Database migration with zero data loss
- โ Custom module code migration
- โ Historical transaction validation
- โ Test environment for sign-off
- โ Cutover plan with rollback
- โ User retraining on new version
- โ Post-upgrade patch support
- โ Community โ Enterprise migration
How the engagement runs
- 1
Assessment
Know what you are actually upgrading before quoting a date.
- Inventory every installed module: standard, third-party and custom, with the source of each
- Check which third-party modules exist for the target version and which have no successor
- Read the custom modules and grade the porting effort per module
- Size the database, the attachments and the volume of open documents
- Identify features that changed behaviour between your version and the target
You end up with: A written assessment with per-module effort, the modules with no path forward, and a recommended target version.
- 2
First test conversion
Find the data problems while they are still cheap.
- Convert a copy of production and record every error and warning
- Fix data issues at source in the live system wherever possible, so the next conversion is cleaner
- Port the custom modules against the target version
- Record the conversion duration, which is the number the cutover window is built from
You end up with: A converted test database and a defect list split into data issues and code issues.
- 3
Functional validation
Let your team prove the converted system does what the old one does.
- Run your real processes end to end on the converted copy, not a demo script
- Compare key reports side by side against the old system for the same period
- Check the things upgrades break quietly: document layouts, access rights, scheduled actions, integrations
- Retrain on the behaviour that genuinely changed, rather than on everything
You end up with: A validation sign-off from the people who use each area.
- 4
Rehearsal
Turn the cutover into a script with known timings.
- Repeat the conversion on a fresh copy with every fix applied
- Time each step so the maintenance window is based on measurement, not on hope
- Write the runbook: who does what, in what order, with the rollback point marked
- Agree the go and no-go criteria in advance, and who calls it
You end up with: A rehearsed runbook with timings and a defined rollback point.
- 5
Cutover and stabilisation
Go live in the planned window and hold the system steady afterwards.
- Freeze the old system, take a full backup, run the conversion, verify against a checklist
- Smoke test the critical paths before users are let in
- Keep the old system readable but not writable for a defined period
- Daily triage for the first weeks, since some issues only surface with real volume
You end up with: A live upgraded system, a retained pre-upgrade backup, and a post-upgrade defect log.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ A full backup of the production database and filestore, plus the source of every custom module
- โ The list of third-party modules you paid for, with licences, so successors can be obtained
- โ Someone from each functional area to validate the converted copy against real work
- โ A decision on the maintenance window, agreed against your operating calendar
- โ Credentials for every integration, since these need retesting after conversion
- โ Agreement on which unused modules can be dropped rather than ported
Decisions you will be asked to make
Which version to land on
The newest is not automatically right. What matters is whether your third-party modules exist there, and how long you want before the next upgrade. We give you the trade-off per module rather than a preference.
Which custom modules to retire
Some custom code exists because the version you are on lacked a feature the target version now has as standard. An upgrade is the cheapest moment to delete it, and that decision belongs to the business, not to the developers.
Community or Enterprise on the target
If you are considering a change of edition, doing it in the same project is usually cheaper than doing it later, but it enlarges the testing scope. That is a deliberate call, not a detail.
How long to keep the old system
Read-only access to the previous system for a defined period settles most historical questions without migrating everything. Keeping it writable, on the other hand, guarantees somebody keeps working in it.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Upgrading straight from production
One attempt, no rehearsal, and every surprise happens with users waiting. The conversion is repeated on copies until it is boring, and only then scheduled.
Custom modules ported without reading them
Making code run on the new version is not the same as making it still do the right thing. Behaviour is validated against the process, not just against the absence of an error.
Data problems fixed in the converted copy
The fix is lost at the next conversion and reappears at cutover. Data issues are corrected at source in the live system so every subsequent conversion is cleaner.
Reports assumed to be identical
A report can run without error and still return a different number, and finance will find it at the first close. Key reports are compared side by side for the same period before sign-off.
Integrations tested last
Credentials, endpoints and payload shapes all break on upgrade, and each one has an external party attached whose response time you do not control. They are retested during validation, not on go-live day.
No rollback point
Cutovers occasionally have to be reversed. The pre-conversion backup, the exact freeze time and the decision maker are written into the runbook before it starts.
Training treated as unnecessary
Users forgive a changed screen and do not forgive a changed workflow they were not told about. Retraining targets what genuinely changed, which is a much shorter list than a full course.
Not included
Stated up front so the proposal has no soft edges.
- ร Third-party module licences for the target version, which are bought by you
- ร Rewriting a third-party module that has no successor version, unless separately quoted
- ร New features and process changes, which belong in an implementation phase and not in an upgrade
- ร Recovering data that was already missing or wrong before the upgrade began
- ร Guaranteed compatibility for modules whose source we are not permitted to see
- ร Hardware or hosting upgrades that the target version needs, quoted separately
How this is priced
Migrations are quoted after the assessment, because a quote before anyone has read the custom modules is a guess. The assessment itself is a small fixed piece of work and its findings carry into the upgrade quote.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
Cloud Backup Pro - Multi-Destination Encrypted Database & Filestore Backup
Encrypted, scheduled Odoo database + filestore backup to S3, SFTP, Local NAS, Google Drive, Dropbox and OneDrive. GFS retention, integrity verification, one-click restore, health dashboard, email/webhook alerts.
Why here: The rollback point for a cutover is a backup you have already restored once. This is the machinery for that.
ToolsImport / Export Power Tools
Powerful data import & export for any model - CSV / XLSX / JSON, upsert, scheduled exports, templates and error logs.
Why here: Upgrades surface data that has to be corrected in bulk at source, and doing that by hand is where the schedule slips.
ProductivityAudit Log & Access Tracking
Track who created, changed or deleted records - full audit trail with field-level history and access-rights tracking.
Why here: After cutover, the fastest way to settle a dispute about a converted record is to see what changed and when.
ProductivityDynamic Financial Reports
Dynamic Balance Sheet, Profit & Loss, Trial Balance, General Ledger, Partner Ledger, Aged Receivable / Payable, Cash Flow and Tax Report with comparison, PDF and Excel.
Why here: Validation depends on comparing the same financial reports on both versions for the same period.
Accounting/AccountingEnterprise Theme (Community)
Brings the full Odoo 19 Enterprise look & feel to Community Edition.
Why here: Where the driver for moving is the Enterprise interface rather than Enterprise features, this closes that gap without changing edition.
Themes/BackendOdoo data migration and version upgrade, including the dry run that proves the numbers match before you commit to a go-live date.
Where we deliver this
Accounting and payroll setup has to be re-validated after any version change. The country pages set out what applies in your market.
Odoo Migration & Upgrade: common questions
Can you upgrade us from an old Odoo version?
Yes. The migration service covers the database, the custom modules, attachments and historical transactions, with a test environment for sign-off before cutover. Older versions take longer because more standard behaviour changed on the way, and because third-party modules are less likely to have a successor.
Will we lose data?
No. Conversions run on copies, the original is untouched until cutover, and a full pre-conversion backup is the rollback point. What does happen is that data which was already inconsistent becomes visible, because conversion is stricter than daily use.
How long does an upgrade take?
The assessment is quick. The elapsed time is driven by how much custom code has to be ported and how long your team needs to validate. The cutover window itself is measured during rehearsal, so you get a real number rather than an estimate.
Do we have to upgrade every year?
No, and most teams should not. The reasons to move are security support on your current version, a third-party module you need, or custom code that is getting expensive to maintain against an old base. Upgrading with no reason is cost with no return.
What about our customisations?
They are graded per module in the assessment. Code that extends standard behaviour ports quickly. Code that replaces standard behaviour, or that was written as edits to core, is expensive at every version, and we tell you which of yours is which before you commit.
Can we move from Community to Enterprise during the upgrade?
Yes, and doing both in one project is usually cheaper than sequencing them. It enlarges the testing scope, so it is planned deliberately rather than added mid-way.
Read next
Odoo Health Audit
Deep technical + functional audit of your instance.
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Odoo Customization
Custom modules built to match your exact workflow.
Odoo Support & Maintenance
24/7 monitoring, bug fixes, performance tuning.
Odoo Consultancy
Expert advice on architecture, licensing, and strategy.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.