Data migration is the part of ERP implementation that gets underestimated most consistently. Teams spend months designing and building the system, then treat data migration as a final-week task. This is how you end up going live with duplicate customer records, wrong stock counts, and opening balances that don't match your previous system.
The right approach: start thinking about data migration in week two of the project, not week twenty.
What Data Actually Needs to Move
Not everything in your old system or spreadsheets needs to go into the new one. Being selective is both practical and beneficial — you don't want to carry old problems into a new system.
Master data is the foundation and must be migrated completely:
- Customers (company name, contact details, payment terms, credit limits, tax IDs)
- Suppliers (same structure)
- Products/items (SKU codes, descriptions, units of measure, pricing, categories)
- Chart of accounts (your financial account structure)
- Employees (for HR modules — ID, department, position, salary structure)
Opening balances establish the financial starting point for your new system:
- Accounts receivable — which customers owe you money, how much, and since when
- Accounts payable — what you owe suppliers, how much, and when it's due
- Stock quantities on hand at each location as of the go-live date
- Bank balances as of go-live
- General ledger balances for all accounts
Historical transactions are optional but often valuable for reporting continuity. If you want to run year-over-year sales comparisons or see a customer's purchase history in the new system, you need historical transaction data. A reasonable cutoff is 1-3 years, depending on your business and reporting needs. Going back further rarely justifies the migration effort.
The Three Most Common Data Migration Problems
Problem 1: Migrating dirty data.
Most businesses have spent years accumulating inconsistencies in their records. Duplicate customer entries — "PT Maju Bersama," "PT. Maju Bersama," and "Maju Bersama" are three records that represent one company. Product codes that were created ad-hoc and don't follow any logic. Supplier records where the contact information is years out of date. Zero-balance AR records for customers who paid years ago but were never closed.
If you migrate this data as-is, the new ERP inherits all of it. Your clean new system starts life with the same mess.
The fix is to clean before you migrate. Deduplicate customers and suppliers. Standardize product codes. Archive records that are clearly inactive. This is time-consuming and unglamorous work, but it's the most valuable thing you can do before go-live.
Problem 2: Rushing the cutover.
The go-live cutover — loading actual live data into the production system — typically happens over a weekend or at month-end. The temptation is to cut corners under time pressure. The result is migration errors that only surface during the first week of live operation, when everyone is already stressed and the team is at capacity.
Run a full "dry run" migration at least two weeks before go-live. Load actual data into the test environment, reconcile it, and have business users verify it. If there are problems, you have time to fix them. The dry run is not optional.
Problem 3: Not validating with business users.
Migration is typically done by the technical team. Technical validation — confirming that the data loaded without errors — is necessary but not sufficient. Business validation means someone from the finance team checks that the AR opening balances match what they see in the old system. Someone from the warehouse walks the physical stock count and checks it against the system quantities. Someone from purchasing verifies that their top 20 suppliers loaded correctly.
This validation can't be delegated to IT. The people who use the data every day are the only ones who will catch the specific errors that matter operationally.
A Practical Migration Approach
Step 1: Inventory your data sources. Before you can plan a migration, you need to know where your data currently lives. It might be spread across an accounting package, a separate inventory system, multiple Excel files, and possibly paper records for some historical information. Map this out completely.
Step 2: Define what you're migrating and what cutoff date you're using. The go-live date is the opening balance date. Everything before that date is historical. Decide how far back historical transaction data needs to go, and stick to that decision.
Step 3: Clean the data. Deduplicate, standardize, and archive. This step takes longer than anyone expects. Budget at least two to four weeks for a business with more than 500 customer or supplier records and a substantial product catalog.
Step 4: Build and test the migration scripts. The technical team builds scripts to extract data from the old system and load it into the new one. These scripts are tested repeatedly on the test environment before touching production.
Step 5: Dry run. Full migration to the test environment. Business users validate. Issues are documented and resolved. If you're mapping this against what the full ERP implementation timeline looks like, migration prep typically runs in parallel with development — not as a separate phase at the end.
Step 6: Freeze old system and perform final migration. At the agreed cutover point, stop transacting in the old system. Run the final migration with the most current data. Validate again — this goes faster because you've already done it once.
Step 7: Go-live. With clean, validated data, and confidence that the numbers are right.
The Opening Balance Problem
The most common numerical error in ERP go-lives involves opening balances not matching. The AR balance in the new system doesn't agree with the closing AR balance in the old system. The bank balance is off by a transaction that got counted twice.
These discrepancies are almost always caused by data being extracted at one point in time and loaded at another, with transactions happening in between. The solution is to freeze the old system (or at least the relevant modules) during the migration window, so the data set is static.
If a parallel run is required — old system and new system running simultaneously for a period — reconciling between them becomes an ongoing task. Plan the staffing for this explicitly; it's often underestimated.
One Thing Worth Saying Directly
Data migration is a good time to question whether the data structures in your old system are worth replicating. If your product categorization is a mess, don't migrate a mess — fix it first. If your customer segmentation doesn't reflect how you actually think about your customers, create a better structure in the new system.
Migration is one of the few opportunities to make significant structural changes to your master data. The effort is roughly the same whether you migrate the old structure or build a better one. Take the time to do it right.
CERIS includes data migration planning as a core part of every ERP implementation — not a last-week task. See what we build or talk to us if you want to understand what data migration looks like for your specific situation.
