
Why data migration is the riskiest part of any NetSuite implementation
Every NetSuite implementation involves moving data from your old system into NetSuite. This sounds straightforward — export from the old system, import into the new one. In practice, data migration is responsible for more go-live delays, budget overruns, and post-launch fire drills than any other implementation phase.
The risk is not technical. NetSuite has robust import tools. The risk is data quality: inconsistent customer records, duplicate vendors, mismatched chart of accounts, historical transactions that don't reconcile, and item records that were organized differently in the old system than they need to be in NetSuite.
What data migrates (and what doesn't)
Must migrate
Chart of accounts. Your account structure needs to be mapped from the old system to NetSuite. This is rarely 1:1 — most companies restructure their chart of accounts during migration to take advantage of NetSuite's subsidiary, department, class, and location dimensions. This is business analysis work, not data work.
Open transactions. Unpaid invoices (open AR), outstanding bills (open AP), open purchase orders, and open sales orders need to transfer so your operations continue seamlessly. These carry forward as opening balances.
Customer and vendor records. Names, addresses, contacts, payment terms, tax settings, credit limits. This is where duplicate cleanup happens — most legacy systems have years of accumulated duplicate records.
Item records. Products, services, inventory items, and their current quantities and valuations. For companies with inventory, migration coordinates with a physical count at cutover.
Employee records. If using SuitePeople HR or just employee records for expense reports, timesheets, and approvals.
Should migrate (selectively)
Historical transactions. Closed invoices, paid bills, completed orders. Most companies bring 1-2 years of transaction detail and summary journal entries for prior years. Moving 10 years of line-item detail is usually unnecessary and expensive.
Notes and attachments. Customer notes, vendor notes, file attachments. Valuable but time-consuming to migrate. Prioritize by business impact.
Usually doesn't migrate
System-specific data. Reports, dashboards, saved searches, workflows, and customizations from the old system don't transfer. You rebuild these in NetSuite using its native tools.
User permissions and roles. These are configured fresh in NetSuite based on your role structure.
Migration approaches
CSV import (most common)
NetSuite's CSV Import tool handles most data types: customers, vendors, items, transactions, journal entries, and custom records. The process:
- Export data from source system to CSV
- Map CSV columns to NetSuite fields
- Run a test import in sandbox
- Fix mapping errors and data quality issues
- Re-run until clean
- Execute final import in production at cutover
CSV import works well for bulk data loads. Limitations: it can be slow for very large datasets (100,000+ records), and complex records with nested data (e.g., transactions with line items) require multiple import passes with proper sequencing.
SuiteTalk / REST API (for complex or large migrations)
For large datasets or records with complex relationships, API-based migration gives you more control. You write a migration script that reads source data, transforms it, and creates NetSuite records via SuiteTalk (SOAP) or the REST API.
This approach is better when:
- You need to create related records in a specific sequence
- Data transformation is complex (currency conversion, unit-of-measure mapping)
- You're migrating from another ERP with an accessible API
- Volume exceeds what CSV import handles efficiently
iPaaS-assisted migration
If you're already using Celigo or another iPaaS platform, you can build migration flows that extract from the source, transform, and load into NetSuite. This is especially useful when the source system has API access (Salesforce, QuickBooks Online, Dynamics) and the data mapping is complex.
The migration timeline
| Phase | Duration | Activities |
|---|---|---|
| Data assessment | 1-2 weeks | Audit source data quality, identify gaps, plan cleanup |
| Mapping and transformation | 2-3 weeks | Map source fields to NetSuite fields, define transformation rules |
| Sandbox testing | 2-3 weeks | Import into sandbox, validate, fix issues, re-import |
| Data cleanup | 1-2 weeks | Deduplicate, standardize, fill gaps in source data |
| Dry run | 1 week | Full migration rehearsal with timing and validation |
| Production cutover | 1-3 days | Final export, import, reconciliation, go-live |
Total: 8-12 weeks as part of the broader implementation. Data migration often runs in parallel with system configuration — you don't wait until the system is fully configured to start mapping data.
Common mistakes
Starting migration too late. Data migration should begin in the first weeks of the implementation, not the last. Discovering data quality issues at cutover is the most expensive time to find them.
Skipping the dry run. A full rehearsal import — timed, validated, reconciled — is non-negotiable. You need to know exactly how long cutover will take and what can go wrong. Surprises at go-live are unacceptable.
Not reconciling opening balances. If your opening AR balance in NetSuite doesn't match your closing AR balance in the old system, you will spend weeks reconciling after go-live. This is the single most common post-migration fire drill.
Migrating too much history. Every historical record you migrate adds cost, time, and risk. Most companies need 1-2 years of transaction detail. Anything older can be summary journal entries or kept in the legacy system for reference.
Ignoring data ownership. Someone needs to own the data cleanup — reviewing duplicates, standardizing addresses, confirming account mappings. This is business team work, not consultant work. If your team doesn't validate the data, the migration will carry forward every error from the old system.
Cutover planning
The cutover window — the time between stopping work in the old system and starting work in NetSuite — should be as short as possible. Most companies cut over during a weekend or at month-end.
Before cutover:
- Complete all open period activity in the old system
- Close the accounting period
- Run final data exports
- Verify sandbox import is clean
During cutover:
- Import opening balances (GL, AR, AP)
- Import open transactions (sales orders, purchase orders)
- Import current inventory levels (ideally with a physical count)
- Validate critical records and balances
- Test key workflows (create a sales order, process a payment)
After cutover:
- Reconcile every opening balance
- Run parallel reporting for one period (old system vs NetSuite)
- Monitor for missing data or mapping errors
- Keep the old system accessible (read-only) for at least 6 months
Frequently Asked Questions
Need help with your NetSuite project?
Whether it's integrations, customization, or support — let's talk about how we can help.

Gustavo Canete
Co-Founder & Development Director
Co-founder and Development Director at BrokenRubik overseeing technical excellence and development operations. 12+ years of experience leading NetSuite development teams and delivering complex enterprise solutions.
Get More Insights Like This
Join our newsletter for weekly tips, tutorials, and exclusive content delivered to your inbox.
Related Articles
NetSuite Implementation Partner: Red Flags & How to Choose
Most NetSuite implementations fail because of the partner, not the platform. 6 red flags, real cost ranges ($25K-$200K+), and the questions your vendor hopes you won't ask.
Acumatica vs NetSuite: Unlimited Users vs Ecosystem
Acumatica offers unlimited users. NetSuite charges per seat but has 3x the partner network. Compare pricing, manufacturing depth, and which ERP fits.
Best NetSuite Apps & SuiteApps: Top Applications for 2026
Curated list of the best NetSuite apps from the SuiteApp marketplace. Top SuiteApps and SuiteCloud extensions that extend NetSuite for your business.
Gustavo Canete