ERP Data Migration: How to Move 5 Years of Records Without Losing Your Mind

Data migration is the part of every ERP project that takes twice as long as planned and gets half the attention it deserves.

Here's the framework I use on every migration engagement.

Phase 1: The data audit

Before you write a single line of migration code, you need to know what you're dealing with.

For every source system, document:

• What data exists — entities, transactions, attachments, history
• Data quality — duplicates, missing fields, inconsistent formats
• Data owners — who in the business owns each dataset and can validate it
• Volume — record counts, file sizes, date ranges

This audit is not optional. Teams that skip it spend weeks later discovering that the customer database has 40% duplicate records, or that the GL history in the old system doesn't reconcile.

Phase 2: Define what moves and what doesn't

Not everything needs to migrate. In fact, trying to migrate everything is one of the most common migration mistakes.

Work with stakeholders to define:

• Active records: Current customers, vendors, items, open transactions — these almost always migrate
• Historical data: How far back? Usually 2-3 fiscal years of transactions for reporting; full history for documents
• Archived data: Old records that don't need to be in the new system but need to be accessible somewhere

Getting explicit sign-off on what's in scope saves enormous scope creep later.

Phase 3: Build the mapping

Data mapping is the detailed work of defining how each field in the source system maps to a field in NetSuite.

A good mapping document includes:

• Source field → Target field
• Transformation logic (e.g., "combine First Name + Last Name into Full Name")
• Default values for required fields that don't exist in source
• Exception handling (what happens when source data doesn't match validation rules)

This document becomes your contract with the business. Get it reviewed and signed off before you start building.

Phase 4: The extraction and transformation pipeline

The actual technical work. For most migrations, I build a pipeline that:

1. Extracts data from the source system via API, direct DB query, or export
2. Transforms it to match the target schema and business rules
3. Validates it against a set of rules before loading
4. Loads it into NetSuite via SuiteScript REST API or CSV import
5. Reconciles counts and spot-checks records after load

For file migrations (PDFs, attachments), the pipeline also needs to handle file storage, naming conventions, and linking files to the correct NetSuite records.

Phase 5: Testing migration runs

Never do a single migration run and call it done. Plan for multiple test loads:

• Mock run 1: Find the structural issues — broken mappings, missing required fields
• Mock run 2: Fix issues from run 1, validate counts and reconciliation
• Mock run 3: Full dress rehearsal with production data, timed
• Cutover: The real thing

Each test run should be treated seriously. If mock run 3 fails, you're not ready for cutover.

The cutover itself

Cutover is the transition from "old system is live" to "new system is live." For most migrations, this means:

1. Freeze the old system (no new transactions)
2. Run the final migration with the most recent data
3. Validate and reconcile
4. Open the new system for business

The length of the cutover window depends on data volume. For most mid-size companies, I plan for a weekend cutover — usually Friday evening to Sunday afternoon.

---

Migrations are hard, but they're predictable. The teams that struggle are the ones that underestimate the data quality work and overestimate the speed of the technical pipeline.

Start your audit early. Map everything. Test repeatedly. And build more time into your schedule than you think you need — you'll use it.