Two different projects that look like one.
A version upgrade and a platform migration get quoted the same way and are not the same work. An upgrade carries your accumulated customisation forward into a framework that has changed underneath it. A migration carries your operating history into a system that models the business differently. Both fail in the same place: the reconciliation nobody scheduled.
What makes either survivable is treating it as a business continuity exercise rather than a technical one. The questions that decide the outcome are operational: what does the close look like in the first month afterwards, which integrations must work on day one, what happens to open transactions at cutover, and what is the documented route back if the first attempt does not hold.
Where upgrades and migrations go wrong.
Customisation treated as portable
Extensions written against an old framework are lifted forward, then break in ways that only appear under production load.
No functional regression testing
The data moved and the screens open, so it is declared done — until the first month-end close finds the differences.
Accounting never reconciled
Trial balance, ageing and inventory valuation are not agreed line by line before cutover, only checked afterwards.
Integrations validated last
Bank files, government portals and eCommerce feeds are tested in the final week, when there is no time to redesign.
No cutover rehearsal
The cutover is executed for the first time on the live weekend, with no measured duration and no fallback.
Performance untested at volume
The new version is tested with sample data and meets production volume for the first time on Monday morning.
What the engagement actually includes.
Upgrade assessment
Before any commitment: how far behind you are, what your customisations will cost to carry forward, which of them can be retired instead, and whether an upgrade or a fresh implementation is the cheaper route.
Migration strategy
Scope of history to carry, cutover approach, phasing, parallel-run decision and the rollback plan — agreed with finance and operations before technical work begins.
Code migration
Custom modules assessed individually, then retired, replaced with standard, or rewritten against current framework practice. Carried forward unchanged only when that is genuinely the right answer.
Data migration
Extract, clean, map, migrate, reconcile, validate — with trial balance, ageing and inventory valuation agreed line by line before cutover, signed by the CFO.
Testing
Functional regression across every process, integration validation against live endpoints, performance testing at production volume, and security testing on the new role model.
Cutover & hypercare
Rehearsed at least once with a measured duration, executed against a documented runbook with a rollback point, then hypercare through the first close.
Ten stages. The cutover is rehearsed, not attempted.
Odoo to Odoo, or another ERP to Odoo.
These are different projects with different risks. A version upgrade is mostly a customisation problem. A platform migration is mostly a process and data-model problem, and it is an opportunity to correct decisions the old system forced on you.
Version 14, 15, 16, 17 or 18 onto current. The work is dominated by custom module assessment and functional regression. The gain is usually retiring code that standard Odoo now covers.
SAP, Dynamics, Oracle, NetSuite, Sage, legacy or custom systems. The work is dominated by process design and data-model mapping, because the two systems model the business differently.
Migration is not moving database A to database B. If the only test applied is whether the records arrived, the differences will be found by your auditor instead.
A live environment on the target version, reconciled and signed.
The migration is finished when finance has signed the reconciliation and the first close has run on the new version — not when the data landed.
Migration sources we work with, and the target environments we deploy onto.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
How much does an Odoo upgrade cost?
Almost entirely a function of your customisation, not your version gap. A standard environment three versions behind can be straightforward; a heavily customised environment one version behind can cost more. The assessment gives you a number before you commit.
Should we migrate all our history?
Rarely all of it. Open transactions and the balances always. Two to three years of closed history usually. Everything beyond that is often better served by keeping the old system readable for reference than by migrating it.
Can you do it with no downtime?
Not honestly, for an ERP. What we can do is compress the window to a rehearsed and measured duration — usually a weekend — with a defined rollback point if it does not hold.
Is SAP to Odoo realistic?
For many mid-market operations, yes — and it is usually driven by cost of ownership and speed of change rather than by function. What it requires is honest process redesign, because the two systems do not model the business the same way.
ERP governance after go-live.
The decision log is the asset. Most programmes throw it away at handover.
ERP StrategyWhy ERP projects fail at the operational layer.
Implementations rarely fail technically. They fail at the point where the software meets a process nobody agreed to change.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.