ERP data migration is the controlled move of the records your business runs on (master data, opening balances and open transactions) from spreadsheets and old systems into a new ERP. It counts as finished only when reconciliation shows the new system agrees with the old one. A workable plan has eight stages: agree the scope and cut-over date, profile the data, cleanse it, write mapping rules, name a data owner for each area, run at least two trial loads, reconcile every load, then cut over at the start of an accounting period and support users through the first close.
Migration is one of the least visible parts of an ERP project and one of the riskiest. This guide is vendor-agnostic. It applies whether you are moving to a packaged suite or to custom ERP software, and whether the source is a set of spreadsheets, an old accounting package or a legacy system that has run for twenty years.
What should you migrate into a new ERP?
Migrate what the business needs to keep operating from day one, and nothing more. In practice that means three groups of records, plus a decision about history.
| Data type | Examples | Migrate? | How |
|---|---|---|---|
| Master data | Customers, suppliers, items, chart of accounts, price lists, bills of materials, employees, warehouses | Yes, active records only | Cleansed and mapped to the new structure |
| Opening balances | Trial balance by account at the cut-over date | Yes | One balanced opening entry per entity, at a period start |
| Open transactions | Unpaid customer invoices, unpaid supplier bills, open sales and purchase orders, unsettled advances, stock on hand by location, batch or serial number | Yes, document by document | So each item can be settled, received or invoiced normally in the new system |
| Closed history | Paid invoices, completed orders, old journals | Usually not in detail | Summary balances per period for comparatives; detail kept in an archive |
| Configuration | Tax codes, payment terms, units of measure, approval rules | Rebuilt, not copied | Designed in the new system, then tested |
What usually should not be migrated
- Dormant master records. Customers, suppliers and items with no activity for a period the business agrees. Each one adds cleansing effort and clutters every search afterwards.
- Duplicates and test records. The same supplier entered three ways, or "TEST CUSTOMER 2".
- Closed transactions at line level. Rebuilding years of paid invoices in a new system is expensive, and recreating them can disturb balances and numbering. Keep them readable elsewhere.
- Unused general ledger accounts. A new ERP is the moment to rationalise the chart of accounts, not to copy every code someone once created.
Where history lives instead
History does not disappear when it is not migrated. The usual options are keeping the old system available in read-only mode, exporting history to an archive database or reporting store, or both. How long records must be kept is a legal and tax question, so confirm the retention period with your accountants before you switch anything off.
Step 1: Agree the scope and the cut-over date
Write down which entities, branches, modules and record types are in scope, and which are not. Then choose the opening balance date. Set it at the start of an accounting period, ideally a month or financial year start. Opening balances then equal the closing balances of the last period in the old system, and period reporting in the new system starts clean.
A mid-month cut-over splits one period across two systems, and someone has to stitch the reports together by hand.
Step 2: Profile the data before you clean it
Profiling means measuring the data before deciding what to do with it. Run simple checks on every source file or table:
- Duplicate records, including near-duplicates with different spelling or spacing
- Missing mandatory fields, such as tax numbers, payment terms or units of measure
- Inconsistent formats in dates, phone numbers, currencies and decimal separators
- Codes that no longer exist, such as an item linked to a deleted category
- Orphan records, such as invoices for a customer that is not in the customer list
- Negative stock quantities and items with no cost
- Sub-ledgers that do not agree with their control accounts
The output is a short issue log with counts per problem: a list of decisions rather than a vague worry.
Step 3: Cleanse at the source, by rule
Fix data in the source system, or in a controlled staging area, using written rules rather than one-off edits. Typical rules: merge duplicate customers into the record with the most history; mark items with no movement in an agreed period as inactive. Rules can be re-run on every trial load. Manual edits are lost on the next extract.
Step 4: Write mapping and transformation rules
A mapping document lists every target field in the new ERP, where its value comes from, and how it is transformed. It is the contract between the business and whoever builds the migration scripts.
| Source | Target | Rule | Owner |
|---|---|---|---|
| Old account code 4010 Sales Local | New account 40100 Revenue, Domestic | Many-to-one map table agreed by finance | Finance controller |
| Item unit "Box" | Base unit "Each", conversion factor 12 | Quantity times factor; unit cost divided by factor | Inventory lead |
| Customer "Name" free text | Legal name plus trading name | Split by rule; exceptions reviewed manually | Credit control |
| Supplier tax status Y or N | Tax code per jurisdiction | Lookup table | Tax or finance lead |
Write the rules down even when the source is a single spreadsheet. Undocumented transformations are the main reason one trial load cannot be reproduced on the next.
Step 5: Name a data owner for every area
Data owners are people in the business who decide what is correct and sign off each load. The implementation team, internal or external, moves the data. It should not be the one deciding whether a customer balance is right.
| Data | Typical owner | Signs off |
|---|---|---|
| Chart of accounts and opening balances | Finance controller | Trial balance tie-out |
| Customers and receivables | Credit control or finance | Customer list and AR ageing |
| Suppliers and payables | Procurement or accounts payable | Supplier list and AP ageing |
| Items, stock and costs | Inventory or operations lead | Stock quantity and valuation |
| Employees and payroll data | HR or payroll lead | Employee master and year-to-date figures |
For a group with several companies, assign owners per entity as well as per module. The controller of one subsidiary cannot vouch for another subsidiary's balances. Our guide to multi-entity ERP governance covers how ownership and controls work across entities.
Step 6: Run at least two trial migrations
A trial migration, or mock load, is a full rehearsal into a test copy of the new ERP. Plan at least two.
- Mock load 1 tests the mapping. Expect failures: rejected records, wrong units, accounts that do not map. Fix the rules, not the loaded data.
- Mock load 2 runs at full volume with the same scripts and sequence planned for cut-over, timed end to end. Its timing tells you how long the real freeze window must be.
- A dress rehearsal is worth adding for larger or multi-entity migrations: the full cut-over run book, including sign-offs, done exactly as it will be on the day.
After each mock load, have users run real scenarios on the migrated data. Receive a payment against a migrated invoice. Receive goods against a migrated purchase order. Ship stock from a migrated batch. Most migration problems surface when people use the data, not when they look at it.
Step 7: Reconcile every load
Reconciliation is the proof that the migration worked. Do it on every mock load and on the final load, and have the data owner sign each tie-out.
Trial balance tie-out
The trial balance in the new ERP at the opening balance date should agree, account by account after mapping, with the closing trial balance in the old system. Many teams post opening balances through a dedicated migration clearing account. That account must net to zero once all balances, sub-ledgers and stock are loaded. A balance left on it means something is missing or loaded twice.
Stock quantity and valuation tie-out
Check quantities by item and location, including batches and serial numbers where you track them, against the old system or a physical count. Then check valuation: total stock value in the new system should equal the inventory balance on the trial balance. If the costing method changes, for example to moving average, agree with your accountants how the opening cost per item is set before the first mock load.
AR and AP ageing tie-out
The total of migrated open customer invoices should equal the receivables control account, and the ageing buckets should match the old ageing report. The same applies to supplier bills and the payables control account. Load open items at document level with their original dates, due dates and currencies, or ageing and dunning will be wrong from day one.
Record counts and control totals
For every entity loaded, compare record counts and a simple control total (for example, the sum of credit limits or of quantities) between source and target. These checks catch silent rejections that a summary balance can hide.
Step 8: Plan the cut-over
The cut-over is the short period when the old system stops, final data moves, and the new system opens. Write it as a run book with named owners and a time for each step.
- Announce the freeze window to staff, customers and suppliers who will notice.
- Enter the last transactions in the old system and stop new entries.
- Count stock, or confirm the count, and post the final adjustments.
- Close the period in the old system and extract the final data.
- Run the load scripts in the rehearsed order.
- Reconcile: trial balance, stock, AR and AP ageing, record counts.
- Data owners sign off. The project lead makes the go or no-go call.
- Open the new system for transactions.
Audited or final balances are often not available on cut-over day. That is normal. Load the best available balances, then post the audit or year-end adjustments in the new system later as normal journals, with a clear audit trail.
Parallel run or direct cut-over?
A parallel run means entering the same transactions in both systems for a period and comparing results. A direct cut-over switches in one step, backed by a rollback plan.
| Parallel run | Direct cut-over | |
|---|---|---|
| Confidence | Results can be compared side by side | Relies on mock loads and reconciliation |
| Workload | Double entry for every user throughout the period | Single entry from day one |
| Common problem | Small timing differences make the systems hard to compare; staff fall behind | A missed issue appears in live use |
| Best fit | Small, high-risk areas such as payroll calculations | Most ERP go-lives, with good rehearsal |
A phased approach sits between the two. Go live with one entity, one branch or one group of modules, stabilise, then move the next. Phasing reduces the size of each cut-over but means old and new systems run side by side for longer. If they must exchange data in the meantime, plan that link deliberately; our ERP integration services page covers connecting systems that stay live.
Your rollback plan
Decide before cut-over day what would make you go back, who decides, and by when. A rollback plan should state:
- Go or no-go criteria, such as the trial balance agreeing, stock valuation agreeing, and key users able to complete their critical transactions
- The decision point, the latest time at which rolling back is still practical
- How the old system is kept ready: unchanged, backed up, and able to reopen
- What happens to transactions entered in the new system before a rollback, and who re-enters them in the old one
Most teams never use their rollback plan. Having one keeps the go or no-go decision honest.
Hypercare: the first weeks after go-live
Hypercare is a period of heightened support straight after go-live. Typical arrangements are a daily check-in with key users, one issue log with priorities, and quick fixes for data errors that slipped through. Extend hypercare at least until the first month-end close in the new system is complete. The first close is where migration gaps in accruals, stock valuation and open items finally show up.
ERP data migration checklist
Print this and tick it off with your data owners.
Before the first trial load
- Scope agreed: entities, modules, record types, and what stays behind
- Opening balance date set at the start of an accounting period
- History approach and retention period confirmed with your accountants
- Data profiled; issue log with counts per problem
- Cleansing rules written and approved
- Mapping document complete for every target field
- Data owner named and agreed for each entity and module
During trial loads
- Mock load 1 run; rule fixes logged
- Mock load 2 run at full volume; load time measured
- User scenarios tested on migrated data
- Trial balance, stock, AR and AP ageing reconciled and signed
- Migration clearing account nets to zero
- Cut-over run book written and rehearsed
Cut-over
- Freeze window announced
- Last transactions entered; old period closed
- Stock count confirmed
- Final load run in the rehearsed order
- All tie-outs signed by data owners
- Go or no-go decision recorded
- Rollback plan ready until the decision point passes
After go-live
- Hypercare issue log active
- Old system read-only, with access for audit and enquiries
- Audit or year-end adjustments posted with an audit trail
- First month-end close completed and reviewed
Why ERP data migrations go wrong
The causes repeat across projects, whatever the software:
- Starting late. Migration planned after the system is built leaves no time for two trial loads.
- No data owners. When nobody in the business signs off, errors are found by customers and auditors instead.
- Cleansing by hand. Fixes made directly in a load file are lost on the next extract.
- Migrating everything. Moving full history multiplies effort and drags old problems into the new system.
- Skipping reconciliation. "It loaded without errors" is not the same as "it is right".
- A mid-period cut-over. It splits reporting across two systems.
- Unrehearsed cut-over. The first full run should never be the real one.
If your old system is hard to extract from, because it is undocumented, runs on an old database or keeps its logic in stored procedures, plan for that work explicitly. Our legacy software modernization page explains how we approach extracting data and logic from older systems.
How Timeline Digital approaches migration
We plan migration from the start of an ERP engagement rather than at the end. In our five-step process, data sources are reviewed during Understand and Plan. Before you commit to a full project, we build 2 to 3 of your key modules as a free pilot, so your team can judge working software before the full migration is planned in detail. For the wider implementation, see our ERP implementation services. If you are still choosing between a packaged ERP and a custom build, our custom ERP software page explains how we build module by module.