ERP data migration is the phase most implementations underestimate. Businesses spend months evaluating platforms, negotiating contracts, and configuring workflows, then discover two weeks before go-live that their customer master has 12,000 duplicate records, or that their open purchase orders don’t map cleanly to the new system’s schema. A structured ERP data migration checklist does not prevent every problem, but it forces the right questions at the right time, so surprises surface in testing rather than on cutover day.
This guide covers the full lifecycle: pre-migration planning, data cleansing and mapping, trial runs and user acceptance testing, cutover execution, and post-go-live validation. The principles apply across platforms. Where platform-specific notes are useful, this guide references Zoho and NetSuite as representative examples.
Most ERP migration failures are not technical. The underlying system usually works. What breaks is the data itself, or the process around it. A 2023 survey by Panorama Consulting found that roughly 40% of ERP projects experienced significant data quality issues that delayed go-live. Understanding the failure modes helps you design the checklist to prevent them.
Before a single row of data is exported, the project team must agree on what will be migrated, who owns it, and what “good data” looks like in the new system.
List every data entity the new ERP will need at go-live. Common entities include: chart of accounts, customers, vendors, items or products, open sales orders, open purchase orders, open invoices, inventory balances, fixed assets, and employee records. For each entity, answer three questions: Where does it live in the legacy system? What is the cutoff date (if any)? Who owns the quality review?
Avoid the temptation to migrate all historical transactions. Most businesses need two to three years of transaction history for reporting. Data older than that can be archived separately and loaded on demand if needed. Limiting scope cuts migration time and reduces the surface area for errors.
Every major data domain needs a named business owner, not an IT contact. The finance team owns the chart of accounts and open transactions. The procurement team owns vendor master data and open purchase orders. The sales team owns customer master data. Owners are responsible for cleaning their data, signing off on the field mapping, and reconciling totals after migration.
Before extracting anything, document exactly which tables or modules in the legacy system hold each data entity. In a Tally or QuickBooks environment, this is relatively straightforward. In an older ERP or custom-built system, it may require working with IT to trace data lineage. This documentation becomes the foundation for every extraction script and mapping template.
Once scope is defined, extract raw data from the legacy system and profile it before mapping. Profiling means running statistical checks that reveal the actual state of the data, not the assumed state.
Never work directly against the production legacy system. Extract to a dedicated staging environment, typically a set of CSV or Excel files, or a staging database. This protects the legacy system and gives the team a fixed snapshot to work from. Date-stamp every extract so you know which version was used in each migration run.
For each extracted entity, check the following:
Document profiling results in a data quality scorecard. This scorecard drives the cleansing plan in the next phase and gives stakeholders visibility into migration risk before testing begins.
This phase is often the longest and most underestimated. Budget at least four to six weeks for a mid-market ERP migration with a moderate data quality baseline.
Cleansing means correcting the data in the staging area so it meets the new system’s requirements. Common cleansing tasks include:
Each cleansing action should be logged, not done ad hoc. A change log allows the team to audit what was modified and why, and to replay changes if the staging data is refreshed from the source.
The field mapping document is the technical blueprint for migration. For each legacy field, it specifies the target field in the new ERP, the transformation logic (if any), and the validation rule. This document should be reviewed and signed off by both the data owner and the implementation partner before any test migration runs.
For NetSuite migrations, pay particular attention to custom fields, subsidiaries, and currency settings. For Zoho migrations, review module-level field types carefully, since Zoho CRM and Zoho Books have different field validation rules than many legacy systems. Teams doing a migrating data to Zoho project often find that picklist values and lookup fields require the most mapping iteration.
No ERP migration should reach cutover without at least two complete end-to-end trial runs. The purpose of trial migrations is to find and fix mapping errors, volume issues, and missing validation logic before the real go-live.
The first trial is primarily for the implementation team. Load the cleansed staging data into the ERP test environment and check:
Document every error and assign it to an owner for resolution. Update the mapping document and cleansing scripts, then schedule trial run 2.
The second trial brings in business users, the data owners you identified in Phase 1. Their job is to validate that the data makes sense from an operational standpoint, not just that it loaded without errors. Typical UAT checks include:
A formal UAT sign-off from each data owner is a prerequisite for proceeding to cutover. Do not skip this step under schedule pressure. If business users cannot validate data in testing, they will raise the same issues on day one of go-live when the stakes are far higher.
If the migration involves more than 100,000 records in any single entity, run a performance test during trial 2 to estimate actual cutover duration. Many ERP platforms, including NetSuite, have API rate limits and batch size restrictions that affect how long a full migration takes. Knowing the runtime allows the team to plan the cutover window accurately.
Cutover is the period when the legacy system is frozen, final data is extracted and loaded, and the new ERP becomes the system of record. A well-documented ERP data migration checklist for cutover covers every task, owner, and time check in sequence.
Agree on a cutover freeze date and communicate it to all users well in advance. From the freeze date, no new transactions should be entered in the legacy system. Any transactions that must be processed during the cutover window go into a parallel queue and are entered into the new system after go-live. Define the freeze scope clearly: does it cover all modules, or only the modules being migrated?
At the start of the cutover window, extract the final production dataset from the legacy system. This extract should be as close to identical to the trial run as possible, except for any transactions that occurred after the trial run date. Load it into the new ERP using the same scripts and mapping logic that were validated in trial run 2.
For complex migrations, for instance a SAP to NetSuite migration with multiple subsidiaries and currencies, the cutover load may take 12–36 hours. Build that time into the cutover plan.
| Task | Owner | Timing |
|---|---|---|
| Freeze legacy system and communicate to users | IT / Project lead | D-2 |
| Run final reconciliation of open transactions in legacy | Finance | D-1 |
| Execute final data extract from legacy | Implementation team | D-Day |
| Load master data to new ERP | Implementation team | D-Day |
| Load open transactions to new ERP | Implementation team | D-Day |
| Validate record counts against sign-off baseline | Data owners | D-Day |
| Validate opening financial balances | Finance | D-Day |
| Enable user access and communicate go-live | IT / Project lead | Go-live |
| Process queued transactions from cutover window | Operations / Finance | Day 1 |
The 30 days after go-live are the highest-risk period of any ERP implementation. Data issues that were not caught in testing surface when users start processing real transactions. A structured hypercare plan reduces the business impact of these issues.
For the first week after go-live, finance should run a daily reconciliation of key balances: accounts receivable, accounts payable, and inventory value. Any discrepancy between the new system and the legacy system’s final state is flagged and investigated the same day. Letting discrepancies accumulate beyond 48 hours makes them progressively harder to trace.
Beyond balance reconciliation, spot-check live transactions as they are processed. Ask users to report any case where data looks wrong on a sales order, invoice, or purchase order. In many migrations, the errors that surface in week one are not in the migrated data itself but in workflows that depend on the migrated data (automated pricing rules, approval hierarchies, tax configurations).
Set a clear date for legacy system decommission, typically 60–90 days after go-live. During this period, the legacy system is available in read-only mode for reference, but no new transactions are entered. At decommission, archive the legacy data to a long-term storage location per your retention policy. Do not delete it — legacy data is often needed for audits or disputes for years after migration.
At the 30-day mark, hold a structured review with data owners, the implementation team, and executive sponsors. The agenda covers: what data quality issues were found, what their business impact was, what was fixed and when, and what process changes are needed to prevent similar issues in future system changes. Document the review and store it with the migration project record.
For teams using the Zoho implementation checklist, the post-migration review covers both data and configuration items across all modules.
The checklist phases above apply to any ERP migration. However, each platform has specific tools and constraints that affect how you execute each phase.
NetSuite provides CSV Import and SuiteScript for data loading. CSV Import covers most standard records (customers, vendors, items, transactions) with configurable field mappings. SuiteScript is required for complex transformations or high-volume loads with custom logic. NetSuite also has a Data Migration Accelerator offering through Oracle, which includes pre-built templates for common migration scenarios. API rate limits apply to SuiteTalk REST calls, so large transaction datasets require batching and retry logic.
Zoho’s suite offers module-specific import tools in Zoho CRM, Zoho Books, and Zoho Inventory. Each module has its own field validation rules and import limits. Zoho CRM allows up to 10,000 records per import batch. Zoho Books requires that accounts, contacts, and opening balances be loaded in a specific sequence. Cross-module data relationships (for example, a contact that exists in both CRM and Books) must be handled carefully to avoid creating orphaned records in either system.
| Tool type | Best for | Example tools |
|---|---|---|
| Native import | Standard records, lower volumes | NetSuite CSV Import, Zoho Import Wizard |
| ETL platforms | Complex transformations, multiple sources | Talend, Informatica, Stitch |
| iPaaS connectors | Ongoing sync between legacy and new system | Boomi, MuleSoft, Zoho Flow |
| Custom scripts | High-volume, non-standard objects | SuiteScript, Python + Zoho API |
For a complete walkthrough of the full process, see our NetSuite ERP implementation guide.
What is an ERP data migration checklist?
An ERP data migration checklist is a structured list of tasks covering every phase of moving data from a legacy system to a new ERP platform. It includes data scoping, extraction, cleansing, field mapping, trial migration runs, cutover execution, and post-go-live validation. A complete checklist assigns each task an owner and a timeline, reducing the risk of critical steps being skipped under project schedule pressure.
How long does ERP data migration typically take?
For a mid-market ERP implementation, the data migration workstream typically runs 8–16 weeks from initial data extraction to go-live sign-off. Simple migrations with clean source data can complete in 6–8 weeks. Complex migrations involving multiple source systems, large transaction volumes, or poor data quality can take 20 weeks or more. The cleansing and mapping phase is usually the longest, taking 4–8 weeks depending on data quality.
How many trial migration runs should you do before cutover?
A minimum of two full trial migration runs is recommended before cutover. The first run validates the technical mapping and identifies import errors. The second run, conducted as a User Acceptance Test with business stakeholders, confirms that the migrated data is operationally correct. For complex migrations with multiple subsidiaries or large datasets, a third dress rehearsal that mirrors the exact cutover steps is strongly advisable.
What data should you not migrate to a new ERP?
Avoid migrating closed transactions older than your chosen historical cutoff (typically 2–3 years), inactive or duplicate master records that are no longer operationally relevant, and system-generated log or audit records that do not carry business meaning in the new platform. Migrating unnecessary data increases migration complexity, extends load times, and makes the new system harder to use. Archive old data separately and retain it for compliance purposes.
What is the difference between ERP data migration and ERP data integration?
ERP data migration is a one-time, point-in-time movement of data from a legacy system to a new ERP as part of an implementation project. ERP data integration is an ongoing, automated process that keeps data in sync between two or more systems after both are live. Migration happens once. Integration is continuous. Some implementations involve both: a migration at go-live, followed by ongoing integration with external systems such as e-commerce platforms, CRMs, or banking feeds.
Aaxonix manages ERP data migrations for Zoho and NetSuite implementations, handling data scoping, cleansing, field mapping, and cutover execution so your go-live stays on schedule. Book a free consultation and get a data readiness assessment for your migration project within 48 hours.
Book a free consultationA well-executed ERP data migration does not happen by accident. It happens because someone built a checklist early, assigned ownership to every data domain, and ran enough trial migrations to prove the process before committing to cutover. The phases above give you that structure. The specific timelines and tool choices will vary by platform and project scale, but the sequencing holds: plan, extract, cleanse, map, test, cut over, validate.
On this page NetSuite implementation services OpenAir PSA NetSuite for professional services firms use…
SuiteScript 2.x guide: script types, code examples, governance limits, and common Indian business customisations for…
On this page Implementing a CRM is one of the most impactful decisions a growing…
Our team builds systems that actually work. No fluff, just honest architecture and clean implementation.
