Most NetSuite exits are planned as a date. A weekend is chosen, the data is moved, the licenses lapse, and on Monday everyone uses the new system. That plan works for a general ledger and almost never works for an operation, because an ERP that has been in place for years is not one system. It is dispatch, pricing, invoicing, inventory, payroll inputs, and a dozen integrations, each with its own failure mode and its own set of people who will stop working if it is wrong. The exits that succeed are sequenced, not scheduled.
Why big-bang is the wrong default
A single cutover concentrates every risk in the business into one weekend. If any one of dispatch, invoicing, or the accounting sync is wrong on Monday morning, you find out with customers waiting and no working alternative. The failure is also hard to diagnose, because everything changed at once and there is no way to isolate which change caused the problem.
The staged alternative is not slower overall. It front-loads the discovery that a big-bang plan defers until the worst possible moment. Moving one capability at a time means each cutover has a small blast radius, a clear owner, and a definite answer to the question of what to do if it goes wrong.
- Failures are contained to one workflow instead of the whole operation.
- Rollback is realistic, because only one thing has to be reversed.
- Users learn one new workflow at a time rather than a new job all at once.
- Data quality problems surface early, on a small dataset, while there is still time to fix them.
- Each stage produces working software, so a delay in stage four does not erase the value of stages one through three.
Settle the contract and data questions before you give notice
The most expensive mistakes in an ERP exit happen before any code is written. Auto-renewal clauses, notice windows, and export limitations are negotiating leverage that disappears the moment the vendor knows you are leaving. Work through this list while the relationship is still routine.
| Item | What to confirm | Why it bites late |
|---|---|---|
| Notice period | The exact number of days before renewal that written non-renewal must be received, and in what form. | Missing the window by a day commits you to another full term at the renewal price. |
| Export rights | Which objects you can export, in what format, and whether transaction history and attachments are included. | Some exports omit line-level detail or file attachments, which you only discover after access ends. |
| Post-termination access | How many days of read-only access you get after the term ends, if any. | Zero-day access means every question about a two-year-old invoice becomes unanswerable. |
| Record retention | How long tax, payroll, warranty, and contractual records must be kept, and in what form regulators accept them. | Retention is your obligation, not the vendor's. It outlives the subscription. |
| Integration dependencies | Every third-party tool authenticating against the ERP, including ones built by a former consultant. | Undocumented integrations fail silently and are usually found by a customer, not a monitor. |
| Customization inventory | Every custom script, saved search, and workflow, and the business rule each one encodes. | Years of rules exist only inside customizations and are otherwise lost at cutover. |
Move the highest-value capability first
The instinct is to start with something safe and peripheral. That is a mistake. Peripheral capabilities do not prove anything, do not relieve any pressure, and do not tell you whether the new system fits the operation. Start with the workflow where the current system costs you the most every day, because that is where the answer matters and where the people who care are paying attention.
In a trades services engagement facing a six-figure renewal, that meant job management, dispatch, mobile field updates, customer records, notifications, and reporting, the workflows the ERP was actively obstructing. Those moved onto a bridge stack of Airtable for data, Stacker for the office and field interfaces, and Make.com for automation, operational in about six weeks. That was fast enough to decline the renewal, which was the point: a custom platform of real complexity takes six to twelve months, and the renewal was not going to wait.
The bridge was deliberately temporary, and its limits were known in advance. Record and API limits create pressure as volume grows, complicated pricing and job-costing rules are awkward inside formulas and automations, and audit trails are thinner than a growing company eventually needs. Those were acceptable for a defined period because the bridge was also doing something a specification could not: showing how the business actually operated, which separated genuine requirements from habits the old ERP had imposed. The purpose-built platform that followed was shaped around dispatch, field work, pricing, and invoicing as first-class capabilities, and it launched with cleaner data than the ERP ever held.
The bridge was intentionally temporary. It let the team observe how the business actually operated, separate real requirements from legacy-system habits, resolve data quality issues, and shape the eventual product around three distinct customer and workflow models.
The cutover sequence
This is the order of operations we use for each capability. It applies to a bridge stack and to a custom platform equally, and it repeats for every stage rather than running once.
- 1
Confirm the contract position and pull a full archival export while your license is unquestionably active.
- 2
Inventory the integrations and customizations, and name an owner for each. Anything without an owner is a risk you have not accounted for yet.
- 3
Pick the single capability with the highest daily operational cost, and write down what success looks like in numbers a dispatcher or a controller would recognize.
- 4
Map and clean the data that capability needs, and only that data. Merge duplicate customers, resolve orphaned records, and standardize the fields the workflow depends on.
- 5
Build the capability in the new system and load the cleaned data. Reconcile record counts and financial totals against the ERP before anyone uses it.
- 6
Run both systems on the same live work for a bounded period, with the ERP still authoritative. Compare outputs daily and fix differences in the new system, not in the comparison.
- 7
Switch the source of truth on an agreed date, keeping the ERP writable for a short, stated window in case you have to reverse.
- 8
Repoint the integrations one at a time and confirm each downstream system receives what it expects.
- 9
Set the old capability to read-only, announce it, and stop dual entry the same day. Half-retired systems are how parallel running becomes permanent.
- 10
Decommission only after retention obligations are satisfied and the archive you pulled in step one has been verified as readable.
Running both systems, and how to decide when to stop
Parallel running is a validation technique, not a safety blanket. It is expensive while it lasts: staff enter work twice, discrepancies have to be investigated, and both systems keep accruing cost. Its value is entirely in the comparison it produces, and that value drops sharply once the comparison stops finding anything.
| Phase | Typical duration | Old system's role | Exit condition |
|---|---|---|---|
| Pre-cutover validation | 2–4 weeks per capability | Authoritative; new system shadows it | Reconciliation differences fall to a rate the team can explain individually |
| Post-cutover overlap | 1–2 weeks | Writable fallback, not used day to day | One full business cycle completes with no rollback trigger fired |
| Read-only reference | About 90 days | Historical lookup only | Reference lookups drop to near zero and the archive is verified |
| Retention hold | As required by law or contract | Archived export, no live system | Statutory and contractual retention periods are satisfied |
The rollback plan
A rollback plan is not a paragraph in a project document saying you will revert if necessary. It is a specific set of triggers, agreed before the cutover, that anyone on the team can invoke without a meeting. The reason to write them down early is that during a bad cutover the people making the decision are tired, invested, and inclined to push through one more hour.
Rehearse the reversal at least once against production-shaped data. A plan that has never been executed is an assumption. The rehearsal usually finds the real problem, which is not the database restore but the integrations that have already sent records downstream and the users who have already entered work in the new system.
- Named triggers with thresholds (jobs not dispatching, invoices not generating, a reconciliation gap above a stated figure) and the person authorized to call it.
- A decision deadline. If the cutover is not confirmed healthy by a stated hour, you revert; you do not extend.
- A tested restore path for the new system's data, so work entered after cutover is not lost when you go back.
- A written procedure for reversing each repointed integration, including any records already delivered downstream.
- A communication script for staff and, where relevant, customers, written before it is needed rather than during the incident.
- A rule that the old system stays writable and licensed until the overlap window formally closes, whatever the pressure to save the fee.
Common questions
- How long does migrating off NetSuite actually take?
- It depends on whether you are replacing it with a bridge or with a purpose-built platform. A no-code bridge covering core operational workflows can be running in roughly six weeks, which is usually enough to beat a renewal deadline. A custom platform of meaningful complexity is a six to twelve month build, which is why the two-phase pattern exists.
- Should we run NetSuite and the new system in parallel?
- Yes, but for a bounded period with a defined end date. Parallel running is how you validate that the new system produces the same financial and operational outputs on live work. It becomes harmful when it has no exit condition, because dual entry quietly becomes the permanent process and neither system is ever fully trusted.
- What do we do about accounting when we leave NetSuite?
- NetSuite's strength is holding financial and operational data together, so leaving means deliberately splitting those concerns. A common answer is to keep operations in the new platform and move accounting to a cheaper system with a well-documented API, syncing invoices and payments across a clean boundary. The decision is worth making early, because it shapes the integration work in every later stage.
- How much of our history do we need to migrate?
- Less than most teams assume. Migrate the data the new workflows need to operate, and keep the rest as a verified archive plus a read-only reference period. Carrying every legacy field forward imports the data quality problems you were trying to escape and adds cost without adding capability.
- Can we cancel the renewal before the replacement is finished?
- Only if something real is running by the notice date. That is the specific problem a bridge stack solves: it replaces the core workflows fast enough to decline the renewal while the permanent system is still being designed. Cancelling on the assumption that a build will land on time is how migrations end up back on the old platform at a worse price.
- When should we not migrate off NetSuite?
- When the platform fits your operating model and the friction is coming from configuration or process rather than the product. Replacing a system that broadly works is expensive and rarely repays the disruption. The case for leaving is strongest when licensing structure is causing you to keep people out of the system and when the workflows themselves are the wrong shape for how you operate.