An ERP migration is not one event. It is an audit, a build, a period where both systems run against the same transactions, and a cutover that must stay reversible until it is not needed. Most of the risk sits in that third phase, and most published timelines skip it, which is why the same projects keep failing at the same place.
Audit. What is actually in the old system: entities, chart of accounts, open transactions, customisations, integrations, and the reports somebody's month genuinely depends on. This phase produces the scope, and a scope produced any other way is a guess.
Build. The new system configured against that audit, with data loaded and reconciled back to the source. Nothing about this phase is negotiable in sequence — you cannot validate what you have not loaded.
Parallel run. Both systems process the same periods, and the outputs are compared. This is where a migration is actually de-risked, and it is the phase most plans compress first because it looks like duplicated effort. It is not duplicated effort. It is the evidence.
Cutover. The old system stops being the book of record. Reversible up to a defined point, and the definition of that point belongs in writing before the weekend it happens.
The risk is not evenly spread. Audit and build failures are visible and get fixed. A parallel run that was shortened produces a cutover with no evidence behind it, and the failure shows up a month later in a number nobody can defend. The method we contract to treats it as the load-bearing phase rather than the optional one.
For a mid-market company moving off a single-tenant cloud ERP, a well-structured move runs a quarter, with the audit and build occupying the first half and the parallel run the second. The variable is not the size of the company but the amount of accumulated customisation and the number of live integrations, because each one is a separate decision about whether to rebuild, replace or retire it. Published timelines that promise less usually achieve it by shortening or skipping the parallel run, which does not remove the work — it moves it past the cutover, where it costs more and is harder to reverse. Note the framing here: 90 days is the schedule del.ai scopes and contracts to, not a report on projects already delivered. del.ai was founded in 2026 and has completed no customer migration, so no duration on this page is an observed outcome.
Source: del.ai migration methodology and scoping model, 2026
A gate that cannot stop the project is a status meeting. Four are worth writing into the plan.
| Gate | The question | What failing it means |
|---|---|---|
| Scope frozen | Is the audit complete, and is every customisation classified? | Build does not start |
| Data reconciled | Do balances in the new system tie to the old, to the cent? | Parallel run does not start |
| Parallel run clean | Do both systems produce the same period result, twice? | Cutover does not happen |
| Rollback defined | Is there a written point of no return, and a documented way back before it? | Cutover weekend does not begin |
Each of these is a decision someone has to be willing to make in the wrong direction. That is the whole value of writing them down in advance: a gate agreed under time pressure at the moment it fails is not a gate. These four are vendor-agnostic and hold whatever you are moving between.
Two things, and they are structural rather than procedural. First, the old system stays live and processing through the parallel run, so reverting means continuing to use a system that never stopped rather than restoring one that did. Second, the point of no return is written down before the cutover weekend, along with what has to be true to pass it and what the documented path back looks like before it. A migration without both is not reversible; it is a cutover with optimism attached. This is also why the parallel run cannot be compressed to save calendar time — it is the mechanism that keeps the old system warm, and shortening it converts a reversible project into an irreversible one without anybody deciding to. The sequence described here is what del.ai contracts to deliver, not a record of completed projects.
Source: del.ai migration methodology, 2026 ; Odoo S.A., "Year-end closing," Odoo 19.0 Accounting documentation, 2026. ↗
Not revenue, and not headcount. Four things, in rough order of how much they move the number:
Accumulated customisation. Every custom script and workflow is a decision: rebuild it, replace it with configuration, or retire it because nobody has used it in two years. The third answer is more common than teams expect and is worth looking for.
Live integrations. Each connected system is its own small migration with its own owner and its own test.
Entity structure. Multiple legal entities multiply the reconciliation surface, and group-level consolidation is a separate question from entity-level ledgers — what transfers and what does not for a multi-entity group is the honest version, including the gap list.
Audit and compliance posture. Being mid-audit, mid-raise or mid-acquisition is a timing constraint, not a capability one, and it is usually a reason to move the date rather than the plan.
The whole shape in one place — timeline, risk, and the decisions a CFO signs off, with each phase named. → NetSuite to Odoo Migration
The scoped calendar, week by week, including which weeks are parallel run and what evidence each one produces. → A 90-Day Migration, Week by Week
The argument for running both systems against the same periods, and what a compressed parallel run actually costs. → Parallel-Run, Not Cutover
What transfers for a group with several legal entities, and the short honest list of what does not. → NetSuite OneWorld to Odoo
The case in the form it has to be made: what it costs, what it replaces, and what the renewal clock does to the decision. → The NetSuite-to-Odoo Business Case
Post-acquisition sequencing when the same decision has to be made several times, in different companies, on different clocks. → ERP Standardization for PE Portfolios
Sizing, timeline and cost for a mid-market move, including the four pitfalls generic migration guides skip. → Odoo Migration for Mid-Market Companies
The same four phases, decomposed into the specific gates: the five-part pre-migration audit, the six data-migration steps in order, the four-part parallel-run validation, and the binary go/no-go and rollback triggers. → The ERP Migration Readiness Checklist
Moving the system of record for finance and operations from one platform to another, including the data, the configuration that encodes how the business works, and the integrations around it. The data move is the part everyone plans for and the smallest of the three.
It is scoped from the audit, not quoted from the headcount, because the drivers are accumulated customisation and live integrations rather than company size. What we will say without seeing an environment is that the comparison a CFO needs is against the cost of staying, which is a five-layer annual number most companies have never assembled — that arithmetic sits here.
Cutting the parallel run. It is the phase that looks most like duplicated effort and is the only one that produces evidence the new system agrees with the old. Everything else that goes wrong is visible while there is still time to fix it.
No. The close is the period when both systems are under the most load and the team has the least slack, and it is the worst moment to be reconciling two sets of books for a reason other than the close itself.