ERP Data Migration: Master Data, Open Transactions, and Historical Balances

ERP migrations are unforgiving. A CRM can limp with imperfect history for a week. An ERP with wrong open orders, stock positions, or item masters stops the business on Monday morning.

That is why ERP data migration best practices are less about clever tooling and more about disciplined scope, sequencing, and proof. Master data, open transactions, and historical balances are different risk classes. Treat them as one undifferentiated “data cut” and you will discover the differences in live operations.

This guide is for mid-market programmes, whether you are moving between ERP suites, consolidating instances, or replatforming to a modern cloud ERP with finance close to the core. It aligns to our data migration methodology and full-population reconciliation standard: in-scope data migrated and reconciled back to the original dataset.

The three risk classes (do not mix them casually)

Best practice starts with naming which class each entity belongs to, then designing load order, freeze rules, and acceptance separately.

Principles that hold across ERP brands

1. Operations before elegance, day-one ship, receive, invoice, and make/buy paths beat perfect ten-year history.
2. Reference data is not admin trivia, units of measure, statuses, location codes, and tax categories break transactions silently.
3. Open means open, define status models precisely; “open-ish” is how reconcile packs lie.
4. Inventory is a position, not a table, quantity, location, status, ownership, and value must cohere.
5. History is a product decision, migrate what you will use and can prove; archive the rest deliberately.
6. Proof beats demos, a successful workshop order entry test is not population reconciliation.
7. Source stability matters, baseline feeds and batch jobs with observability before migration.

Part A, Master data: build the nouns the ERP can trust

What usually sits in master scope

• Items / materials / SKUs (including variants and kits if used)
• Customers and ship-to / bill-to structures
• Suppliers and purchasing sites
• Locations, warehouses, bins (as far as the target model supports)
• Product structures: BOM, recipes, configurations
• Work centres / resources if manufacturing is in scope
• Price lists, discount constructs, customer-item specifics
• Chart of accounts crosswalk if ERP posts finance (coordinate with finance migration)

Best practices

Rank attributes by transactional criticality. An item without a correct UOM or stocking policy is more dangerous than an item missing a marketing description. Build a critical attribute list per master and make those attributes blocking in quality gates.

Normalise reference data before clever transforms. If source has five unit codes that mean each, fix or map them explicitly. Silent many-to-one dumps into a generic code create reporting and picking errors.

Decide duplicate strategy early. ERP duplicates are not only a CRM nuisance. Duplicate items and suppliers create split history, wrong planning signals, and purchasing leakage. Merge rules need business owners, not only data stewards.

Preserve crosswalks. Legacy item numbers and customer numbers often power warehouse labels, customer portals, and EDI. Migrate external keys even when the target assigns new internal IDs.

Sequence masters before opens. Open transactions that reference missing or incomplete masters will fail validation or land corrupted. Master readiness is a gate, not a parallel hope.

Master data reconciliation (minimum)

• Population counts by type/status/facility
• Key match and orphan reports
• Critical attribute completion rates
• Reference decode success rates
• Deep-dives on A-class items, strategic customers, top suppliers

Part B, Open transactions: the day-one kill zone

Open transactions are where ERP migrations earn or lose credibility.

Define “open” with brutal precision

For each document type, write status inclusion rules:

• Sales orders: which statuses still require fulfilment?
• Purchase orders: unpaid, unreceived, partially received?
• Production orders: released, in process, complete pending receipt?
• Inventory: available, QC hold, returns, consignment?
• Customer/supplier open invoices if subledgers live in ERP

If finance owns AP/AR in a separate finance system, draw the boundary explicitly. Split-brain open items are a classic mid-market failure mode.

Open sales and purchase documents

Best practices:

• Migrate only documents that still have operational residual value
• Recalculate remaining quantities from source of truth, do not trust stale “open” flags alone
• Map partial shipments/receipts carefully
• Carry customer promised dates and internal priority fields sales/ops actually run
• Validate tax, ship-from, and route fields required for release

Reconciliation anchors:

• Open document counts by status and site
• Open line residual quantities
• Open order value
• Stratified deep-dives on largest and oldest open documents

Inventory positions

Inventory is a multi-dimensional truth:

