Ask anyone who has been through a NetSuite implementation which phase they underestimated, and the answer comes back the same nearly every time: data migration.
It never looks hard on the project plan. A couple of lines, a few weeks, “extract, transform, load.” Then reality arrives in the form of a customer file with 14,000 records, a third of them duplicates, an item list that includes SKUs discontinued during a previous decade, open invoices that don’t match the GL, and a debate about whether to bring ten years of transaction history that nobody can settle.
Migration is where implementation timelines quietly slip, and it’s also where the long-term quality of your NetSuite account gets decided. Migrate garbage and you’ll be cleaning it up for years. Migrate thoughtfully and your new system starts life with data people actually trust.
Here’s how to do it thoughtfully.
Decide What You’re Migrating (And Be Ruthless)
The first migration decision is scope, and the default instinct, “bring everything,” is nearly always wrong.
Master data is the easy part of the decision: customers, vendors, items, employees, chart of accounts, and their supporting lists all need to come across. The question is how much of each. That customer list from your old system includes every prospect who requested a quote in 2015. It probably doesn’t need to. A common and sensible rule is to migrate only customers and vendors with activity in the last two or three years, and archive the rest for reference.
Open transactions are non-negotiable. Open invoices, unpaid bills, open sales orders, open purchase orders, and inventory on hand must exist in NetSuite on day one so operations can continue.
Historical balances are how you preserve financial continuity without dragging history along. Migrating GL balances by period, typically as monthly or quarterly journal entries for the last one to two fiscal years, gives you comparative reporting without importing every underlying transaction.
Historical transaction detail is where the real debate lives. Some companies want years of invoices and orders in NetSuite for reporting and customer service. It’s possible, but it’s expensive: the volume is large, the data rarely maps cleanly, and every historical record must reconcile. Most companies land on migrating detailed history for a limited window, often the current fiscal year, and keeping the legacy system or a data warehouse available read-only for older lookups.
The principle: every record you migrate is a record you must clean, map, load, validate, and reconcile. Scope is the biggest lever you have on both timeline and quality.
Clean Before You Load, Never After
Once it’s inside NetSuite, bad data gets a NetSuite internal ID, gets referenced by transactions, and becomes dramatically harder to remove. Cleanup belongs before the import, in the source data or in the staging spreadsheets, without exception.
Cleanup work usually includes:
Deduplication. Customers and vendors especially. Define matching rules (name plus email, or tax ID, or address) and merge or eliminate duplicates before loading. This is tedious and it’s worth every hour.
Standardization. Consistent naming conventions, address formats, state and country codes, phone formats, item naming. Inconsistent data becomes inconsistent reporting.
Retirement. Inactive items, dead customers, obsolete accounts, unused classifications. If it hasn’t been touched in years, inactivate it in the legacy system and leave it there.
Enrichment. NetSuite will want fields your old system didn’t have: item types, tax codes, subsidiary assignments, classification segments like department, class, and location. Populate these during cleanup so records arrive complete.
Assign this work to people who know the data. The accountant who has lived with the vendor list for six years will spot problems no consultant would. And build cleanup time into the schedule explicitly, because it always takes longer than planned.
Map With the Target in Mind
Mapping means deciding exactly how each source field lands in NetSuite. Most of it is mechanical, but the exceptions define the project.
A few reliable trouble spots:
Chart of accounts. Migration is the ideal moment to rationalize a bloated chart. Don’t recreate 400 accounts because you had 400 accounts. Design the chart you want, then map the old accounts into it.
Customer and item categorization. Legacy systems often stuffed multiple meanings into one field. Unpack these into NetSuite’s proper structures during mapping.
Custom fields. Every “we need a custom field to hold this” during mapping deserves a question: is this data actually used, or is it just present?
Multi-entity structures. If you’re moving to NetSuite OneWorld with multiple subsidiaries, every record needs a subsidiary assignment, and intercompany balances need careful thought.
Good mapping is a design activity, not a clerical one. It’s where an experienced NetSuite consultant earns their keep, because they’ve seen how mapping choices play out in reporting and operations years later, and they’ll steer you away from the ones that hurt.
Load in Sandbox, Repeatedly
Never load production data cold. The tooling for NetSuite migration ranges from the built-in CSV import assistant (surprisingly capable for most master data and transactions) to scripted loads for high volume or complex relationships. Whichever you use, the process runs the same way:
Dry run one in sandbox exposes every mapping error, every missing reference, every record that fails validation. Expect lots of failures. That’s the point.
Fix and dry run two proves the fixes worked and gives you realistic timing for how long the full load takes.
Validate every time. Record counts match. Sample records look right. Open AR and AP totals tie to the legacy system. Inventory quantities and values match. GL balances by period reconcile to the old trial balance to the penny. Build a reconciliation checklist and run it after every load.
Then use the sandbox data for user acceptance testing. Testing against real migrated data catches problems that testing against demo data never will.
Plan the Cutover Like a Surgery
Cutover is the sequence that takes you from the last day on the old system to the first day on NetSuite, and it needs a written, timed plan. The typical shape:
Freeze the legacy system at a defined point, usually end of business on a Friday at month end. Extract final open transactions and balances. Load them into production NetSuite, following the sequence proven in dry runs: master data first, then open transactions, then balances. Run the full reconciliation checklist. Get sign-off from finance. Open NetSuite to users.
Every step should have an owner, an expected duration, and a checkpoint. Include a rollback decision point: if reconciliation fails badly, what’s the plan? Having thought about it beforehand is far better than deciding at 2 a.m. on Sunday.
The Mistakes That Cause the Most Pain
Underestimating cleanup effort, which compresses testing and pushes problems into production.
Migrating history nobody uses, doubling the effort for reports that get run twice.
Letting the consultants own the data. Your team knows the data; the partner knows the platform. Migration needs both, and the business must own the validation and sign-off.
Skipping dry runs to save time. This never saves time.
Leaving reconciliation to after go-live. Discovering that AR doesn’t tie during your first close is far more expensive than discovering it in sandbox.
Why This Determines the Whole Project
Data migration sits at the center of a NetSuite implementation because everything else depends on it. Configuration is tested against migrated data. Users learn on migrated data. Go-live succeeds or fails on whether the numbers reconcile. A clean, well-scoped migration makes every later phase easier; a rushed one poisons them all.
Treat it as the serious, business-owned workstream it is, and your new NetSuite account starts life clean, trusted, and ready to run the company. That’s a foundation worth the effort.
