The Ultimate ERP Data Migration Checklist (10-Point Plan)

Most ERP projects don't fail because the software is configured incorrectly. They fail because the underlying data is corrupted, untransformed, or breaks referential integrity when loaded into the new system. When you move from a legacy on-premise system or disjointed accounting software into a modern ERP like SAP S/4HANA, Microsoft Dynamics 365, or Oracle NetSuite, you're not copying tables. You're translating decades of business logic into a completely new data model.

The urgency is real. SAP will end mainstream maintenance for ECC 6.0 (EHP 6–8) on December 31, 2027, with optional extended maintenance through 2030. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as 25% will fail catastrophically. (gartner.com) The data layer is where most of that damage occurs.

This 10-point plan gives you the specific actions, decision points, and failure modes that matter — not another project management template dressed up as a checklist. If you want the deeper patterns behind ERP data failures, read Why ERP Migrations Fail at the Data Layer: 9 Core Patterns.

Why Generic ERP Data Migration Checklists Fail

Most published ERP migration checklists read like project management templates: "define scope," "clean data," "test," "go live." They ignore the three things that actually kill ERP migrations:

1. Cross-module data dependencies. A single sales order in SAP or NetSuite touches CRM (customer record), inventory (item availability, valuation), finance (revenue recognition, GL posting), and shipping (fulfillment). Migrate any of those objects out of sequence and you break referential integrity across the entire system.

2. Compliance requirements that constrain your approach. For public companies, an ERP migration is a SOX 404 control change. Your external auditors will require extraction logs, transformation specifications, and sub-ledger to GL reconciliations. Manual Excel-based cleansing breaks the automated audit trail. See our deep dive on SOX-Compliant ERP Migration: Maintaining Audit Trails in Dynamics 365.

3. Data volumes that exceed native tool limits. NetSuite's CSV Import Assistant caps at 25,000 records per file. SAP's Migration Cockpit in S/4HANA Cloud limits batch jobs to 10 concurrent processes. These constraints work for initial master data loads. They break down when you're migrating years of transactional history across multiple entities. (docs.oracle.com)

Public filings confirm the business impact. SEC filings have described delayed shipments after ERP implementations due to inaccurate shipment dates, and vendor-invoice processing errors after ERP transitions that led to misstatements and material weaknesses in internal control. (sec.gov) That is why an ERP data migration checklist has to protect both operations and financial reporting.

The 10-Point ERP Data Migration Plan

1. Assign Named Data Owners by Module — Not Just a "Migration Team"

Every data domain — customers, vendors, items, BOMs, GL accounts, inventory — needs a named business owner who signs off on extraction rules, transformation logic, and post-load validation. This is not an IT task.

The finance team must define how "customer" data from three legacy CRMs maps to a single customer entity in the new ERP. The supply chain team must own inventory valuation methods. HR owns employee records. These owners are accountable for data accuracy at cutover and during the first financial close.

2. Audit and Triage: Define What Migrates, What Archives, What Dies

Don't migrate everything. Disciplined cleansing during the preparation phase typically reduces total ERP data volume by 20–30%, lowering migration time, storage costs, and cutover duration. (kissingerassoc.com) Use that as a planning range, not a promise — your actual reduction depends on how much technical debt your legacy system has accumulated.

Modern cloud ERPs are high-performance transactional engines, not cheap data lakes. Microsoft explicitly advises not to migrate more data than users need. SAP's S/4HANA Migration Cockpit is designed for initial operational data — historical closed-process data is out of scope. (learn.microsoft.com, help.sap.com)

The triage framework:

Financial data typically requires a strict retention period of 3–7 years based on regulatory compliance and tax authority rules. That window dictates what must be migrated versus archived. For a detailed framework on scoping decisions, see What Data Should You Actually Migrate to Your New ERP?.

Do not rely on users manually scanning spreadsheets to find duplicates. Build programmatic rules:

• Vendors: Match on Tax ID or standardized address fields.
• Customers: Identify records with no sales activity in the trailing 24 months.
• Items: Flag SKUs with zero inventory and no open purchase orders.

3. Map Cross-Module Dependencies Before Writing a Single Script

This is where ERP migrations diverge from helpdesk or CRM migrations. In an ERP, data objects are deeply interconnected:

• A sales order references a customer (AR), items (inventory), a price list (pricing engine), a warehouse (WMS), a shipping method (logistics), and a revenue schedule (GL).
• A purchase order references a vendor (AP), items (inventory), a receiving location (WMS), and an accrual (GL).
• A BOM (Bill of Materials) references parent items, component items, routing operations, and work centers.