• Item
• Quantity
• Location / warehouse / bin
• Status (available, blocked, QC)
• Ownership / project / batch-serial if used
• Valuation basis aligned to finance policy

Best practices:

• Freeze or tightly control warehouse movements in the cutover window
• Align physical cut strategy with system cut (cycle count, full count, or risk-based)
• Never accept “quantity matched in total” without location and status slices
• Batch/serial controlled items need identity-level proof, not only totals
• Coordinate valuation with finance, quantity-correct and value-wrong still fails the business

Reconciliation anchors:

• On-hand quantity by item-location-status
• Inventory value by valuation class / account mapping
• Zero negative availability surprises versus source policy
• Exception lists for unmapped locations or statuses

WIP and manufacturing opens (if in scope)

• Define whether to close and restart jobs or migrate in-process balances
• Prove component issue positions and remaining operations where required
• Align with inventory so components are not double-counted or lost

Manufacturing cutovers fail when inventory and WIP teams reconcile in isolation.

Part C, Historical balances and history depth

History is where programmes overspend for underused data.

Decide history products explicitly

Ask:

• What does customer service need to see for returns and complaints?
• What does finance need for audit traceability?
• What does planning need for demand history?
• What can live in a read-only archive or data warehouse instead of live ERP?

Best practice: migrate operationally necessary history into ERP; park deep archive in a cheaper, searchable store with clear access paths. “All history forever in live ERP” is a cost and complexity decision, not a default.

Historical balances

Depending on design:

• Opening balances by account / subledger at a chosen cut date (often with finance programme)
• Stock valuation opening aligned to finance
• Open item histories required to explain residual balances

Prove control totals at the cut date. If trial balance and stock value are in play, link to finance reconciliation practices (trial balance reconciliation after finance migration).

Transaction history

If full movement history is in scope:

• Bound it (e.g. 24 months live, older archive)
• Prove volume bands and referential links to masters
• Accept that perfect line-level history is expensive, fund it only with a user story

Load order that reduces pain

A practical mid-market sequence:

1. Reference data and organisation structure
2. Masters (items, parties, locations, product structures)
3. Pricing constructs required for open documents
4. Open operational transactions (orders, inventory, WIP)
5. Opening balances / finance handoff
6. Agreed history waves (if any) after core stability
7. Interfaces on

Variation is fine. Skipping master readiness before opens is not.

Freeze, cutover, and dual-run for ERP

Freeze design

ERP freezes are operational events:

• Order entry cut-offs
• Receiving and shipping blackouts or tightly controlled bridges
• Manufacturing release rules
• Finance period considerations

Write who can do what in which system during the window. Informal exceptions become unreconcilable deltas.

Dress rehearsals

Run at least one full-volume open-transaction rehearsal including inventory. Timing matters: a rehearsal on a quiet Sunday can hide weekday volume and interface load.

Measure:

• Runtime and restart behaviour
• Reconcile pack production time
• Exception volumes by class
• Business smoke tests: pick, ship, receive, make, invoice

Dual-run

Short dual-run can be rational for high-risk sites. Endless dual-run usually means open positions were never trusted. Tie exit to evidence packs, not optimism. See why migrations fail after go-live.

ERP reconciliation pack: what “done” looks like

Exception register mandatory: blocking defect vs accepted exclusion with owner.

Cross-system programmes (ERP + CRM + finance)

If CRM and finance are moving too:

• Agree customer master ownership and sync direction
• Align item/product identifiers across quote-to-cash
• Coordinate open AR/AP boundaries so invoices are not migrated twice or not at all
• Sequence waves so operational opens are not stranded without financial posting paths

Multi-system complexity is where a Data Migration Readiness Assessment pays for itself before the SI statement of work hardens the wrong assumptions.

Common ERP migration anti-patterns

Day-one operations are the acceptance test

ERP data migration best practices reduce to a simple standard: masters complete enough to transact, open positions true enough to run the building, history intentional enough to justify its cost, and proof strong enough that operations and finance can sign without crossing their fingers.

If your plan still describes ERP data as a single cutover workstream with count checks at the end, split it now, master data, open transactions, historical balances, and put reconciliation at the centre.

Next step: Discuss ERP migration delivery, read the finance migration companion, or book a readiness assessment.