NewNetSuite 2026.1 — What's new

NetSuite Data Migration: Planning, Pitfalls & Best Practices

How to migrate data into NetSuite. CSV imports, staging environments, chart of accounts mapping, and the mistakes that blow up go-live timelines.

7 min read
Celigo Partner · NetSuite Experts150+ Projects Delivered10+ Years Experience
NetSuite Data Migration: Planning, Pitfalls & Best Practices

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:

  1. Export data from source system to CSV
  2. Map CSV columns to NetSuite fields
  3. Run a test import in sandbox
  4. Fix mapping errors and data quality issues
  5. Re-run until clean
  6. 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

PhaseDurationActivities
Data assessment1-2 weeksAudit source data quality, identify gaps, plan cleanup
Mapping and transformation2-3 weeksMap source fields to NetSuite fields, define transformation rules
Sandbox testing2-3 weeksImport into sandbox, validate, fix issues, re-import
Data cleanup1-2 weeksDeduplicate, standardize, fill gaps in source data
Dry run1 weekFull migration rehearsal with timing and validation
Production cutover1-3 daysFinal 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

Share:

Need help with your NetSuite project?

Whether it's integrations, customization, or support — let's talk about how we can help.

We respond within 24 hours.

Gustavo Canete

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.

12+ years experienceOracle NetSuite Certified +1
NetSuite DevelopmentSuiteCommerce AdvancedTeam ManagementTechnical Leadership+2 more

Get More Insights Like This

Join our newsletter for weekly tips, tutorials, and exclusive content delivered to your inbox.

Get in Touch