A good data migration plan answers ten questions before anything moves: what's in scope, where the data lives today, how each field maps to the new system, what needs cleaning, how much history to bring, how you'll test it, how you'll prove the numbers match, how the cutover weekend runs, who signs it off, and what you check after go-live. Most migration problems come from skipping the middle steps: no trial runs, no reconciliation, and old mess loaded straight into the new system. This guide walks through each step in plain English and finishes with a checklist you can copy into your own project plan. It covers the plan, the strategy decisions, data migration testing basics and the cutover plan in one place.
Why migrations go wrong
A system change is usually bought for the new software's features. The data gets treated as a copy job for the last fortnight. That's backwards. Your customers, suppliers, items, prices, open orders, jobs and balances are what the new system runs on, and they carry years of workarounds: duplicate customers, items nobody sells, codes that meant something to a person who left.
Three things go wrong again and again:
- Old problems move across. Duplicates and inconsistent codes are loaded as they are, so the new system disagrees with itself from day one. Our guide to data cleansing before a migration covers how to find and fix them.
- Nobody proves it arrived. The load "finished without errors", but nobody compared totals, so a missing batch of open invoices turns up at month-end.
- The cutover is improvised. Staff keep entering into the old system after the final extract, and those transactions vanish.
Step 1: Scope and strategy
Write one page that says what's moving and why. Include:
- Systems leaving and arriving, and anything that stays (for example, the accounting software stays but the job system changes).
- The kinds of data: master data (customers, suppliers, items, staff, chart of accounts), open transactions (unpaid invoices and bills, open orders, jobs in progress, stock on hand) and history (closed transactions).
- The approach: a big bang cutover (everything moves at once over a weekend or month-end) or a phased move (one site, entity or module at a time). Big bang is simpler to reason about. Phased lowers the risk but means the two systems must stay in step for a while, which often needs a temporary connection between them.
- The go-live date, chosen around your busy periods, month-end and year-end.
- Who decides: a business owner for each kind of data, not just the project lead.
Step 2: Inventory where the data actually lives
List every source, not just the main system. The real data is often spread across the old system, spreadsheets, an Access database, a CRM, email folders and a shared drive. For each source, note the owner, the rough number of records, how current it is, and whether it's the master copy or a copy of something else. This is where information stuck in separate systems (data silos) shows up: the same customer kept in three places, with three different addresses.
If the old system is ending, check what you can still export and how. Our post on getting your data out of your accounting software covers the exports to request before access changes.
Step 3: Map every field
A data mapping document lists each field in the old system and where it goes in the new one, with any rule that changes it on the way. A simple spreadsheet works, one row per field:
- old system and field
- new system and field
- the rule (copy as is, split, combine, convert codes, default a blank)
- who confirmed it
- notes and open questions.
Mapping is where business decisions hide. If the old system has one "customer type" field and the new one has three, someone in the business has to decide which goes where. Don't let the developer guess. Codes need a lookup table: old tax codes, payment terms, item categories and units of measure each map to their new values.
Step 4: Clean before you move
Fix the data at the source, before the first trial run, so every trial gets cleaner data. Typical work:
- merge duplicate customers, suppliers and items
- archive records with no activity for years
- fix missing or inconsistent ABNs, emails, addresses and units
- agree one naming and coding standard
- clear old unapplied payments and credits where the accountant agrees.
Decide what "clean enough" means for each kind of data. Customers you invoice next week must be right. A supplier you used once in 2015 can be archived. Our data cleansing services page explains how we approach larger clean-ups, for example after an acquisition.
Step 5: Decide how much history to bring
This is the biggest strategy decision after the approach. The usual options:
- Balances only: opening balances at the cutover date, plus open transactions. Fastest and cleanest.
- Recent history: for example, the current and previous financial year in detail, so staff can look up recent jobs and customers.
- Full history: everything. Slowest and most expensive to test, and old data often doesn't fit the new structure.
Many businesses bring balances and open items, plus a limited history, and keep the old system (or an export of it) read-only for lookups and audits. Check record-keeping obligations with your accountant before deciding what you can leave behind.
Step 6: Trial runs and data migration testing
Never let the first full load be the real one. Plan at least two trial migrations into a test copy of the new system:
- First trial: load everything, find what breaks, fix the mapping and the cleansing.
- Second trial (dress rehearsal): run the whole thing the way you will at cutover, timed, from the final extract through to sign-off.
Testing has three layers:
- Counts: the number of customers, suppliers, items, open invoices and open orders in the old system matches the new one, or the difference is explained (for example, archived duplicates).
- Totals: debtors, creditors, stock value and work in progress match to the cent at the cutover date.
- Spot checks by the people who use it: each team picks real records they know well (a big customer, a tricky item, a job half finished) and checks them end to end, then runs a few everyday tasks such as raising an invoice or receiving stock.
Write down what result counts as a pass before each trial starts, so sign-off isn't a matter of opinion.
Step 7: Reconciliation
Reconciliation is the proof that the numbers arrived. Prepare a short pack that compares old and new at the cutover date: trial balance, aged debtors, aged creditors, stock on hand by location, open orders, jobs in progress and any balances specific to your business. Every difference is either fixed or written down with a reason. Your accountant or finance lead should review it. If the old and new systems still don't agree after go-live, our post on why systems disagree explains the usual causes.
Step 8: The cutover plan
The cutover plan is an hour-by-hour run sheet for the go-live window. It should cover:
- The freeze: the exact time staff stop entering into the old system, and what they do with work that arrives during the freeze (a paper or spreadsheet log, entered on day one).
- Final extract, load and reconciliation, using the steps you rehearsed.
- Connections switched over: integrations, banking feeds, online store, EDI and any scheduled reports pointed at the new system.
- A go/no-go point: who decides, and on what evidence.
- A rollback plan: what happens if the go/no-go is "no". Usually that means the old system stays live and the freeze log is entered there.
- Communication: who tells staff, customers and suppliers about anything that changes for them, such as new invoice numbers or remittance details.
Step 9: Sign-off
Each data owner signs that their area is complete and correct, against the pass criteria from the dress rehearsal, and the finance lead signs the reconciliation. Keep the sign-offs, the reconciliation pack and the final extract files together. You'll want them at year-end and for the auditor.
Step 10: Post-go-live checks
The first few weeks show what testing missed. Plan for:
- daily checks in week one: invoices, payments, stock movements and integrations all behaving
- a first month-end close with extra time and a reconciliation back to the old system's closing figures
- a list of fixes and small changes, owned and dated
- turning the old system read-only, then retiring it on a date you choose, once the history you need is safe.
Copyable data migration checklist
Plan and strategy
- ☐ Scope written: systems, kinds of data, what stays
- ☐ Big bang or phased decided, with reasons
- ☐ Go-live date set around busy periods and month-end
- ☐ Data owner named for each kind of data
Inventory and mapping
- ☐ Every data source listed, with owner and record counts
- ☐ Field mapping document complete and confirmed by data owners
- ☐ Code lookup tables agreed (tax codes, terms, categories, units)
Cleansing and history
- ☐ Duplicates merged, inactive records archived
- ☐ "Clean enough" agreed for each kind of data
- ☐ History decision made and checked with the accountant
- ☐ Plan for read-only access to old data
Testing
- ☐ Pass criteria written before each trial
- ☐ First trial run, issues fixed
- ☐ Dress rehearsal run and timed
- ☐ Counts, totals and user spot checks passed
Cutover
- ☐ Freeze time and freeze log agreed
- ☐ Run sheet with owners and times
- ☐ Integrations and feeds switchover listed
- ☐ Go/no-go owner and rollback plan agreed
- ☐ Staff, customers and suppliers told what changes
Sign-off and after go-live
- ☐ Reconciliation pack reviewed and signed
- ☐ Data owners signed off
- ☐ Week-one daily checks done
- ☐ First month-end reconciled to old closing figures
- ☐ Old system retirement date set
Frequently asked questions
What's the difference between a data migration plan and a data migration strategy?
The strategy is the set of big decisions: big bang or phased, how much history to bring, and when to go live. The plan is everything that carries those decisions out: inventory, mapping, cleansing, trial runs, reconciliation, cutover and sign-off.
How many trial migrations do we need?
At least two: one to find problems and one dress rehearsal run exactly like the real cutover. Complex moves with several sources often need more. Keep going until a full run passes the criteria you wrote down beforehand.
Should we bring all our history into the new system?
Usually not. Most businesses bring opening balances, open transactions and a limited recent history, and keep the old data read-only for lookups. Full history is slower to test and often doesn't fit the new structure. Check record-keeping requirements with your accountant first.
What is a cutover plan?
A cutover plan is the run sheet for go-live: when the old system freezes, the final extract and load, reconciliation, switching connections, the go/no-go decision, and how to roll back if needed.
Can we migrate and clean the data at the same time?
You can, but it's safer to clean at the source before the first trial, so every trial uses cleaner data and you can see what changed. Cleaning during the load hides changes inside the migration scripts, where they're harder to check.
Getting help with a migration
If your old system is reaching end of support, our legacy system end-of-life migration page covers the dated Microsoft changes and what to do about them. For the migration itself, our database integration and migration work covers the mapping, trial runs and reconciliation, with your team signing off each step. We scope every project first and give you a fixed quote after a free initial chat. Kenomont brings 20+ years of building and moving business systems.
If you're planning a system change, book a free initial chat and we'll talk through the plan before you commit to a date.