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”.
What is data migration?
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.
Why data migration is harder than people expect
1) Your data lives in lots of places
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.
2) The data is messy (because business is messy)
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)
3) Old systems and new ERPs don’t speak the same language
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)
4) Volume adds weight
Even “simple” businesses can have:
-
Thousands of customers/products
-
Years of transactions
-
Attachments and documents
-
Millions of rows once you include line items
A simple, practical data migration playbook (5 phases)
Phase 1: Discovery and planning (2–4 weeks)
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.
Phase 2: Data cleansing (4–8 weeks)
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”.
Phase 3: Build migration + test it properly (3–6 weeks)
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.)
Phase 4: Production migration (go-live weekend)
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.
Phase 5: Post-migration validation (week 1–2)
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
The most common problems (and how to avoid them)
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.
Best practices that make migrations smoother
-
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
Quick checklist
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
Conclusion
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.
