If ERP is a new house, data migration is the plumbing. You can have gorgeous rooms (configuration, workflows, dashboards), but if the pipes are full of gunk or connected to the wrong places, go-live gets… dramatic.
Data migration is often the biggest cause of ERP delays and post-go-live headaches because it’s not just “move files”. It’s “move truth”.
Data migration is transferring information from your current systems into your new cloud ERP, including things like:
Customers and suppliers
Inventory items, pricing, and stock on hand
Financial balances and transactions
Open orders, invoices, bills, and projects/jobs
Employee records
Historical data for reporting and context
The real work is making sure the data is clean, consistent, and usable in the new system, not just copied across.
Most businesses have data scattered across Accounting software, Inventory or warehouse systems, CRM, Spreadsheets (usually… many spreadsheets), Access databases or small “side” apps, Emails, documents, attachments, etc.
That means you’ll need to decide what the “source of truth” is when systems disagree.
Common issues include:
Duplicate records (the same customer entered multiple times)
Inconsistent naming (ABC Ltd vs ABC Limited)
Missing fields (no address, no phone number, no terms)
Outdated records (closed accounts still active)
Incorrect values (wrong costs, incorrect categories)
Notes fields full of critical info (unstructured data)
Differences usually show up in:
Field names and structures
Required fields (new system needs info you didn’t store before)
Validation rules and formats
How relationships work (customer → orders → invoices → payments)
Even “simple” businesses can have:
Thousands of customers/products
Years of transactions
Attachments and documents
Millions of rows once you include line items
Goal: Know what you have, where it is, and what you’re migrating.
Do this:
List every data source (systems + spreadsheets + “hidden” databases)
Identify who owns each dataset (Sales, Finance, Purchasing, etc.)
Define the migration scope: what’s going in vs staying behind
Create data mapping (source field → target field + rules)
Decide what to migrate
A useful way to sort it:
Must migrate (needed to operate Day 1):
Active customers and vendors
Current inventory items + balances
Open sales/purchase orders
Unpaid invoices and bills (AR/AP)
Current year financials
Active employees
Open jobs/projects
Should migrate (valuable context):
2–3 years of transactional history
Prior year financials (comparisons)
Customer interaction history (if it’s usable)
Supplier performance info
Archive (keep access, don’t migrate):
Inactive customers/vendors (e.g., 3+ years)
Discontinued products
Very old closed transactions
One-off vendors and obsolete info
Pro tip: Keep the old system accessible in read-only for historical lookups, or export key reports to PDF before switching it off.
Goal: Remove junk, fix inconsistencies, fill gaps.
This phase takes the most time because it needs human decisions, not just tools.
Key cleansing work:
Deduplicate: merge duplicates into a single “master” record
Standardise: naming rules, phone formats, address formats, product codes
Complete: fill missing required fields (or set sensible defaults)
Validate: check balances, stock quantities, costs, terms, and classifications
Ownership matters
Assign data owners who can make business calls:
Customer data: Sales / Customer Service
Vendor data: Purchasing / AP
Product data: Inventory / Purchasing
Financial data: Finance / Accounting
Employee data: HR
Consultants and IT can help, but the business must decide what’s “correct”.
Goal: Create a repeatable process you trust.
Most migrations follow an ETL approach:
Extract from sources
Transform using mapping rules
Load into the ERP
Validate and reconcile
Do multiple mock migrations (never just one)
A good cadence looks like:
Mock 1 (Initial test): reveals the real problems
Mock 2 (Refinement): confirms fixes and improves confidence
Mock 3 (Dress rehearsal): final practice run
Production cutover: go-live migration using the proven process
Validate every run
Record counts (expected vs loaded)
AR/AP totals match
Inventory value reconciles
Trial balance agrees
Samples checked (random records + critical customers/items)
Relationships intact (orders link to customers, lines link to items, etc.)
Goal: A clean cutover with minimal chaos.
A typical weekend flow:
Friday: finalise old system, freeze, backup, extract
Saturday: load data, validate, reconcile, test key transactions
Sunday: final checks, user access, integrations, comms, ready for Monday
About the “freeze”
You stop data entry in the old system so you’re not chasing a moving target.
If business continues (it always does), decide how to handle:
Orders received during freeze (manual log → enter Monday)
Urgent payments or critical transactions (special handling plan)
Parallel running (two systems at once) is usually expensive and confusing, so it’s best avoided unless absolutely necessary.
Goal: Stabilise fast and prove the numbers.
Day 1 checks:
Users can access the right data
Key processes work (invoice, receive stock, pay supplier, etc.)
Integrations are running
Core reports look sane
Week 1–2:
Full reconciliation (finance + operational)
Structured issue tracking and triage
Daily check-ins until stable
Formal sign-off once balanced and verified
1) “It’s just copy-paste”
Reality: data migration can be 30–40% of the total effort.
Fix: treat it as a major workstream with its own timeline and owners.
2) Starting too late
Cleansing takes months, not weeks.
Fix: start data work during project initiation, alongside configuration.
3) No clear data ownership
If nobody owns the data, nobody fixes the data.
Fix: appoint data owners early and make decisions part of their role.
4) Not enough testing
The first migration always exposes surprises.
Fix: do at least three mock runs with validation after each.
5) “We’ll clean it up after go-live”
Bad data gets harder to fix once it’s inside the new ERP.
Fix: clean before you move, even if it means adjusting timelines.
6) Migrating the wrong history
Too little history frustrates users; too much wastes time and cost.
Fix: decide early what history is genuinely needed for reporting and service.
Start early and run data work in parallel with configuration
Document mapping rules and decisions (future you will thank you)
Automate extraction/loading where possible, but keep human judgement for quality
Validate continuously (counts, balances, samples, relationships)
Communicate often: status, risks, decisions needed
Plan for hypercare: you’ll still have issues, the goal is fast resolution
Planning
Data inventory completed
Migration scope defined (must/should/archive)
Mapping document created
Data owners assigned
Validation criteria agreed
Cleansing
Duplicates merged
Formats standardised
Missing fields completed/defaulted
Key data validated (stock, costs, balances)
Data owner sign-off
Testing
Migration scripts built
Mock run 1 completed + issues logged
Mock run 2 completed + issues reduced
Mock run 3 completed + ready for cutover sign-off
Go-live
Freeze plan agreed
Production migration executed
Counts + balances reconciled
Critical transactions tested
Users enabled + comms sent
Post go-live
Full reconciliation complete
Issues triaged and resolved
Lessons learned captured
Archive/read-only plan in place
Data migration isn’t a technical box to tick. It’s a business-critical effort that determines whether your new ERP launches cleanly or limps into go-live with a backlog of avoidable issues.
Treat data migration like the foundation of the project, because your new ERP is only as good as the data inside it.
Verde Group brings deep data migration expertise to cloud ERP implementations across New Zealand. Our structured approach, experienced specialists, and focus on data quality help ensure your ERP goes live with accurate, complete, and usable information from day one.
Want to de-risk your migration? Get in touch with Verde Group to discuss your data migration plan and how we can support your ERP implementation.