Disclosure: del.ai has a commercial interest in this topic — we sell NetSuite-to-Odoo migrations, and the parallel-run methodology described below is the one written into the engagements we scope. We were founded in 2026 and have not yet completed a customer migration, so treat this as the standard we contract to rather than a delivery record. The checklist itself is vendor-agnostic: if you're evaluating a move to Odoo, SAP, Dynamics, or anything else, the gates hold regardless of which system you're leaving or landing on.
Most ERP migration checklists read like packing lists: extract data, configure the new system, train the team, go live. That format misses the part that actually determines whether the project works. An erp migration checklist built around tasks tells you what to do. One built around decision gates tells you when you're actually ready to do it, and when to stop. This article is the second kind. It walks a pre-migration audit, the data migration steps that follow, how to validate the new system before cutover, the go/no-go criteria for cutover itself, and the conditions that should trigger a rollback if something breaks.
If you searched specifically for a netsuite to odoo migration checklist, the worked examples in the parallel-run and rollback sections below are drawn from how that migration is scoped. If you want the narrative version first, why the phases run in this order and what each one is actually for, before working through the checkbox-level detail here, see The Sequence, the Gates, and the Rollback.
We are not going to open this with a failure rate. The ERP failure and overrun statistics in circulation come overwhelmingly from consultancy surveys drawn on enterprise samples, which is the wrong population for a 50-to-500-employee company, and quoting one would make this page look better sourced than it is. The structural argument does not need one.
Here it is. A checklist made of tasks can be completed in full and still permit a premature cutover, because "configure the new system" and "confirm the new system is correct" are two different items and a task list treats them as the same kind of thing: something you tick. Ticking the first does not evidence the second. That is why the rest of this article is organized around explicit go/no-go gates rather than a flat task list — a gate is the only structure that can return the answer "no," and "no" is the only output that stops a cutover the calendar wants to happen anyway.
The cost of getting this wrong isn't abstract. A premature cutover means reconciling a broken general ledger during the next close, re-running reports finance already signed off on, and explaining the gap to an auditor who wasn't warned it was coming. None of that shows up in a checklist that only tracks whether steps were completed.
The mechanics below, particularly the parallel-run section, are illustrated using a NetSuite-to-Odoo migration as the concrete example, since that is the migration del.ai sells and scopes. The gates apply to any ERP-to-ERP move.
A pre-migration ERP audit checklist has five parts: a feature and customization gap audit, a data quality baseline, an audit-cycle calendar check, an integration inventory, and an access and ownership review. List every custom module, workflow, and integration on the current system, then score each one as rebuild, drop, or stay before signing anything. Count duplicate records, orphaned entries, and unmapped general ledger accounts so data quality is a number, not a vague promise. Map close periods and any external audit fieldwork windows, because cutover can never land inside either one. Inventory every connector, banking, payroll, EDI, tax engines, e-commerce, that has to be rebuilt or re-pointed at the new system. Confirm who holds admin credentials today and what data-export rights exist if the migration partner disappears mid-project. Skip any of these five and a manageable project turns into a mid-migration surprise.
Source: del.ai migration methodology, 2026; SysGenPro, "Finance ERP Deployment Best Practices to Minimize Close Disruption During System Change," 2026. ↗
This audit should happen before you sign anything, not during week one of the engagement. It doubles as a filter on the vendor: a partner who can't produce this list before the statement of work is a partner asking you to discover the gaps live.
An ERP data migration should run through six steps in sequence; skipping the order creates the risk. First, extract and map every field to an explicit destination before a single record moves, including fields marked "not migrated, archived instead." Second, separate historical transactions from open balances into two streams, because a miscoded closed invoice is an annoyance while a miscoded open AR balance is a number the team is about to operate on. Third, stage everything in a non-production environment; never land data directly in a live system. Fourth, reconcile every migrated object, trial balance, AR and AP aging, inventory counts, fixed asset registers, line by line against the source rather than trusting the new UI "looks right." Fifth, preserve the full transaction history and audit trail rather than carrying forward only today's balances. Sixth, trace every migrated record back to its source automatically, so drift gets flagged rather than caught by spot-checking a sample.
Source: del.ai migration methodology, 2026
The erp data migration steps below apply regardless of which two systems are involved. The sequence matters more than any individual tool.
Extract and map first, move nothing yet. Build an explicit, field-level mapping from the source schema to the destination schema before a single record moves. Every field on the old system needs a documented destination, even if that destination is "not migrated, archived instead."
Separate historical transactions from open balances. Closed, historical transactions and current open balances validate differently and carry different risk if something's wrong. A miscoded historical invoice from three years ago is an annoyance. A miscoded open AR balance is a number your team is about to operate on. Treat them as two migration streams, not one.
Stage before you land in production. Migrate into a non-production environment first, always. Never move data directly into a live destination system. Staging is where mapping errors surface without touching anything anyone depends on that day.
Reconcile every migrated object against the source. Trial balance, AR and AP aging, inventory counts, fixed asset registers, all of it, checked line by line against the system you're leaving. A migration that "looks right" in the new UI and hasn't been reconciled against the source hasn't actually been validated.
Preserve the full transaction history, not a current-state snapshot. A migration that carries forward only today's balances and drops the trail behind them is not defensible to an auditor later. The full history has to move, with the audit trail intact, or the new system starts its life with a gap that eventually gets asked about.
Trace source to destination automatically. Every migrated record should be traceable back to its source, with drift flagged automatically rather than caught by someone spot-checking a sample. Manual spot-checks catch what you happen to look at. A reconciliation pass that traces every record catches what you didn't think to check.
Get these six steps right and the data migration itself stops being the risky part of the project. The risk moves to the next question: how do you know the new system is actually ready to run the business.
You validate an ERP migration before cutover by running the source and destination systems live, in parallel, for a defined window measured in weeks, and reconciling on a fixed cadence until every discrepancy has a documented root cause and a fix. Process the same real transactions in both systems during that window, not synthetic test data, so behavior is compared under actual operating conditions. Bring the external auditor into the parallel-run window itself, not after cutover, so the audit trail stays defensible. Require sign-off from the finance team who will operate the new system daily, not just IT or the vendor delivering the project. A parallel run that skips any of these four elements is a demo, not a validation, and a demo is not a basis for a go decision on your books.
Source: del.ai migration methodology, 2026
A parallel run validation checklist works because it tests the new system under the one condition that actually matters: real transactions, real edge cases, real people operating it, while the old system is still there as the source of truth. Here's what that looks like in practice.
Run both systems live, for weeks, not days. The source ERP stays fully operational. The destination system runs alongside it, processing the same activity. Size the window by what it has to contain, not by how long feels reassuring: a parallel run shorter than one full close cycle never exercises month-end at all, and month-end is where accruals, revaluations, allocations and cutoff entries live — the logic least likely to have been reproduced correctly and least likely to surface in daily transaction flow. Del.ai scopes five weeks, weeks five through nine of a 90-day migration, for that reason.
Process identical transactions in both systems. Every invoice, payment, and journal entry that runs through the old system during the window also runs through the new one. This is what separates a real validation from a synthetic test: synthetic data can't surface the specific weirdness in your actual chart of accounts or your actual customer records.
Reconcile on a fixed cadence with a mismatch-resolution loop. Weekly is the cadence del.ai scopes, because it is short enough that a discrepancy is traceable to the week that produced it. Every discrepancy gets a documented root cause and a fix before the next reconciliation cycle, not a shrug and a note to check it later. A mismatch that carries forward unresolved into week three is a warning sign about the whole project, not a detail to clean up at cutover.
Bring the auditor in during the window, not after. Waiting until after cutover to walk the auditor through the new system's mapping is how a routine system change turns into a re-attestation fire drill. Walking them through it while both systems are still live and reconciling gives them time to raise concerns while there's still a system to compare against.
Require finance sign-off, not just IT sign-off. The team that will operate the new system daily, closing the books and running AP and AR in it, needs to confirm readiness themselves. A migration that IT and the vendor call "done" but finance hasn't actually run independently isn't validated. It's untested with a green checkmark on it.
This is the same mechanic del.ai scopes into NetSuite-to-Odoo migrations, for qualifying migrations within the signed scope document: NetSuite stays live and fully operational through the parallel-run window, and cutover does not happen until reconciliation proves the numbers match. It's not a special feature. It's the standard the rest of this checklist is built around, applied to one specific system pair.
For the full mechanism, reconciliation gates, a rehearsed rollback, and how the risk is allocated in the contract, see Parallel-Run, Not Cutover: The De-Risking Method del.ai Contracts To.
ERP migration cutover go/no-go criteria are binary, not a feeling of readiness: full reconciliation complete on every account and balance within an agreed variance threshold, auditor or compliance sign-off obtained if any audit period overlaps the date, cutover scheduled outside close and audit windows as a hard rule, a rollback plan documented and tested before cutover weekend, finance team confirmation after operating the new system independently during parallel-run, and support coverage confirmed for the first week post-cutover with a named point of contact. If any one of these six is unmet, the answer is no, and the parallel-run window extends until it's met. None of the six is a judgment call made under schedule pressure on a Friday afternoon; each one is a fact that either checks out or doesn't. That binary structure exists precisely because ambiguous readiness is the condition that lets schedule pressure make the call instead of the data.
Source: del.ai migration methodology, 2026
Turn "we think we're ready" into a checklist you can actually fail. These erp cutover criteria are meant to be copied directly into your own migration plan, not treated as a description of what a good migration generally looks like.
Six items, all binary. If the answer to any one is no, cutover doesn't happen that weekend. That's not a delay to apologize for. It's the checklist doing its job.
An ERP migration rollback should trigger on three conditions defined before cutover, not decided during a live incident: reconciliation variance exceeding the agreed threshold, a critical integration failing to reconnect, or a required audit sign-off being withheld. Design the reversal per step rather than whole-system: a full revert is a far larger action than any single one of those triggers justifies, and a plan whose only move is the largest one tends not to get used when it should be. Rollback authority sits with the finance team that owns the books, not with the vendor delivering the migration; the people accountable for the numbers decide when the numbers aren't trustworthy yet. The rollback runbook gets written and tested before cutover, never drafted in the middle of an incident, because a plan written under pressure is worse than no plan at all. Each trigger should map to one reversible action, so a single broken bank feed doesn't force the whole migration back to the old system.
Source: del.ai migration methodology, 2026
An erp migration rollback plan only works if it's written down before you need it. Define the triggers in advance:
Match the size of the reversal to the size of the failure. One broken bank feed, one miscoded account, one reconciliation gap: each of those is a reason to undo one thing, not to march the whole business back to the old ERP. A plan whose only move is the full revert forces a choice between over-correcting and doing nothing, and under pressure teams pick doing nothing. Design rollback to reverse the specific action that failed, and write down which action each trigger maps to before you need to look it up.
Rollback authority belongs to the finance team, the people who own the books and answer for them, not to the vendor running the migration. The party that has to live with a wrong number for the next four quarters is the party that should decide whether the numbers are trustworthy enough to go live on. Write that into the contract, whoever the vendor is.
Fixed-price terms matter here beyond the sales pitch, and the point is about the contract rather than about anybody's character. Under a fixed price, the cost of extending a parallel run because a gate failed lands on the vendor. Under time-and-materials, it lands on you. Whichever structure you sign, know which side of that line you are on before the gate is the thing standing between the project and a go-live date, and read the rollback clause in that light.
Write the runbook before cutover, in full, while everyone is calm and has time to think it through. A rollback plan improvised during a live incident, under the pressure of a broken GL on a Monday morning, is not a plan. It's a guess with worse odds.
del.ai contracts on this exact combination, parallel-run validation, fixed-price terms, per-step rollback defined before cutover, for NetSuite-to-Odoo migrations within the signed scope document, built for companies spending $120,000 or more a year on NetSuite with 50 to 500 employees, because that's the profile where a checklist like this one gets used for real, not as a thought exercise. If you're mapping this checklist against a different ERP pair, the gates still hold. Adjust the specifics, keep the structure.
30 minutes. Bring your own migration checklist and we'll tell you where it holds up and where it doesn't. No pitch. If you're mapping this against a NetSuite-to-Odoo migration specifically, that's the exact migration we're built to run.
Sources
1. del.ai migration methodology, 2026
2. SysGenPro, "Finance ERP Deployment Best Practices to Minimize Close Disruption During System Change," 2026. ↗