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, so we are not a neutral observer. We were founded in 2026 and have not yet completed a customer migration, which means the calendar below is the schedule we scope and contract to, not a report on projects already delivered. It is the sequence written into the scope document, not a marketing simplification of a longer project — and you should read it as a commitment we are asking to be held to rather than as a track record.
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.
Ninety days is the window del.ai scopes and contracts to, and it is conditional rather than 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 migration methodology, 2026
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.
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. That compression is what makes a fixed calendar possible in the first place, not optimism about how fast a team can work. Three conditions determine whether it holds for a specific company: 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 commitment is also structural: 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.
A published week-by-week schedule with named disqualifiers is rare enough that it is worth asking any vendor for one and seeing what comes back. The reason is structural rather than secretive: a time-and-materials engagement does not require the vendor to commit to a calendar, because under that contract the cost of a longer schedule sits with the buyer. 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: a signed migration is scoped with one forward-deployed engineer assigned for the full 90 days, not a rotating bench of whoever's available that week. The person who runs discovery week stays on the account through cutover weekend. That continuity is part of what the calendar depends on: nobody should have to re-explain the scope document to a new face in week 8.
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. The audit sorts every piece of custom logic into one of three buckets, and we do not publish a percentage for how the buckets usually split, because we have no delivered migrations to average and a made-up ratio would be the least useful number on this page. The buckets are: rebuild it in Odoo, drop it because a standard module already does it, or, where it is load-bearing and cannot be built inside the timeline, the company stays on NetSuite and the engagement ends here, not at cutover. What the two weeks produce is your split, on your customization inventory, before a statement of work is signed.
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.
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.
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 is expected to feel disorienting; the interface, the navigation, and the muscle memory are all new. The design assumption behind the five-week window is that a team needs a full close cycle inside the new system, not a demo of it, before anyone can say whether they are ready — and the window is sized to give them one whether or not the adjustment goes smoothly. 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.
The audit question is usually the one Controllers ask last and worry about first.
Audit prep is scheduled into weeks 7 and 8 of a 90-day NetSuite to Odoo migration, inside the parallel-run window, while both systems are still live and directly comparable line by line. The auditor is walked through the source-to-destination mapping before go-live, not after, so there is no gap in the trail to explain months later. Year-1 close still happens on NetSuite books under this schedule; year-2 becomes the first full Odoo audit cycle, and the auditor has already seen the complete mapping once, during weeks 7-8, rather than encountering it cold. Under a fixed-price scope of work, the audit re-attestation work that can surprise a CFO on a system swap is bundled into the migration price rather than arriving as a separate invoice, however much mapping documentation the specific auditor asks for. That is a commitment about the contract, not a forecast of your auditor's fee, which del.ai is in no position to quote and does not try to.
Source: del.ai migration methodology, 2026
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.
Cutover weekend is planned for weeks 10 through 12 of a 90-day NetSuite to Odoo migration, depending on how parallel run landed, and it is the only moment NetSuite goes dark. 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 it passes, cutover proceeds on schedule; if it doesn't, the team works the failure, NetSuite stays live, and cutover moves to the following week instead of happening on a fixed date regardless of readiness. The calendar serves the verification, not the reverse. Two agents are scoped to ship with the migration rather than after it, a month-end close agent and an FP&A draft agent, both currently at demo stage and built into the day-one scope we are designing toward for qualifying migrations within the signed scope document.
Source: del.ai migration methodology, 2026
A short stabilization window follows go-live, where issues tied to the migrated configuration are handled inside the original scope, while 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.
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.
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. The three are not symmetrical, and the schedule is built on that asymmetry rather than on a measured failure rate we do not have: OneWorld is designed to be caught during week 1-2 discovery, before a contract is signed, so it should surface as a disqualified engagement rather than a missed deadline, which leaves the second and third causes as the ones that can actually move a signed date. 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 migration methodology, 2026
Three things push a NetSuite to Odoo migration past 90 days:
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.
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.
The disqualifiers named above are also the qualifier, restated as a short checklist.
A 90-day NetSuite to Odoo migration fits companies on single-entity NetSuite, not OneWorld, spending $120,000 a year or more across the NetSuite ecosystem, in the 50 to 500 employee range, with a renewal coming up in the next year or an AI pilot that already stalled on a closed schema. It is not a fit today if the company runs NetSuite OneWorld, carries SuiteScript customization that is heavy and largely undocumented, or has no one on the team who can serve as 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 surfaced during week 1-2 discovery, named here before a call gets booked. Most companies do not know their own SuiteScript footprint well enough to self-diagnose against these criteria, and that uncertainty is normal, not itself a disqualifier — it is exactly what the discovery-week audit exists to resolve.
Source: del.ai migration methodology, 2026
A 90-day migration is realistic for you if:
It is not a fit today if any of these are true:
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.
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.
Sources
1. del.ai migration methodology, 2026