A 90-Day NetSuite to Odoo Migration, Week by Week
Every vendor who sells NetSuite-to-Odoo migration services says some version of "90 days." Few publish the calendar that has to hold for a 90-day NetSuite to Odoo migration to land on time. This article breaks the NetSuite to Odoo migration phases into the actual weeks they occupy: what gets mapped in week 1, what gets trained in week 6, what gets walked through with your auditor in week 8, and what happens on cutover weekend.
Disclosure: del.ai sells NetSuite-to-Odoo migration services. We have a commercial interest in this topic, and this breakdown comes from the team that runs the schedule on signed engagements, not a neutral observer. The weeks described below are the actual sequence, not a marketing simplification of a longer project.
This piece does not re-argue whether a migration is safe, what parallel run protects against, or what the five-year cost comparison looks like against staying on NetSuite. That case is made in full in the companion article, "NetSuite to Odoo Migration: Timeline, Risk, and What CFOs Need to Know." This one stays narrow: which week does what, and where the 90-day promise breaks. If you already know you want to migrate and need to know what the calendar looks like, start here.
Quick Answer: Is 90 days realistic for a NetSuite to Odoo migration, and what does each phase cover?
Ninety days is realistic for a NetSuite to Odoo migration, but it is conditional, not a marketing round number. The clock holds when three conditions are met: the source is single-entity NetSuite, not OneWorld; SuiteScript customization is moderate rather than extensive; and the buyer assigns one dedicated point of contact for discovery week. Weeks 1-2 cover discovery: a SuiteScript audit, a OneWorld check, and a locked migration scope. Weeks 3-4 build the sandbox and map every NetSuite field to its Odoo equivalent. Weeks 5-9 run NetSuite and Odoo in parallel while the team trains on real transactions, with audit prep folded into weeks 7-8. Weeks 10-12 cover cutover weekend and go-live, gated on a rollback test rather than a fixed date. Under a fixed-price scope of work, del.ai absorbs the cost of schedule overrun, not the customer, for qualifying migrations within the signed scope document.
Source: del.ai analysis of 20+ mid-market NetSuite-to-Odoo migration scopings, 2024–2026.
Where the 90-Day Number Comes From (and When It Doesn't Hold)
Most accounts of a 90 day ERP implementation skip the week-by-week mechanics and assert the number. This is where it comes from, and the conditions that have to hold for it to stay true.
Ninety days is realistic for a NetSuite to Odoo migration, but it is conditional, not a marketing round number. The clock holds when three conditions are met: the source is single-entity NetSuite, not OneWorld, SuiteScript customization is moderate rather than extensive, and the buyer assigns one dedicated point of contact for discovery week. The schedule is achievable at all because AI-accelerated dependency mapping and parallel task execution compress work a serial human systems integrator does over twelve to eighteen months into twelve weeks of overlapping phases instead of sequential ones. The commitment is also structural, not merely optimistic: under a fixed-price scope of work, del.ai absorbs the cost of schedule overrun, not the customer, for qualifying migrations within the signed scope document. That is why this reads as a sequenced set of weekly commitments rather than an estimate. The section near the end of this article names exactly what disqualifies a migration from holding to it.
Most Odoo implementation partners and generic ERP migration vendors do not publish a week-by-week schedule with named disqualifiers up front. In del.ai's analysis, that's a function of pricing model, not secrecy: time-and-materials engagements do not require the vendor to commit to a calendar, because schedule risk sits with the buyer rather than the vendor. A fixed-price, dedicated-engineer model only works if the team can name the weeks and own the risk of missing them. That's the structural reason a literal week-by-week duration claim is credible here instead of aspirational. The rest of this article names every one of those weeks, in order, including the slip points.
That staffing model is concrete, not abstract: each signed migration gets one forward-deployed engineer assigned for the full 90 days, not a rotating bench of whoever's available that week. The same person who ran discovery week is still on the account during cutover weekend. That continuity is part of why the calendar holds: nobody has to re-explain the scope document to a new face in week 8.
Week 1-2 Discovery: What Gets Mapped Before Anything Moves
The NetSuite migration discovery phase runs in the first two weeks, and it happens before the statement of work is signed, not after. That ordering matters more than almost anything else in the schedule: every disqualifier gets surfaced while it still only costs a conversation, not a change order mid-cutover.
Discovery starts with a SuiteScript audit and a OneWorld check on day one. del.ai's review of past NetSuite-to-Odoo scoping work finds that standard Odoo modules typically cover around 80% of a customer's existing SuiteScript logic (del.ai analysis of 20+ mid-market NetSuite-to-Odoo migration scopings, 2024–2026). The remaining 20% gets evaluated individually during these two weeks: rebuild it in Odoo, drop it because it duplicates a standard feature, or, in the small number of cases where it's load-bearing and unbuildable in the timeline, the company stays on NetSuite and the engagement ends here, not at cutover.
A sandbox environment is spun up on day one of discovery, in parallel with the audit, with no procurement wait for infrastructure. Nothing about the technical environment is gated behind contract signature.
The output of week 1-2 is two documents: a disqualifier list, naming anything that doesn't make the cut, and a locked migration scope that becomes the fixed-price anchor for everything that follows. Neither document is a placeholder. "We'll figure it out during the build" does not appear in either one.
The dedicated point of contact named in the preconditions above does most of their work in these two weeks. Most of the calendar risk in a NetSuite to Odoo migration concentrates here, in how fast the buyer side can confirm what's in scope and what isn't, not in how fast del.ai can build.
Weeks 3-4: Infrastructure and Data Mapping
By week 3, the sandbox spun up during discovery becomes a structural mirror of the live NetSuite instance: same chart of accounts, same entity structure, same transaction types, populated with a working copy of the real data rather than a demo dataset.
The bulk of weeks 3-4 is schema mapping and canonical ontology construction. Every NetSuite field, every custom record type, every relationship between objects gets mapped to its Odoo equivalent and folded into a single ontology that both systems can be reasoned about against. This is not a translation layer bolted on after the fact. It happens here, before a single live transaction runs through the new system, because it is what makes the next two phases, parallel run and day-one agents, possible at all.
Weeks 3-4 also build the data reconciliation primitive that the rest of the migration depends on: every record gets a traceable path from its NetSuite source to its Odoo destination, with drift flagged automatically rather than caught by a human running spot checks later. That primitive is what makes the weekly reconciliation gates in the next phase deterministic instead of a judgment call. Nobody is eyeballing whether the numbers look right; the system checks whether they match, record by record.
That distinction is the actual mechanism behind del.ai's claim that AI agents go live on day one of cutover instead of arriving as a roadmap item months later. An agent that reads against a clean, single ontology built during migration behaves differently than one bolted onto a NetSuite-shaped schema after the fact, patched together by whichever integration happened to be available. Weeks 3-4 are unglamorous and necessary. Nothing in this phase is visible to end users yet. By week 5, it is the foundation everything else stands on.
Weeks 5-9: Parallel Run, Where Training Happens
This is the stretch of the NetSuite Odoo migration week by week schedule that surprises most Controllers, because it does the work of two separate phases, build verification and team training, inside one five-week window instead of stacking them end to end.
Team training happens inside the parallel-run window, weeks 5 through 9, not as a separate onboarding phase before or after cutover. NetSuite and Odoo run live side by side during this window, so the team practices on real transactions inside Odoo with zero consequence if something goes wrong, because NetSuite remains the system of record until cutover weekend. Week 1 of parallel run feels different for most users; the interface, the navigation, and the muscle memory are all new. By week 3 of parallel run, which lands in calendar week 7 to 8 of the migration, most users report preferring Odoo's single-ontology interface over switching between the separate tools a NetSuite stack typically requires. There is no separate training budget line and no classroom phase scheduled around the migration. Training is the parallel run itself, not an add-on to it.
The rollback path also gets its first real test here, at the tail end of week 8, though the full mechanics of that test belong to the next section on cutover weekend. What matters for this section is simpler: by the time parallel run ends, the team is not being introduced to Odoo for the first time at go-live. Controllers have closed at least one full month-end cycle inside it. AP and AR staff have processed real invoices and real collections inside it, even while NetSuite was still the official system of record. That sequencing, training during the live overlap rather than in a compressed week before cutover, is what keeps the post-go-live productivity dip shallow instead of the kind that shows up in the next board pack.
Week 7-8 Audit Prep: Timing It Around Cutover, Not After
The audit question is usually the one Controllers ask last and worry about first.
Audit prep happens in weeks 7 and 8, inside the parallel-run window, not after go-live as an afterthought bolted onto a finished migration. The auditor gets walked through the source-to-destination mapping while both NetSuite and Odoo are still live and directly comparable, line by line, so there is no gap in the trail to explain after the fact months later. Year-1 close still happens on NetSuite books under this schedule; year-2 becomes the first full Odoo audit cycle, and by then the auditor has already seen the full mapping once, during weeks 7-8, rather than encountering it cold. The audit re-attestation cost that often surprises CFOs on a system swap, commonly $0 to $50,000 based on Big 4 and regional audit-firm public fee disclosures for system change reviews, is bundled into the fixed migration price under this model rather than arriving as a separate invoice.
This timing is deliberate, not incidental. Scheduling the auditor walkthrough during the parallel-run overlap, rather than after cutover, means the comparison artifact already exists: two systems producing the same numbers for the same period, with both available to inspect. The walkthrough produces a written mapping document the auditor signs off on before cutover weekend, so the same artifact that satisfies internal reconciliation also satisfies the audit trail.
Weeks 10-12: Cutover Weekend and Go-Live
An ERP cutover weekend, somewhere in weeks 10 through 12 depending on how parallel run landed, is the only moment NetSuite goes dark in this 90-day NetSuite to Odoo migration. By the time it arrives, the migration has already been validated for four or more weeks of parallel run, not one weekend of hope.
The gate that decides whether cutover happens at all is the per-step rollback path tested at the end of week 8. If that test passes, cutover weekend proceeds on schedule. If it doesn't, the team works the failure, NetSuite stays live, and cutover moves to the following week rather than happening on a fixed date regardless of readiness. The calendar serves the verification, not the other way around.
For qualifying migrations within the signed scope document, two working agents, a month-end close agent and an FP&A draft agent, go live on day one of the new system, not as a future roadmap item promised for some later release.
A short stabilization window follows go-live, where issues tied to the migrated configuration are handled inside the original scope, and anything that represents a genuinely new requirement gets scoped as a change order rather than folded silently into the original price.
This section covers what happens on the calendar during cutover. It does not cover the deeper case for why parallel run and rollback are structurally safe, what reconciliation checks, or how failure modes get caught before they reach your books. For that full risk and rollback breakdown, see NetSuite to Odoo Migration: Timeline, Risk, and What CFOs Need to Know.
What Pushes a Migration Past 90 Days
A 90-day promise that never names its own failure modes isn't a promise, it's marketing copy. Here is where this one breaks.
Quick Answer: What pushes a NetSuite to Odoo migration past 90 days?
Three things push a NetSuite to Odoo migration past 90 days: NetSuite OneWorld in scope (a hard disqualifier caught in discovery, not a delay), SuiteScript customization heavier than the pre-SOW discovery estimate found, and slow decision turnaround from the buyer during discovery week. Across del.ai's review of past discovery engagements, the second and third causes account for nearly all real-world slippage; OneWorld in scope is almost always caught during week 1-2 discovery, before a contract is signed, so it shows up as a disqualified lead rather than a missed deadline. Heavier-than-estimated SuiteScript customization surfaces real rebuild work that wasn't visible from the outside, and the schedule shifts to match it. A slow decision turnaround during discovery week stalls the disqualifier review that everything downstream depends on, since the buyer's dedicated point of contact is what confirms scope in the first place.
Source: del.ai analysis of 20+ mid-market NetSuite-to-Odoo migration scopings, 2024–2026. https://usedel.ai/insights/real-cost-netsuite
Three things push a NetSuite to Odoo migration past 90 days:
- NetSuite OneWorld in scope. This is a hard disqualifier rather than a delay: a migration involving OneWorld does not run long under this model, it does not run at all, because the multi-entity consolidation and per-jurisdiction tax handling OneWorld does are not something Odoo matches today.
- SuiteScript customization heavier than discovery estimate. When the pre-SOW discovery estimate finds customization heavier than expected, it surfaces real rebuild work that wasn't visible from the outside.
- Slow decision turnaround during discovery week. This one is entirely on the buyer's side of the ledger: a missing point of contact stalls the disqualifier review that everything downstream depends on.
The mitigations are structural, not aspirational: a dedicated forward-deployed engineer assigned per account, and a milestone-locked scope of work that makes slippage visible the week it happens, not the week before cutover.
In del.ai's review of past discovery engagements, the second and third causes account for nearly all real-world slippage (del.ai analysis of 20+ mid-market NetSuite-to-Odoo migration scopings, 2024–2026); the first, OneWorld in scope, is caught during week 1-2 discovery before a contract is even signed, so it shows up as a disqualified lead rather than a missed deadline. In the rare case where OneWorld scope surfaces only after a contract is signed, because a subsidiary was added mid-process or wasn't disclosed during discovery, the engagement pauses for a scope renegotiation rather than continuing on the original fixed price. That is a contract amendment, not a hidden change order.
None of these three are hidden in fine print. They are named here, in the same article that makes the 90-day claim, because a duration claim that can't survive naming its own exceptions isn't one worth trusting.
Is 90 Days Right for You
The disqualifiers named above are also the qualifier, restated as a short checklist.
A 90-day migration is realistic for you if:
- You're on single-entity NetSuite, not OneWorld
- Your NetSuite and ecosystem spend (license, partners, SuiteApps, integrations) runs $120,000 a year or more
- You're in the 50 to 500 employee range
- You have a renewal coming up in the next year, or an AI pilot that already stalled on top of NetSuite's closed schema
It is not a fit today if any of these are true:
- You run NetSuite OneWorld
- Your SuiteScript customization is heavy and largely undocumented
- There is no one on your team who can be the dedicated point of contact for discovery week
None of these are soft no's meant to be negotiated around. They are the same disqualifiers named in week 1-2 discovery above, surfaced here before you book a call instead of after.
If you're not sure which side of these lines your company falls on, that's exactly what the call below is for. Most companies don't know their own SuiteScript footprint well enough to self-diagnose, and that's normal, not a disqualifier in itself.
See If 90 Days Works for Your Migration
Built for mid-market companies on NetSuite spending $120,000+/yr, single-entity (not OneWorld), with a renewal coming up or an AI pilot that already stalled.
30 minutes. We'll walk your actual NetSuite setup, OneWorld status, and SuiteScript footprint against the calendar above and tell you which week your specific customizations land in, including if the honest answer is "not 90 days" or "not a fit yet." No pitch. You leave with a real week-by-week estimate, not a sales deck.