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. The data layer is where most migration 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. 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:

The "3–7 years" retention window in that table is a planning range, not a single rule. Actual requirements vary by jurisdiction and regulatory regime:

For cross-border operations, apply the most restrictive applicable requirement to each data category. This table is a starting point — confirm the specific rule with legal counsel for your jurisdictions.

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.

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.

Choosing between these isn't just a risk preference — it depends on measurable conditions. Use this decision model:

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 — define these quantitatively before go-live, not during the incident. Examples: abort and restore if trial balance variance exceeds a pre-agreed dollar threshold, if record rejection rate exceeds 1% of total records loaded, or if a Severity 1 integration failure (EDI, payment processor) is not resolved within two hours of cutover start.

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.

Special Case: Migrating Zendesk to Salesforce Service Cloud (Apex & Custom Objects)

While ERPs have strict financial dependencies, CRM migrations introduce a different data layer threat: execution context. A frequent question we get is: "How do I migrate from Zendesk to Salesforce Service Cloud when I have custom objects and Apex triggers?"

The answer is that you must decouple your data load from your automation. If you try to load hundreds of thousands of Zendesk tickets into Salesforce while active Apex triggers are running, you will hit CPU time limits, SOQL 101 limits, and row lock errors. When you migrate custom objects to Salesforce Service Cloud, you need a specific checklist to manage the metadata and execution context.

Pre-migration: audit triggers & test coverage

Before moving a single record, audit the target Salesforce environment.

• Audit triggers and related classes: Document every active trigger on Cases, Accounts, Contacts, and any target custom objects. Identify which helper classes they call.
• Collect current test coverage: If your organization's Apex test coverage is hovering near the 75% minimum, a massive data load might uncover hidden bugs or skew data volumes, preventing future deployments. Fix failing tests before the migration.

Metadata deployment plan checklist

Schema changes must precede data. Create a strict sandbox deployment plan to ensure environments stay in sync.

• Map custom-object relationships: Salesforce enforces strict rules on relationships. Master-Detail relationships require the parent record to exist before the child can be loaded. Lookup relationships are more forgiving but still require accurate external IDs.
• Deploy schema first: Push all custom fields, custom objects, and external ID fields to production before the data cutover begins.

Data migration ordering and trigger-safe load steps

Your recommended data-load ordering for a Zendesk to Salesforce migration should look like this: Users -> Accounts -> Contacts -> Custom Objects (Parents) -> Cases (Tickets) -> Case Comments -> Custom Objects (Children) -> Attachments/Files.

• Bypass automation: Implement trigger-safe load steps. Use a Custom Hierarchy Setting or Custom Metadata Type to bypass Apex triggers, Workflow Rules, Process Builders, and Flows for the specific API integration user performing the migration.
• Batch sizing: Use the Bulk API for large volumes, but lower the batch size if you still encounter locking issues on highly skewed parent records.

Sandbox validation and test execution checklist

• Schedule sandbox validation runs: Use a Full Copy sandbox to rehearse the exact data load.
• Execute the load: Run the migration with automation bypassed, exactly as planned for production.
• Run Apex tests: After the data is loaded, run all local Apex tests to ensure the new data volume hasn't broken any existing assertions or caused SOQL timeouts.

Post-migration validation and monitoring

Once the data is in production, you must ensure the system behaves correctly with the new baseline.

• Reactivate automation: Remove the bypass flags for the integration user.
• Steps to validate trigger behavior after migration: Manually create and update test Cases and custom object records in the UI. Verify that routing rules, escalation triggers, and custom roll-up summaries fire correctly on the newly migrated dataset.
• Monitor logs: Watch the Developer Console and Apex exception emails closely for the first 72 hours of hypercare to catch any edge cases introduced by the legacy Zendesk data.

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

If that describes your situation, talk to our engineers.

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.