Buying guide - Migration
ERP data migration: balances, stock and a cutover you can defend.
An ERP migration is not a data transfer, it is a financial and operational event. Valuation, tax position, customer balances and stock accuracy all reset at the moment of cutover. This guide covers the preparation, the reconciliation criteria and the cutover sequencing that let finance and operations sign off with confidence.
At a glance
- Who this is for
- Finance and operations leaders planning an ERP cutover.
- Key insight
- Reconciliation criteria are agreed before the load, not judged after it.
- Related
- The CRM migration guide covers customer records and pipeline.
Method
Eight steps to a defensible ERP migration.
Rehearsal is not optional. It is what turns a cutover plan into a measured schedule.
- 01
Profile and assess
Product data completeness, stock accuracy by location, BOM coverage, supplier and customer records, and the state of open transactions. This assessment shapes the whole plan.
- 02
Prepare master data
Products, units of measure, partners, tax codes, price lists and BOMs. Master data must be correct before any transactional data can be meaningfully loaded.
- 03
Define the balance strategy
Agree with your accountant what comes across as opening balances, at what date, and what remains in the old system for historical reporting.
- 04
Map and transform
Documented mapping per object, with transformation rules, chart of accounts alignment and a decision on every field with no target.
- 05
Rehearse the load
Trial loads into a test environment, repeated until they run cleanly. Each rehearsal times the steps, which is what makes the cutover plan credible.
- 06
Reconcile
Trial balance, debtors and creditors ageing, stock quantity and value by location, and open order counts - all agreed against the source before sign-off.
- 07
Execute cutover
Transaction freeze, physical stock count, final balance extract, load, verify, release. Sequenced and dry-run in advance, with a stated rollback point.
- 08
Verify after go-live
Re-reconcile after the first week, watch valuation movements closely, and treat the first month-end close as the true acceptance test.
Scope
Object by object.
| Object | Approach |
|---|---|
| Chart of accounts | Migrate as a mapped structure, not a copy. An ERP move is the natural point to rationalise accounts, and doing it later is far more disruptive. |
| Products and variants | Codes, descriptions, units of measure, tax settings, costing method and reorder rules. Errors here propagate into every transaction that follows. |
| Bills of materials and routings | Must be verified by production, not assumed from the old system. Informal or outdated BOMs are the most common manufacturing migration problem. |
| Customers and suppliers | Including payment terms, tax treatment, delivery addresses and price agreements - the fields that quietly break invoicing if wrong. |
| Opening stock | Quantity and value by location, from a counted and reconciled position rather than a system extract nobody has verified. |
| Open sales and purchase orders | Migrated as open documents so fulfilment and receipting continue uninterrupted through cutover. |
| Debtors and creditors | Open items with correct ageing and remittance references, so collections and payments continue without manual reconstruction. |
| Historical transactions | Rarely worth loading in full. Keep the old system available as a read-only archive for the retention period instead. |
Risk
Five migration risks with expensive tails.
- 01
Loading stock without a count
A migration inherits the accuracy of its source. If the count was not physical and reconciled, the new ERP starts wrong and every valuation report after it is suspect.
- 02
Unverified bills of materials
Production knows what is really used; the system often does not. Costing, planning and purchasing all inherit the error, and it surfaces as margin drift.
- 03
Chart of accounts copied rather than designed
Carrying forty years of accumulated accounts into a new system preserves the reporting problems you were trying to solve.
- 04
Costing method decided late
Standard, average or FIFO changes valuation, reporting and reconciliation. Deciding after configuration forces rework across the board.
- 05
One rehearsal treated as enough
The purpose of rehearsal is both correctness and timing. Without repeated runs, the cutover schedule is an estimate rather than a measured plan.
Rather work through your own numbers?
A consultation covers the same ground against your systems, volumes and timeline instead of a general range.
Strategy
Balances forward or full history.
Recommended default
Balances forward
- Opening balances at a clean period boundary
- Open AR and AP items with ageing
- Counted, reconciled stock quantity and value
- Old system retained as read-only archive
- Shorter, lower-risk cutover
Occasionally justified
Full transaction history
- Multiple prior years loaded into the new ERP
- Continuous reporting within one system
- Substantially larger reconciliation effort
- Legacy errors carried into the new ledger
- Only where regulation or reporting genuinely requires it
ERP migration questions buyers ask
- How much history should we migrate into a new ERP?
- For most businesses, opening balances plus open transactions is the right scope, with the legacy system retained as a read-only archive for the retention period. Full history migration multiplies reconciliation effort and imports legacy errors into a fresh ledger.
- Do we need a full stocktake before cutover?
- A counted and reconciled stock position is the safest starting point, and in practice it is what makes post-go-live valuation defensible. Where a full count is impractical, a targeted count of high-value and high-movement items with cycle counting after go-live is a reasonable compromise - as a deliberate decision, not an omission.
- Who signs off that the migration is correct?
- Finance signs the balances, operations signs the stock, and production signs the BOMs. Migration acceptance is a business decision against agreed reconciliation criteria, not a technical statement that the load completed.
- What happens to data we do not migrate?
- It stays accessible. Usually that means keeping the legacy system read-only for the retention period, or extracting archives to a searchable store. Either way the decision should be documented against your record-keeping obligations.
- How many rehearsal loads are typical?
- As many as it takes for the load to run cleanly and reconcile without intervention, with each step timed. The number is an output of your data quality rather than something to fix in advance.
Where to go next
Related buying guides
Related architecture and services
Recommended for your industry
Start with a data readiness assessment.
Stock accuracy, BOM coverage and product data completeness tell you more about your ERP risk than any vendor demonstration will.