The question is usually asked as though the answer were a license fee. It is not. Moving off NetSuite is an operations project with a software deliverable attached, and the software is rarely the largest number on the page. What you are paying to remove is a system that years of process have grown around: the integrations that point at it, the report exports someone rebuilds in a spreadsheet every Monday, the customizations nobody documented after the implementation partner left, and a decade of transactional history that has to arrive somewhere intact. This page breaks the cost into the lines that actually move.
The destination is the smallest line item
Teams evaluating a move build a spreadsheet of subscription prices and stop there. That comparison answers a question nobody is asking. The cost of the destination platform is knowable, quotable, and usually the part with the least variance. Everything that has to happen for your business to arrive there intact is where the money goes.
| Cost line | Typical share of total | What moves it |
|---|---|---|
| Discovery and operational blueprint | 5–10% | How many departments the ERP touches, how much of the real workflow already lives outside it, and how many undocumented customizations exist. |
| Replacement software | 40–55% | Whether you are configuring a fitted product, assembling a bridge stack, or building a platform around your operating model. |
| Data extraction and cleansing | 15–25% | Years of history, entity count, and how much of your data quality was enforced by convention rather than by the system. |
| Integration rebuild | 10–20% | Accounting, payments, payroll, communications, and fleet or inventory systems that currently point at NetSuite. |
| Parallel running and reconciliation | 5–10% | How long both systems stay live and how much duplicate entry that requires from the people doing the job. |
| Training and rollout | 5–10% | Headcount, shift patterns, and how far the new workflow diverges from the habits the old platform created. |
The shares hold up better than the absolute figures. If a proposal you are reading puts 80% of the budget into building software and 5% into data, it has not been scoped by anyone who has done this before.
Discovery, and why skipping it costs more
The instinct is to treat discovery as overhead on the way to real work. In an ERP exit it is the cheapest insurance available, because the thing you are replacing is not the software. It is an operating model that has quietly bent itself around the software for years, and nobody in the building can fully describe it from memory.
A discovery phase on this kind of work runs $20,000 to $50,000 and takes three to six weeks. It is worth that only if it answers hard questions rather than producing a diagram.
- Which workflows genuinely run in the ERP, and which already run in spreadsheets alongside it
- Which requirements are real and which are habits the platform created
- Every downstream consumer of ERP data, including the ones that are a scheduled export into someone's inbox
- What has to be retained for audit, tax, or contractual reasons, and in what form
- Which customizations are load-bearing and which were built for a process that ended years ago
- Where the renewal date sits relative to any realistic delivery sequence
Data extraction and cleansing breaks more budgets than anything else
This is the line that ruins schedules. It is also the line most often quoted as a flat fee by people who have not looked at the data. Extraction itself is mechanical and usually a couple of weeks of work. Cleansing is not, because the cost tracks data quality rather than data volume. A clean two-million-row transaction table is cheaper to move than a filthy fifty-thousand-row customer table.
Expect duplicate customer and vendor records created by staff who could not find the existing one, addresses stored in inconsistent shapes, dates held as text, part numbers with trailing whitespace, and business rules enforced by nothing more than a convention people followed most of the time. Every one of those has to be found, decided on, and either fixed or deliberately carried across. The decisions are the expensive part, and they belong to your people rather than to the delivery team.
The integration rebuild
NetSuite is usually the hub, which means every connection into it has to be re-pointed. The cost is not linear in the number of integrations; it depends on which end you control. A documented API with a sandbox may be a week. A connector maintained by a vendor who built it for a platform you are leaving may be a month of negotiation before a record moves.
- Accounting or general ledger, which almost always needs reconciliation logic rather than a straight field mapping
- Payments and merchant processing, including stored tokens that may not be portable
- Payroll and time capture
- Customer communications, notifications, and document generation
- Fleet, inventory, purchasing, or field hardware, depending on the operation
- Reporting and BI tools whose queries are written against ERP table structures
Budget for the ones nobody mentions in the first meeting. In practice there is always at least one integration that surfaces during discovery because a single person maintains it and has never had to explain it.
Parallel running and training
You cannot switch a business off for a weekend. For some period both systems are live, which means either duplicate entry or a synchronization layer that itself has to be built and then thrown away. This is genuine cost, and it is usually absorbed by the operating team rather than the project budget, which is why it disappears from business cases.
Run parallel for as short a period as the risk allows. Two to six weeks per capability is normal for operational workflows; a financial period close often has to be run twice regardless. The longer the overlap, the more the team quietly decides the old system is the real one.
Training cost is dominated by shift patterns rather than headcount. A field workforce that is never in the same room needs short, role-specific enablement delivered where the work happens, and a support path for the first two weeks after go-live that is staffed as though it matters. Under-funding the fortnight after cutover is the most reliable way to convert a good migration into a bad one.
The renewal you stop paying
The offset side of this calculation is real and routinely left out. Per-seat licensing, mandatory support tiers, implementation partner retainers, paid connectors, and the annual uplift on renewal all stop. So does the labor cost of the workarounds people built because the platform would not do the thing: the parallel spreadsheets, the re-keying, the seats you did not buy for field staff because the per-user price made it unattractive to put them in the system at all.
A trades services business facing a six-figure ERP renewal moved core dispatch, field updates, and invoicing onto a bridge stack in six weeks, avoiding roughly $100,000 in renewal cost while the real platform was designed around how the work actually ran.
Count the seat cost you would have to add over the next three years, not just today's bill. Growth against a per-user model is a cost curve, and it is often the line that decides the business case.
A worked example, and the two-phase path
The pattern that works most often is not a single migration. It is two phases: a fast bridge stack that gets you off the ERP before a renewal deadline, then a purpose-built platform designed with the benefit of everything the bridge period taught you. The bridge is deliberately temporary. It buys time, removes the renewal, and turns requirements-gathering into observation of working software rather than a workshop about what people think they do.
| Line item | Phase 1: bridge stack | Phase 2: purpose-built platform |
|---|---|---|
| Discovery and operational blueprint | $25,000 | Carried forward from phase 1 |
| Build or configuration | $60,000 | $380,000 |
| Data extraction and cleansing | $30,000 | $70,000 |
| Integration rebuild | $25,000 | $85,000 |
| Parallel running and reconciliation | $15,000 | $40,000 |
| Training and rollout | $10,000 | $35,000 |
| Elapsed time | 6–8 weeks | 9–14 months |
| Subtotal | $165,000 | $610,000 |
Two phases cost more in raw spend than a single clean migration would in theory, because some of the data and integration work is done twice. In practice the single clean migration is the theoretical option, not this one. The two-phase path removes the deadline pressure that causes teams to rebuild their old workflow in a new system because there was no time to ask whether the workflow was right.
It also changes what you are buying in phase two. By then you have observed the actual operating model for six months in software you can change in an afternoon, and the platform gets designed around that rather than around whatever the previous vendor's data model implied.
- 1
Find your renewal date and your contractual notice deadline before anything else. Everything sequences backwards from there.
- 2
Run a short discovery that inventories systems, integrations, data, and undocumented customizations. Insist on a costed sequence as the output, not a report.
- 3
Decide what history actually has to move and what can live in an archive. Do this before anyone prices the migration.
- 4
Get the highest-cost workflow off the ERP first, even if the destination is temporary. Reducing the dependency early is what gives you both value and negotiating room.
- 5
Run parallel per capability, not across the whole system, and set an explicit end date for each overlap.
- 6
Retire the ERP only after data, integrations, users, and a fallback plan are all confirmed, and keep the archive.
Common questions
- Can we just move to another ERP instead?
- Sometimes that is the right answer, and if a product genuinely fits your operation you should buy it. The costs on this page barely change if you do, because discovery, data cleansing, integration rebuild, parallel running, and training are the same work regardless of the destination. What changes is the software line and whether you are trading one set of vendor constraints for another.
- How long does a NetSuite migration take?
- A bridge stack that removes the core operational dependency can be live in six to eight weeks. A full replacement platform is usually 9 to 14 months, delivered as releases that each stand on their own. Anyone promising a complete cutover in under three months has not seen your integrations.
- What is the cheapest way to get off NetSuite before a renewal?
- Move only the workflows that create the dependency (typically dispatch or order management, field or floor updates, and invoicing) onto a configurable stack, and archive the rest read-only. That is generally a $100,000 to $200,000 exercise rather than a full platform build. It is a legitimate stopping point on its own if the bridge turns out to fit well enough.
- Why is data migration priced separately instead of included?
- Because nobody can responsibly price it before looking at the data. The variance between a well-maintained dataset and one with twelve years of duplicates and free-text fields is several multiples, not a percentage. A vendor who includes a flat data migration fee in a pre-discovery quote has either padded it heavily or intends to recover the difference through change orders.
- Should we keep any part of NetSuite?
- Occasionally, yes. Some businesses keep the financials module and move only the operational workflows, which cuts seat count sharply while preserving an accounting system that works. It is worth pricing before assuming a full exit, though be careful that the remaining integration surface does not cost more to maintain than the licensing you saved.