SAP's migration documentation makes the sequencing problem explicit: Material BOM depends on material master, valuation data is a prerequisite for loading material inventory balances, and open sales orders are treated as a specific migration object rather than generic row data. The right model for any ERP migration: stable reference objects early, time-sensitive financial and inventory values late. (help.sap.com)

A dependency-aware load order looks like this:

1. Chart of Accounts / GL structure
2. Currencies, exchange rates, fiscal calendars
3. Subsidiaries / legal entities / intercompany rules
4. Master data: customers, vendors, items, warehouses, BOMs, routings
5. Inventory valuation and opening balances (AR, AP, GL trial balance)
6. Open transactions: sales orders, purchase orders, work orders
7. Historical transactions (if in scope)

Load items before sales orders. Load customers before invoices. Load the chart of accounts before anything financial. Break this sequence and you get orphaned records, broken foreign keys, and inventory that doesn't reconcile to the GL — the exact failure mode that crippled Hershey's $112 million ERP rollout, where the company couldn't process $100 million worth of orders despite having inventory in stock.

4. Freeze Transformation Rules and Build the Compliance Evidence Package

Don't let developers invent business rules in scripts. Decide them first: unit-of-measure conversions, tax-code normalization, intercompany mappings, inactive-item handling, revenue dates, historical exchange-rate policy, and how multi-entity balances roll forward.

Inventory valuation deserves special attention. When migrating inventory levels across multiple warehouses, you must ensure the cost basis (FIFO, LIFO, Standard Costing, Weighted Average) translates correctly to the new system's ledger. In S/4HANA, Material Ledger underpins material inventory valuation and supports multiple currencies and parallel accounting standards. If valuation logic is fuzzy, inventory reconciliation can drift even when row counts look perfect. (help.sap.com)

Multi-currency configurations require historical exchange rates. If you migrate a historical invoice originally billed in Euros into a USD-base ledger using today's exchange rate instead of the historical rate, your retained earnings won't tie out, and your financial close will fail.

For SOX-regulated companies, an ERP migration changes the system that generates, processes, and stores financial data. That makes it a SOX 404 control change, and your auditors will treat it as one. The SEC requires management's report on ICFR and requires evaluation of changes that materially affect ICFR. PCAOB AS 2201 then requires auditors to obtain evidence about the effectiveness of relevant controls. (sec.gov)

The artifacts your auditors will request:

• Extraction logs with timestamps, source system IDs, and record counts
• Transformation specifications documenting every rule applied to source data (e.g., mapping legacy account 1000 to new account 10100), version-controlled and approved by the business owner
• Named service accounts (not shared logins) for all migration execution
• Sub-ledger to GL reconciliation proving that the sum of AR + AP + inventory + fixed assets equals the GL trial balance in the target system
• Change management documentation showing access provisioning and approval workflows

For the full SOX compliance playbook, see SOX-Compliant ERP Migration: Maintaining Audit Trails in Dynamics 365.

5. Ban Uncontrolled Spreadsheet Edits

Native ERP import tools like NetSuite's CSV Import or SAP's Migration Cockpit require data to be extracted and cleansed externally before importing. The workflow — export, clean in Excel, reimport — is inherently manual and creates an undocumented gap in the audit trail. There's no automated log of what changed, who changed it, or why. Auditors flag this as a control deficiency.

Oracle documents a 25,000-record limit per uploaded file for NetSuite, requires external IDs for new transactions, and notes that updating a transaction without the correct line number creates a new line. Transactions with more than 1,000 lines may cause timeouts. (docs.oracle.com)

All data transformation must happen in an automated, version-controlled ETL pipeline. If a record fails validation, the pipeline should flag it, the source system should be updated, and the pipeline should be rerun. Every transformation is logged, repeatable, and attributable.

6. Validate Master Data Before Transactional Data

Master data is the foundation. If a customer record is wrong, every invoice, payment, and credit memo tied to it is wrong. If an item record has the wrong unit of measure or costing method, every purchase order, sales order, and inventory transaction is wrong.

Do not attempt to load the entire database in a single test pass. Begin by extracting, transforming, and loading only master data into a sandbox environment. Validate that the UI displays records correctly, that search indexing works, and that downstream workflows trigger as expected.

Validation sequence:

