ERP Data Migration: Balances, Orders, History

ERP data migration is harder than most system migrations because an ERP's data must balance. Customer and supplier records can be cleaned and loaded much like CRM data, but stock quantities, open orders, unpaid invoices and account balances must match the old system to the unit and the cent on the day of cutover, or the new ERP starts life with numbers nobody trusts. This guide explains how to approach ERP data migration: the types of data involved, how to decide what history to bring across, how to handle master data, open transactions and balances, how to time cutover around a period end and how to prove the numbers match, with a worked migration plan.

The types of ERP data

TypeExamplesTypical approachConfigurationChart of accounts, tax codes, payment terms, units of measure, warehousesDesigned and set up in the new ERP, often reworked rather than copiedCore master dataCustomers, suppliers, items, bills of materials, price lists, employeesCleaned, mapped and loaded before cutover, with updates frozen near the endOpen transactionsOpen sales and purchase orders, unpaid invoices and bills, work in progressLoaded at cutover so work continues seamlesslyBalancesStock on hand and value, general ledger balances, customer and supplier balancesLoaded as opening balances at a period end and reconciledHistoryClosed orders, past invoices, past ledger transactionsOften summarised or archived rather than fully migrated

Each type needs its own method, owner and checks. Treating them all as "data to import" is how ERP migrations go wrong.

Deciding what history to migrate

Migrating years of closed transactions is expensive, slow and rarely necessary. Common approaches:

• Migrate open items and balances only, and keep the old system or an archive available read-only for history
• Migrate summarised history, such as monthly ledger balances for comparative reporting, without every transaction
• Migrate a limited period of detailed history, such as the current and previous financial year, where users need it day to day

Consider legal and audit requirements for record retention, and how often users genuinely look up old transactions. An accessible archive often satisfies both at a fraction of the cost.

Core master data: clean before you load

The quality of master data determines how well the new ERP works. Duplicate customers split credit limits and history; duplicate items confuse stock; inaccurate bills of materials produce wrong costs. Use the migration to:

• Merge duplicate customers, suppliers and items, and retire inactive ones
• Standardise names, addresses, units of measure and item descriptions
• Validate bank details and tax registrations
• Review bills of materials and routings with production staff

Load master data early in trials, freeze changes in the old system close to cutover, and capture any late changes in a controlled list to apply after the final load.

Open transactions and balances

Open transactions must be migrated so each one can continue naturally: an open purchase order should be receivable in the new ERP, an unpaid invoice payable or collectable. Load them with references back to their original numbers, so staff and customers can match them.

Balances are loaded as opening entries at a cut-off point, usually the end of an accounting period. Stock quantities come from a physical count or a trusted stock report at cut-off, valued according to your costing method. General ledger balances are loaded from the trial balance, and customer and supplier balances must equal the sum of open invoices and bills.

Timing cutover around a period end

Most ERP cutovers happen at the end of a month, quarter or financial year, so that the old system closes one period and the new one opens the next. This keeps reporting clean, but it puts cutover on top of month-end closing work. Plan for it: close the period in the old system quickly, take the final balances, load them and verify before trading resumes. Many businesses also schedule a stock count at cut-off, which needs warehouse time and planning.

Proving the numbers match

Reconciliation is the heart of ERP data migration. Agree in advance which checks finance and operations will sign off:

• Trial balance in the new ERP equals the old system's closing trial balance
• Accounts receivable and payable totals match, and agree to their control accounts
• Stock quantity and value match by item and location
• Open order counts and values match
• Sample of master data records verified field by field

Run the same checks in every trial migration, so the final cutover holds no surprises.

Worked example: ERP data migration plan for a manufacturer

Suppose a manufacturer with two sites is moving from an ageing ERP to a new custom-built one, with cutover at the end of its financial year. Its plan:

DataApproachSign-off checkChart of accounts, tax codesRedesigned; mapping from old accounts maintainedFinance approves mappingCustomers and suppliersDuplicates merged, inactive records retired, bank details verifiedSample of 100 each checkedItems and bills of materialsReviewed with production; obsolete items retiredCosted BOMs compared for top 50 productsOpen sales and purchase ordersLoaded at cutover with original order numbersCounts and values matchUnpaid invoices and billsLoaded with original numbers and due datesTotals equal receivables and payablesStockPhysical count at year end; quantities and values loaded by locationQuantity and value match count sheetsGeneral ledgerClosing trial balance loaded as opening balancesTrial balances matchHistoryTwo years of monthly ledger balances migrated; detailed history kept in a read-only archiveComparative reports agree with old system

Three trial migrations are run, each with the full reconciliation. Year-end closing in the old system and the stock count are scheduled for the final weekend, with the new ERP opening on the first working day of the new year. The details are this manufacturer's choices, shown to illustrate the method.

Common mistakes

• Migrating all history by default
• Loading master data without cleaning it
• No agreed reconciliation checks or sign-off
• Cutover without a stock count or trusted stock figures
• Underestimating the clash with period-end closing
• Changing master data in the old system after the final extract without capturing it

For the overall rollout plan, see our guide to custom ERP implementation. Many of the same disciplines apply to CRM data; our CRM data migration checklist sets them out phase by phase.

Frequently Asked Questions

What data is migrated to a new ERP?

Configuration is usually redesigned; master data, open transactions and balances are migrated; detailed history is often summarised or archived.

Should we migrate all historical transactions to the new ERP?

Usually not. Open items, balances and limited or summarised history, with an accessible archive for the rest, meet most needs at much lower cost.

When should ERP cutover happen?

Usually at the end of an accounting period, such as a month or financial year, so balances can be closed in the old system and opened cleanly in the new one.

How do we check an ERP data migration is correct?

Reconcile trial balances, receivables, payables, stock quantities and values and open orders, and verify samples of master data, in every trial and at cutover.

Migrate your ERP data with confidence

We plan ERP data migrations with cleaning, trial runs and reconciliation built in, for custom and packaged systems. See our custom app development services, or talk to us about your ERP.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.