Migration without invisible regression
Customisations analysed before the move. Integration contracts redesigned. The new system isn't an accident; it's a decision.
When the system that used to fit doesn't anymore,
Migration is half decision audit, half technical move.
We help you decide what to carry forward before we help you move it.
The technical move is the easy half. The decision audit is what determines whether the migration completes on time.
Customisations analysed before the move. Integration contracts redesigned. The new system isn't an accident; it's a decision.
Phased cutover with parallel running where practical. Reporting continuity. The business doesn't stall while the systems trade places.
Decision audit reveals migration scope before the project starts. No "we found more customisations than we thought" surprise.
Source audit trail mapped and preserved. Data residency respected through the migration. Compliance evidence doesn't lose continuity.
Migrations don't slip because the technical work is hard. They slip because the decision work is invisible until it isn't.
Year-three of the legacy system contains thousands of decisions accumulated since launch. Customisations someone built for a specific business reason that nobody remembers. Integrations that route around a vendor's API quirk. Reports the board uses that were spec'd in 2019. Workarounds that became habits. Half of every migration is figuring out which of those decisions is still load-bearing and which has aged out. The technical move is the easy half. The decision audit is the half that ate the timeline.
Discovery reveals modules nobody on the current team knew about.
Vendor integrations exist but no one can fully explain what they do.
Dashboards the board uses were spec'd by people who have moved on.
In the codebase, the spreadsheet bridge that runs a department looks the same as the temp script nobody needs anymore.
It becomes a decision audit.
That's where migration stops being a project plan.
Each shows up in leadership meetings well before anyone formally schedules the project.
The migration discovery phase reveals customisations nobody on the current team knew about.
Vendor integrations exist but no one can fully explain what they do or who relies on them.
Every team has reports they trust. Each team's reports show slightly different numbers.
A spreadsheet bridge that "we'll fix in the new system" turns out to be how a department functions.
The Odoo (or other ERP) version is several behind. The upgrade path is non-trivial.
The legacy vendor is either disappearing, raising prices, or retiring the version. Choice is forced.
These aren't technical surprises. They are decision-archaeology surprises. The migration plan optimistically assumed they didn't exist.
Migrations fail in patterns. The patterns are decision-archaeology problems disguised as technical-execution problems.
Migration kicks off without an inventory of accumulated decisions. The decisions surface during the move and stop it.
Customisations get ported without asking whether they're still needed. The new system inherits the old system's debt.
Master data quality issues, duplicates, and ownership gaps carry forward into the new system.
Cutover happens before reporting continuity is verified. Trust in the new system erodes.
Cutover assumed irreversibility. When something doesn't behave, the team has nowhere to go.
Operational reports get prioritised; leadership reports get rebuilt after go-live, with gaps in trust during the interim.
Custom modules ported as-is rather than refactored for the new platform's idioms. Maintenance debt arrives day one.
Migration failure looks like a technical-execution problem. It is almost always a decision-archaeology problem in disguise.
Every migration that ran twice as long as planned shows some version of the same mistake.
The plan was to move the system. The work turned out to be auditing the decisions inside it.
When years of accumulated customisations, integrations, workarounds, and reports show up only during the migration itself, the project becomes an unscheduled decision audit on a deadline.
Migration rarely breaks on the move. It breaks on the decisions you bring with you.
Four principles separate a migration that lands from a migration that becomes the next rescue.
Inventory of accumulated decisions in the source system, with each tagged: carry, refactor, retire, or replace. Scope follows.
Functional areas cut over in waves. Where the workload supports it, both systems run in parallel until the new one is trusted. Where it doesn't, staged validation and rapid-rollback design replace dual-running.
Every cutover phase has a documented reversion or contingency path, calibrated to what the workload genuinely supports. Used rarely; valued when needed.
Leadership reporting recreated and verified before cutover, not after. Trust in the new system depends on the numbers still matching.
Four blocks: internal proof, engagement components, migration architecture, and where this work shows up in our existing book.
Weeks 1 to 4. Inventory of customisations, integrations, workarounds, reports. Each tagged: carry, refactor, retire.
Weeks 4 to 6. Phased plan distinguishing carry, refactor, retire, and newly build.
Weeks 6 to 10, if needed. The legacy system must be operational and trustworthy during the migration.
Parallel. Treated as data-quality work — duplicates resolved, master data harmonised, audit trails preserved.
Weeks 8 to cutover. Existing modules analysed, ported, refactored, or retired per the audit verdict.
4 to 12 weeks where practical. Reconciliation between source and target is part of the engagement.
One weekend, planned in detail. The new system becomes authoritative with a rollback or contingency plan ready.
6 to 12 weeks of stabilisation in the new system before the engagement closes.
Legacy system on the left. Target system on the right. Between them, the audit/decide/carry/refactor/retire layer — where the engagement actually happens. The technical move is the smaller arrow at the bottom; it's what gets scheduled once the decisions are made.
Four outcomes plus the six numbers we measure across a migration engagement.
The migration is the opportunity to retire technical debt, not import it.
Numbers in the new system match expected. Leadership confidence transfers cleanly.
Decision audit reveals scope before cutover, not during. No "we found more work than we thought" surprises.
Whether literal rollback or staged-validation contingency, the team has somewhere to go. Used rarely; valued when needed.
The customisation tag count is the single most informative number — it tells leadership how much of the old system survived the audit, in writing, with the verdict per item attached.
A migration engagement is the right move when the current system is forcing the conversation (vendor changes, version EOL, scale limits, cost), you're willing to fund a decision audit before scoping the technical move, and operations leadership can engage with parallel running and reconciliation work.
It's too early when you want a lift-and-shift on the lowest budget, there's no internal owner for the decision audit, the business is changing too fast to formalise current-state decisions, or the source system is actively failing — in which case start with System Rescue first.
Source platforms we have migrated from include Tally, QuickBooks, SAP Business One, NetSuite, and various custom internal systems, plus Odoo version-to-version upgrades. Each engagement confirms which source platforms apply before scope is set.
A typical migration runs 5 to 12 months end-to-end depending on system complexity. Four phases, each ending with a written deliverable.
Inventory of customisations, integrations, workarounds, and reports. Each tagged. Modernization roadmap delivered in writing.
Target system built per the roadmap. Customisations refactored. Data migration validated. Parallel running where practical.
Planned in detail. New system becomes authoritative. Rollback or contingency plan ready.
Stabilisation in the new system. Reporting verified. Operations confidence restored. Then the engagement closes — or transitions to Long-Term Support.
The decisions you carry into a new system become the new system's debt before launch. Auditing them first is what separates a migration from a rebuild in disguise.
Six engineering non-negotiables. Each is the floor, not the ceiling.
The audit is the first deliverable, not a phase to rush through. Every customisation, integration, workaround, and report tagged.
Scope follows the audit. Nothing moves unexamined.
Where the workload supports it, both systems live until reporting confidence transfers. Where it doesn't, staged validation replaces it.
Documented, tested, available. The shape depends on what the workload supports; the principle (a known way back) does not.
Leadership reports rebuilt and verified in parallel. Cutover doesn't blink the numbers.
6 to 12 weeks of stabilisation in the target system before the engagement closes.
Direct answers for CTOs and operations leaders considering a migration.
A focused single-entity migration from a legacy ERP to Odoo typically takes 5 to 9 months end-to-end (audit + scoping + build + parallel running + cutover + stabilisation). Multi-entity or multi-region migrations are usually 9 to 18 months. The decision audit phase often surprises clients in how much it reveals.
Migration moves operations from System A to System B. Modernization is the broader work of bringing the operating model up to current standards — which may or may not require a full migration. We often start engagements with the question "is this a migration or a modernization?" because the answer changes the scope materially.
Data migration is treated as a data-quality engagement, not a technical mapping exercise. Duplicates resolved at source. Master data harmonised. Audit trails preserved. Garbage in the source is identified and addressed before it migrates, not after.
Yes. Odoo version-to-version migrations follow the same discipline: decision audit (which customisations still apply), refactor (where the new version makes them obsolete), parallel running where practical, and cutover. Smaller in scope than a platform migration, but the same shape.
Phased when feasible. Big-bang only when phased is genuinely impractical (e.g., the systems can't run in parallel because of licensing or operational reasons). The default is phased; the burden of proof is on big-bang.
The decision audit tags each customisation: carry forward (still load-bearing, port responsibly), refactor (still needed but the new platform offers a better way), or retire (was a workaround that's no longer needed). The output is a documented decision per customisation, signed off before scope is set.
A single-entity migration from a legacy ERP to Odoo varies widely depending on customisation depth, integration count, data complexity, and parallel-running duration. Concrete ranges are confirmed in the consultation conversation; we don't publish numbers on this page until they have leadership sign-off.
That's typically a System Rescue engagement first — stabilise the source enough to migrate from it safely, then proceed with migration. Trying to migrate from a failing system without stabilising it first usually compounds the problem.
Yes. Platform migrations (on-premise to cloud, one cloud to another) follow the same discipline as ERP migrations. The decision audit covers the deployment model along with the application.
Every cutover phase has a documented reversion or contingency path, sized to what the workload supports. Where parallel running is practical: source system kept warm, data sync direction reversible, leadership reporting maintained in both systems through the parallel period. Where it isn't: staged validation, smaller cutover slices, and a fast-forward-fix plan replace a literal "press the undo button" reversion. Rollback gets used rarely. Having it ready changes how the team behaves on launch day.
Migration is half decision audit and half technical move. The technical move is the easy half. The decision audit is what determines whether the migration completes on time.
Customisations in a migration carry three possible verdicts: carry forward, refactor, or retire. The output of a migration's discovery phase is a tagged inventory, not a project plan.
Phased cutover with parallel running where practical is the default approach. Where parallel running isn't viable, staged validation and rapid-rollback design replace it.
No lift-and-shift pitch. Fit-first.