1. Customers and vendors. Deduplicate. Validate tax IDs. Confirm payment terms match the target system's options.
2. Items / products. Validate UOMs, costing methods (standard, average, FIFO), and inventory valuation. For manufacturers: validate BOMs, routings, and work center assignments.
3. Chart of accounts. Confirm every legacy account maps to a target account. Flag unmapped accounts as blockers.
4. Open balances. Run a trial balance comparison: source system vs. target system. They must match to the penny before you load any transactions.

7. Run at Least Two Full Mock Cutovers

A mock cutover is a timed, end-to-end rehearsal of the entire migration in a sandbox environment. It is the single most effective risk-reduction activity in any ERP project. Kissinger Associates reports that thorough testing phases correlate with 60% fewer post-go-live issues and faster user adoption. (kissingerassoc.com)

What a mock cutover validates:

• Elapsed time. You need to know exactly how many hours the full data load takes. If your cutover window is 48 hours and your mock takes 52, you have a problem — before it becomes a production crisis.
• Data integrity. Run reconciliation checks: record counts by object type, financial totals (AR aging, AP aging, inventory valuation, GL trial balance), and referential integrity (every sales order line links to a valid item and customer).
• Sequencing failures. You'll discover dependency errors — items that reference a warehouse that hasn't been loaded yet, or invoices that reference customers from a subsidiary that wasn't configured.
• Integration behavior. Every connected system — EDI, payment gateways, 3PL, CRM — needs to be tested against migrated data. A broken EDI connection with a major retailer can halt shipments on Day 1.

Schedule your first mock cutover no later than 8 weeks before go-live, and your second no later than 3 weeks before.

Reconcile sub-ledgers to the general ledger on every mock run. Counts alone are not enough. Tie A/R open items to receivables, A/P to payables, inventory quantities and values to inventory control, WIP and work orders to manufacturing balances, and fixed assets to asset registers.

-- Example reconciliation pattern
SELECT company, currency, SUM(open_amount) AS ar_open
FROM target_ar_open_items
GROUP BY 1,2;
 
SELECT company, currency, SUM(amount) AS gl_ar
FROM target_gl_entries
WHERE account IN ('110000','110100')
GROUP BY 1,2;

Avoid the financial errors detailed in 7 Costly Mistakes to Avoid When Migrating Financial Data.

8. Plan Your Cutover Window in Dollars, Not Hours

Cutover planning should start at least three months before go-live — not the week before. The cutover is not a weekend project; it's a coordinated operation involving data migration, integration repointing, user access provisioning, and business validation.

Three common strategies:

• Hard cutover (big bang). Legacy system goes dark on Friday night. New ERP goes live Monday morning. Works when data is clean, the team has rehearsed, and the business can tolerate a defined blackout window.
• Parallel running (soft cutover). Both systems run simultaneously for a defined period. Reduces risk but doubles workload and cost.
• Continuous sync with delta replay. Historical data is migrated weeks in advance, and a delta-sync pipeline captures new transactions created in the legacy system, streaming them into the new ERP. This reduces the final cutover window from days to minutes. For global supply chains or high-volume ecommerce operations where a 48-hour system freeze is unacceptable, continuous sync is often the safer option.

Choose based on your business's actual risk tolerance. A manufacturer with 24/7 production lines and EDI-connected suppliers has a very different cutover calculus than a professional services firm that can freeze invoicing for a weekend.

SAP notes that freeze periods or double maintenance may be required for some master data during cutover, and that some partially open orders may need to be closed or cancelled in the source system before migration. If Dynamics 365 Finance and Operations APIs are in the path, Microsoft documents default service protection limits: 6,000 requests per five-minute window and 52 concurrent requests per user, returning 429 responses when limits are hit. Don't discover these constraints at 2 a.m. on go-live weekend. (learn.microsoft.com)

The cutover runbook should be a minute-by-minute document with:

• Task name, owner, start time, duration, dependencies
• Go/no-go checkpoints at defined intervals
• Explicit rollback triggers (e.g., "if trial balance variance exceeds $X, abort and restore")

9. Protect Integrations — They Break First

A mid-market ERP typically connects to 10–20 external systems: payment processors, EDI networks, CRM, e-commerce platforms, WMS, 3PL, tax engines (Avalara, Vertex), HRIS, and BI tools. Each integration has its own authentication, field mappings, and API contracts.

Your ERP data is rarely just in the ERP. It's scattered across WMS, MES, PLM, CRM, tax engines, banking, payroll, and custom databases. Your migration inventory must include every upstream and downstream dependency, not just the database you can query today.

During migration, you need to:

