ERP data migration: what actually moves, what stays behind, and how to prepare

Businesses evaluating a new ERP tend to spend most of their time comparing features. The question that actually determines whether go-live works is simpler and harder: what happens to all your data?

Data migration is where ERP projects get hurt. Not by features that don't quite fit, but by customer records that won't load, inventory balances that don't reconcile, and pricing tables that need rebuilding from scratch. This guide covers what actually moves in an ERP migration, what typically stays behind, the decisions no-one tells you about up front, and the NZ-specific considerations that apply to every implementation here.

Two categories: master data and transactional data

Before getting to the migration plan, it helps to think in two buckets.

Master data is the reference data your business runs on day-to-day: your customer list, supplier list, product and SKU catalogue, pricing tiers, chart of accounts, warehouse locations, staff records, and tax codes. This is the data that must be in the new system before anyone can do anything on Day 1.

Transactional data is the history of what has happened: invoices raised, purchase orders placed, payments received, inventory movements, and so on. This category is where the decisions get interesting.

What migrates on Day 1

Every ERP migration moves all master data. There is no version of a working system that starts without your customers loaded. What also migrates on Day 1 is the snapshot of where your business sits right now:

• Open invoices — every invoice that hasn't been paid at the point of cutover must appear in the new system so your AR team can continue to collect
• Open purchase orders — outstanding orders from suppliers that haven't yet been received
• Stock on hand — your current inventory counts and valuations, by location if you run multiple warehouses
• Opening trial balance — if the new ERP includes accounting, the account balances at cutover date that let your bookkeeper start from a clean, reconciled starting point

Getting these right is the migration. The rest — historical transactions — is a separate decision.

The history decision

Should you bring five years of closed invoices into the new ERP? Three years? None at all? This is the question most implementations handle badly — either by attempting too much (causing the migration to drag on and reconciliation to fail) or by migrating nothing and discovering that staff can't look up a customer's order history from last year.

The core problem with full historical migration is that old and new systems rarely share the same data structure. Mapping every transaction from an Accredo or MYOB Exo data model into a new custom ERP involves interpretation at every step — and that interpretation introduces errors that compound as you go back in time. The further back you go, the worse the data quality and the more time it takes.

A practical approach for most NZ businesses:

1. Migrate master data and open transactions fully — these are non-negotiable
2. Bring the last one to two years of transaction history into the new system for operational reference (customer purchase history, supplier order patterns)
3. Keep the old system accessible in read-only mode for the remainder — which also satisfies your IRD obligations

NZ-specific: IRD and the seven-year rule

The Inland Revenue's record-keeping requirement for GST and income tax is seven years. That means any historical transaction records you hold need to remain accessible for that period — but they don't need to be in your new system. An archived export or a read-only legacy instance satisfies the obligation.

In practice, most NZ ERP migrations leave the old system running in read-only mode (no new transactions, existing data intact) for a transition period, then export to a structured archive before decommissioning. The key is that the data is accessible and auditable, not that it lives in the operational system. Your accountant and tax advisor should confirm the format that satisfies IRD requirements for your business.

The cutover date also has GST implications. Most NZ businesses time the ERP go-live to coincide with the end of a GST period — either monthly or two-monthly — so that the final return from the old system closes cleanly and the new system starts from a GST-zero position.

The chart of accounts: the decision hiding in plain sight

Replacing an ERP is one of the few moments when redesigning the chart of accounts is practical. Many businesses carry the same account structure they started with fifteen years ago — a product of the original accountant's preferences, now patched with workarounds and unused accounts.

A migration is an opportunity to clean this up: consolidate redundant codes, add cost centres or departments that the business now needs, and align the structure with the reporting your management team actually uses. This work happens before migration, because once you decide on the new COA, you map the old account codes to the new ones — and that mapping determines how historical transactions appear in reports.

If you carry your old COA directly into the new system without review, you carry its problems with it. Most implementations that skip this step regret it within twelve months.

The data quality problem that derails timelines

In almost every ERP migration, the data extraction phase reveals that the data in the old system is messier than anyone expected. Common problems:

• Duplicate customer records — the same customer entered twice with different codes over the years
• Inconsistent product codes — SKUs that exist in the order system but not in accounting, or vice versa
• Pricing tables with gaps — missing price tiers for certain customer segments, or price records that no longer match active product lines
• Supplier records with missing ABN/GST numbers, or contact details that haven't been updated in years

Cleaning this data is a project before the migration project. Businesses that skip it either delay go-live when problems surface during testing, or go live with known data quality issues that staff then spend months correcting manually.

A mock migration run — extracting, transforming and loading data into a test environment four to six weeks before go-live — is the tool that surfaces these problems while there's still time to fix them. The first mock run almost always reveals something significant.

What doesn't migrate (and why)

A few things rarely make it into the new system cleanly:

• Custom reports and views built on the old system's data model — these need to be rebuilt, not migrated
• Scanned documents and email attachments that were linked to transactions — these typically require a separate document migration or archival plan
• Audit trails and change logs from the old system — the old system's internal audit structure rarely maps to the new one
• Workflow configurations — approval rules, notification settings and automation from the old system must be rebuilt in the new one

Questions to ask before you commit

When you're assessing an ERP implementation partner, these are the migration questions that tell you whether they've done this before:

1. What is your standard approach to a mock migration run, and how many do you do?
2. What tools do you use to extract data from our current system (Accredo / MYOB / Xero / Attaché)?
3. Who owns data cleansing — us or you, and what does that handover look like?
4. How do you handle the opening trial balance reconciliation?
5. What is your process if we find a significant data issue four weeks before go-live?
6. How do you handle the cutover weekend — what's the rollback plan if something fails?

Vague answers to these questions are a warning sign. A partner who has run migrations from NZ accounting systems will have specific, lived answers.

What this looks like in practice

When Zeabyte builds a custom ERP for an established business, data migration is scoped as its own phase — not an afterthought tagged on at the end of the build. We extract from whatever the client is running today (Accredo, MYOB Exo, Xero, Attaché, CSB-System and others — see our full integrations list), run a data audit, clean against the target data model, and do at least one full mock migration before the cutover weekend. The opening balance reconciliation is signed off by the client's accountant before we touch production.

If you're planning an ERP replacement and want a clear-eyed view of what your data migration will actually involve, talk to us — we'll look at your current systems and tell you what to expect before you commit to anything.