NetSuite → Odoo Migration Timeline
90-day parallel-run approach · NetSuite stays live until cutover
usedel.ai · Figures in USD thousands
Every CFO who has lived through a failed ERP project knows the pattern: the timeline that turned into three years, the fixed-price contract that wasn't, the go-live weekend that became a six-month emergency. Those outcomes are real. But they come from a specific set of structural choices, not from ERP migration being inherently unpredictable.
If you are evaluating a netsuite to odoo migration and want to understand what a well-structured project looks like, this article covers the operating structure: the 90-day timeline, how the parallel run works, what fixed-price actually means and what it excludes, and the five-year cost math. If you are still in the comparison phase and have not decided whether Odoo is the right direction, start with Odoo vs NetSuite: Honest Comparison for Mid-Market CFOs first. If you want the step-by-step audit-to-rollback sequence for running a migration like this yourself, see The Sequence, the Gates, and the Rollback: How an ERP Migration Actually Runs.
A NetSuite to Odoo migration is scoped at 90 days on a parallel-run model for a single-entity company with clean data and no OneWorld dependency. Weeks 1–2 cover discovery and scope lock, producing a signed scope document that anchors the fixed price. Weeks 3–6 cover system build and data migration, with NetSuite still live and unchanged. Weeks 7–10 cover the parallel run: both NetSuite and Odoo process the same transactions simultaneously, with weekly reconciliation gates. Weeks 11–12 cover UAT, training, and written reconciliation sign-off. Cutover happens on Day 90 and is condition-based, not calendar-based — NetSuite stays live until outputs match line-by-line. Migration starts at $50,000 fixed-price. The five-year cost comparison at a $429,000 NetSuite annual baseline shows $2,516,772 for NetSuite versus $350,000 for Odoo post-migration, a delta of $2,166,772. Multi-entity structures, active audit cycles, and heavy SuiteScript customization extend both the timeline and the cost beyond this baseline.
Source: del.ai migration methodology, 2026
The ERP migration horror story has two root causes. Both are structural. Neither is inherent to migration itself.
Root cause one: scope ambiguity. Most ERP implementation contracts are signed before requirements are fully understood. The vendor gives you a price based on a sales conversation. Discovery happens post-contract. When the vendor finds requirements they did not anticipate, they bill for them. The timeline expands to absorb the additional work. The budget expands to cover the change orders. By the time you realize the scope has doubled, you are deep enough in that stopping costs more than continuing.
This is not a complexity problem. It is a contracting problem. The scope was never fixed.
Root cause two: forced cutover. The go-live date is set on a calendar before anyone has confirmed the data is right. Pressure builds as the date approaches. When something is wrong — and something is always off in the first weeks — you are already live. The only direction available is forward, at whatever cost it takes to stabilize.
There is no shortage of published statistics on ERP budget overruns, and we are not quoting one, because the widely circulated figures trace back to a single consultancy's commercial survey drawn from a largely enterprise sample. That is the wrong population for a 50-to-500-employee company, and a borrowed number would make this page look better evidenced than it is. The pattern is legible without a percentage: when discovery happens after the contract is signed, every requirement found later is a cost the buyer did not model before signing.
The odoo migration risk that CFOs describe is almost always one of these two failures, not ERP migration as a category. A fixed-price contract anchored to a completed discovery phase eliminates the first. A parallel run with a condition-based cutover eliminates the second.
The parallel run is the structural solution to forced-cutover risk. It is also the part of ERP migration that most vendors skip because it requires maintaining two live systems simultaneously, which costs more to operate in the short term.
An ERP parallel run means both systems — NetSuite and Odoo — process the same transactions simultaneously for four weeks under the standard 90-day timeline, longer for migrations with higher transaction volume or reconciliation complexity. You do not cut over until the numbers reconcile. If Odoo output matches NetSuite output for the same period, cutover proceeds. If it does not, NetSuite stays live.
That is the erp migration parallel run structure in plain terms. The cutover is not a date on a calendar. It is a condition. The condition is deterministic: numbers either match or they do not. No one makes a judgment call about whether the system is "good enough."
Reconciliation in this context means deterministic data verification, not a visual review. Both systems receive the same inputs over the same period. You compare outputs: journal entries, AR aging, AP aging, inventory positions, revenue recognition. If the outputs match, the verification passes. If they do not, the migration restarts from the last confirmed gate.
"The numbers look right" is not reconciliation. "The numbers match exactly, line by line, for the period" is reconciliation. The distinction matters because ERP systems can produce plausible-looking output that contains systematic errors. A visual review misses those. A deterministic comparison does not.
Each phase of the migration has a rollback gate. If reconciliation fails at any gate, the previous confirmed state is the live state. NetSuite is not cancelled in advance of cutover. The license is maintained through go-live. There is no moment where you are committed to Odoo before verification is complete.
The parallel run also generates a dual-record artifact: the same transaction set documented in both systems for the overlap period. For CFOs with upcoming audits, this is a useful continuity document.
Reconciliation in a NetSuite to Odoo migration means deterministic data verification, not a visual review. Both systems receive the same inputs over the same period, then the outputs are compared line by line: journal entries, AR aging, AP aging, inventory positions, and revenue recognition. If every output matches, the gate passes. If any output does not match, the previous confirmed state stays live, and NetSuite is not cancelled until the gate is re-run. That standard is what eliminates most of the odoo migration risk CFOs describe: a migration cannot silently drift into a bad cutover, because cutover requires an exact match, not a judgment call that "the numbers look right." The same discipline applies before scoping: OneWorld with five or more entities, heavy custom SuiteScript, an active M&A process, and a mid-audit cycle each disqualify a company from this model until the underlying condition changes.
Source: del.ai migration methodology, 2026
A NetSuite to Odoo migration on a parallel-run model takes 90 days across five phases: discovery, build, parallel run, UAT, and cutover. Weeks 1 through 2 cover discovery and scope lock. Weeks 3 through 6 cover system build and data migration, with NetSuite still live and unchanged. Weeks 7 through 10 cover the parallel run, with both systems processing the same transactions. Weeks 11 through 12 cover UAT, training, and written reconciliation sign-off. Day 90 is cutover weekend. The 90-day clock starts after scope is confirmed in writing.
This is the netsuite migration timeline for a single-entity, clean-data migration. Multi-entity structures, active audit cycles, and significant customization extend the timeline. The 90-day figure applies to the ICP: a mid-market company with one or two legal entities, no OneWorld dependency, and no active audit at the time of scope confirmation.
This phase has one output: a signed scope document. The scope document defines what is included in the fixed price, what is excluded, and what would trigger a change order. Everything in the migration flows from this document.
Discovery in weeks 1-2 covers your current NetSuite configuration, your chart of accounts, open periods, pending transactions, historical data depth, and any SuiteApp dependencies. It also identifies audit cycle constraints. If you have an audit scheduled during the migration window, that constraint gets built into the plan. The migration does not run into an active audit.
The data map produced in this phase defines exactly what moves, in what format, and what stays behind (archived but not migrated). Data that is excluded is documented. Exclusions are agreed in writing before the build starts.
The scope document from this phase is also the price anchor. The fixed price is confirmed after discovery, not before. Before discovery, you receive a range. After discovery, you receive a number.
The Odoo instance is built against the signed scope document. Historical data is migrated, system configuration is completed, and integrations are connected. NetSuite continues to operate as the system of record throughout this phase — nothing in production changes yet.
This phase is where the majority of the configuration work happens: chart-of-accounts mapping, workflow rules, and any SuiteApp-equivalent functionality get built and internally tested before the parallel run starts. Errors caught here are cheaper to fix than errors caught during reconciliation.
Both systems go live simultaneously: NetSuite continues to process transactions, and Odoo processes the same transactions in parallel.
Reconciliation runs on a weekly cadence during this phase. Each weekly reconciliation is a gate. If a gate fails, the build does not advance to the next phase. The team identifies the source of the discrepancy, corrects it, and the gate is re-run. NetSuite remains the system of record throughout this phase.
The parallel run occupies this four-week window under the standard 90-day timeline. Low-volume, clean-data migrations clear reconciliation faster within it. High-volume periods (month-end, quarter-end) can extend the parallel run beyond four weeks, which pushes the overall project past 90 days, because those are the periods where systematic errors surface.
Cutover does not proceed without written reconciliation sign-off. The sign-off document records the period covered, the comparison outputs, and the confirmation that both systems match. This document is the authorization for cutover.
User acceptance testing and finance-team training happen in this window. After sign-off, the NetSuite data is archived in a portable format. Odoo becomes the system of record.
Cutover happens on Day 90. The NetSuite license is maintained through this phase and cancelled only after go-live is confirmed stable.
The erp migration timeline for this phase includes a stabilization window after go-live. Issues that surface post-cutover are within scope if they relate to the migrated configuration. Issues that represent new requirements are change orders.
The migration starts at $50,000. The fixed price is confirmed after weeks 1-2 discovery, not before the project starts. Before discovery, you get a range. The range narrows to a number once the scope document is signed. The $50,000 starting point assumes a single-entity migration with clean historical data and no SuiteScript customization. Complexity above that baseline is scoped and priced during discovery before any contract is signed.
What the fixed price covers: data migration from NetSuite to Odoo, system configuration against the scope document, parallel run operation for the agreed period, and cutover support through go-live.
What it does not cover: custom development outside the agreed scope document, third-party integration work not listed in the scope document, and ongoing support after go-live. These are separate line items.
The scope document is the contract anchor. Any work that expands beyond the signed scope becomes a change order. Change orders require written approval before the work starts. This is the mechanism that prevents scope ambiguity from recurring in the new contract.
There are four situations where a migration is not the right call. These are worth naming directly.
OneWorld with five or more legal entities. NetSuite OneWorld handles multi-entity consolidation, per-jurisdiction tax compliance, and intercompany eliminations in a way Odoo does not match today. If your structure requires that depth, evaluate carefully before committing to a migration. Odoo's multi-company module handles simpler structures. It does not replicate OneWorld for complex consolidation.
Heavy custom SuiteScript. If your business runs on custom NetSuite code, migration complexity increases substantially. The SuiteScript logic needs to be re-implemented in Odoo, which means scoping and pricing custom development. That changes the economics.
Active M&A process. Do not swap the system of record while a deal is in diligence. Your financial data is under scrutiny. This is not the time to introduce migration risk.
Mid-audit cycle. Do not migrate during an active audit. Discovery in weeks 1-2 identifies your audit schedule. If an audit falls within the migration window, the migration is scheduled around it.
These are not standard vendor disclaimers. Each one represents a situation where the migration either fails or generates costs that exceed the savings.
A mid-market NetSuite installation costs $210,000–$680,000 per year across five cost layers — not the license line alone. The five layers are license and user fees, Alliance Partner or admin support, SuiteApps such as Avalara and Celigo, BI and ETL tools, and internal admin headcount. Most CFOs model only the license. The full stack runs 5x to 15x that figure once the other four layers are counted. At a $429,000 annual NetSuite baseline with 8% annual price escalation, the five-year NetSuite total is $2,516,772. Post-migration there is no platform licence at all: del.ai deploys Odoo Community under LGPLv3, which carries no per-seat fee, so the recurring cost is hosting from $2,000 a month and there is no Alliance Partner retainer. The migration starts at $50,000 fixed-price. Year 1 savings from eliminating the NetSuite stack offset the migration fee, making the net first-year migration cost zero. Savings compound from Year 2 onward, producing a five-year delta of $2,166,772 in favor of Odoo.
Source: del.ai product scope definition, 2026
The netsuite odoo migration cost question has two components: the one-time migration fee and the ongoing platform cost post-migration. Both need to be in the model before the comparison is meaningful.
NetSuite total stack cost for a mid-market company runs across five layers:
| Cost Layer | Annual Range |
|---|---|
| License + users | $30,000–$50,000 |
| Alliance Partner / admin support | $30,000–$100,000 |
| SuiteApps (Avalara, Celigo, FloQast) | $20,000–$50,000 |
| BI / ETL tools | $30,000–$80,000 |
| Internal admin headcount | $100,000–$400,000 |
| Total | $210,000–$680,000 |
Most CFOs are tracking the license line. The total stack is 5x to 15x the license.
Post-migration there is no platform licence line. del.ai deploys Odoo Community, the LGPLv3 edition, which has no per-seat fee — the recurring cost is hosting, from $2,000 a month, and it does not reprice when you hire. The AI layer, integrations and ongoing configuration are included in del.ai's post-migration structure. There is no equivalent to the Alliance Partner retainer.
The five-year comparison uses a $429,000 midpoint as the NetSuite annual baseline, with 8% annual price escalation as a modeling assumption rather than a rate Oracle publishes; check your own contract's uplift clause for the figure that actually applies to you — the same $2,516,772 vs. $350,000 comparison stated above. These are illustrative numbers. Your specific number depends on your stack, your headcount, and your SuiteApp mix.
The migration cost is self-funded in this model. Year 1 savings from eliminating the NetSuite stack offset the migration fee. The net cost of migration in year 1 is the difference between what you stop paying and what you pay del.ai. At a $429,000 annual NetSuite baseline, the net migration fee in year 1 is offset by the first year of NetSuite savings. The savings accumulate from Year 2 onward.
For the five-layer cost breakdown with sourced numbers, see The Real Cost of NetSuite Nobody Publishes.
These questions apply to any vendor, not del.ai specifically. A CFO who applies them in any vendor conversation will surface the structural risks before signing. The list comes out of del.ai's own migration methodology — the same failure patterns named in the "Why ERP Migrations Go Wrong" section above, restated as questions a buyer can ask before signing rather than as a diagnosis after the fact.
A vendor who cannot answer questions 3, 5, and 7 specifically is operating under the same structural conditions that produce the horror stories. Vague answers on rollback and reconciliation mean the risk is still on you.
This structure works for a specific type of company. NetSuite all-in spend of $200,000 or more per year. Clean entity structure: one or two legal entities, no OneWorld dependency. No active M&A or audit. Renewal coming in the next 12 months.
If that is your situation, the math is usually clear enough to model in a 30-minute conversation. Del.ai builds your specific number. If the five-year comparison does not show a return that justifies the migration, that gets said in the first 10 minutes.
Patrick Xie is the founder of del.ai. del.ai sells fixed-price NetSuite-to-Odoo migrations to mid-market companies. The company was founded in 2026 and has not yet completed a customer migration, so the timeline, gates and contract terms described above are the model we scope and contract to, not a summary of delivered projects.
Sources
1. del.ai migration methodology and cost model, 2026