• Inventory every integration and its data contract (which fields, which direction, which frequency)
• Repoint API endpoints from legacy to target in a coordinated sequence
• Test each integration independently with migrated data before cutover
• Plan for EDI specifically. Traditional EDI requires custom mapping per trading partner per ERP. Changing ERPs means rebuilding those mappings — a process that can take months if not planned early.

Broken integrations are the number one cause of "Day 1 can't ship" emergencies. Don't let this be a last-minute discovery.

10. Establish Post-Go-Live Hypercare and Document Everything

The migration doesn't end at go-live. The first 30–90 days are where data issues, integration bugs, and user adoption gaps surface. Staff a dedicated support team for this period:

• Daily standups to triage issues by severity
• Finance-specific validation during the first monthly close — this is the real test
• Issue tracking with root cause analysis (is it a data problem, a config problem, or a training problem?)
• Performance monitoring — watch transaction volumes, error rates, and system response times

Don't dismantle your migration team on Day 2. The first financial close in the new ERP is the moment of truth.

Every extraction script, transformation rule, validation result, reconciliation report, and cutover decision should be documented and stored in a controlled repository. This is both a compliance requirement and a practical necessity. If an auditor asks in Q4 why your opening balances don't match your legacy closing balances, "we fixed it in Excel" is not an acceptable answer. If a new team member needs to understand why certain historical transactions weren't migrated, the decision log should answer that question without requiring tribal knowledge.

ERP Data Migration Tools: Native vs. iPaaS vs. Expert Services

Not all migration approaches are equal. The right choice depends on data volume, complexity, compliance requirements, and cutover tolerance.

SAP Migration Cockpit supports direct transfer, file, and staging-table approaches and is aimed at initial operational data. It transfers postings "as-is" with no capability for data transformation or enrichment, no selective migration of historical data, and no support for phased balance-then-detail loading. For complex enterprise environments, organizations typically need to supplement it with validation and governance tooling. (help.sap.com)

NetSuite's CSV Import works for small-to-medium datasets but caps at 25,000 records per file and requires external data preparation. Transactions with more than 1,000 lines may cause timeouts. The workflow is inherently manual and creates audit trail gaps. (docs.oracle.com)

iPaaS platforms like Celigo and Boomi are designed for ongoing, real-time data synchronization between active cloud applications — not bulk historical migration. Legacy data typically requires complex transformation before loading, which these platforms aren't natively built to handle at scale. (docs.celigo.com)

DIY scripts and ETL are the right move when the source is unusual, on-prem, or transformation logic is too specific for vendor tools. They become dangerous when code is unversioned, evidence is missing, or the whole plan depends on one engineer. SOX-scoped migrations still need control documentation, testing evidence, and repeatable execution.

When to Bring in a Dedicated Migration Partner

The honest answer: not every ERP migration needs external help. If you're loading clean master data into a single-entity NetSuite instance with no SOX requirements and no historical transaction migration, your implementation partner's standard tooling will likely suffice.

But if your migration involves any of the following, the risk profile changes:

• Multi-entity, multi-currency configurations with intercompany elimination rules
• TB-scale transactional history that must be migrated (not just archived)
• SOX, GxP, or FDA compliance requiring full audit trail documentation
• 20+ connected integrations that must be repointed and tested
• A cutover window measured in dollars-lost-per-hour, not days

At ClonePartner, we've executed 1,200+ data migrations across ERP, CRM, and helpdesk platforms. For ERP-specific work, we bring continuous data sync capabilities that compress cutover windows, automated sub-ledger to GL reconciliation that satisfies auditors, and engineer-led execution that goes beyond what native CSV imports or iPaaS connectors can handle.

What This Checklist Won't Fix

A checklist can't compensate for:

• Bad scoping decisions made during implementation. If your implementation partner committed to migrating 15 years of closed purchase orders without costing the data migration effort, no checklist saves you from the schedule impact.
• Lack of executive sponsorship. Data migration requires business users to spend significant time validating, cleansing, and signing off. Without executive backing, these people get pulled back to their day jobs at the worst possible time.
• Unrealistic cutover timelines. Hershey's compressed a 48-month implementation into 30 months. The testing phases got cut. The system went live during peak demand season. The result was a 19% decline in quarterly profits and $100 million in unfulfilled orders. No checklist prevents that kind of organizational decision.

The checklist gives you the structure. Execution still requires discipline, the right people, and honest risk assessment. If your current plan still says "export everything, clean it up, and import it during cutover," you don't have a migration plan yet. You have a hope strategy.