A system replacement can look straightforward until someone asks where the customer notes are held, which spreadsheet contains the current prices, or whether the old system’s order history is still needed. That is where a guide to data migration planning becomes useful. Moving data is not simply a technical task. It is a business change that affects how people find information, serve customers and keep work moving.
For growing businesses, poor migration planning often creates the very problems a new system was meant to remove: duplicate records, missing information, staff working from old files and reporting nobody trusts. A sensible plan avoids that by making clear decisions before anything is moved.
Start with the business process, not the data export
The first mistake is to export everything from the old system and hope it can be sorted out later. Most established businesses have years of duplicate contacts, retired product lines, abandoned job records and spreadsheets that were built for one-off needs. Carrying all of it into a new platform makes the new platform harder to use from day one.
Start by mapping the process the new system needs to support. For example, follow an enquiry from first contact through quotation, order, delivery, invoicing and aftercare. Identify the information staff need at each stage, who owns it and where it currently lives.
This establishes the difference between data that is useful and data that is merely available. A customer’s active contact details, credit status and open orders may be essential. Ten years of old internal notes may not be. The right answer depends on the business, regulatory requirements and the practical value of being able to retrieve historic information later.
Historic data does not always need to sit in the new operational system. It may be safer and cheaper to retain a read-only archive, provided authorised staff can access it when needed.
Define what will move and why
A migration scope should be written in plain English and agreed by the people who use the process, not just the person building the system. It should set out each data set, its source, its destination and its purpose.
Typical data sets include customers, suppliers, contacts, products, pricing, jobs, orders, stock, invoices, documents and user permissions. But the detail matters. “Customer data” is not a sufficient definition if some contacts have opted out of marketing, some customers trade under several names, or account managers use their own local naming conventions.
For every data set, decide whether it will be:
- migrated in full because it is needed for current operations
- migrated in a reduced form, such as active customers only
- retained in an archive for reference
- cleaned before migration
- left behind because it has no ongoing business value
This avoids scope drift and reduces arguments late in the project. It also gives the business a clear opportunity to remove information it no longer needs, which is good operational housekeeping as well as sensible data protection practice.
Clean the data before building around it
A new system cannot fix unreliable data by itself. If customers appear three times under slightly different names, telephone numbers are stored in free-text notes, or product codes are inconsistent, those issues need addressing before or during migration.
Data cleansing does not have to become an endless project. Focus first on the fields that drive real work: names, addresses, contact details, account status, product codes, prices and dates. Set simple rules for each. For instance, decide how company names are formatted, whether a contact can belong to more than one account, and which field is the source of truth when two systems disagree.
This is often where operational knowledge is most valuable. A developer can identify duplicates, but a member of the team may know that two similar records represent separate trading entities, or that a “closed” customer is likely to place seasonal orders again. The best results come from combining both views.
A guide to data migration planning needs clear ownership
Data migration is frequently delayed because everyone assumes someone else will make the difficult calls. Assign named owners for the main areas of data. They do not need to do every piece of cleansing themselves, but they need authority to confirm what is correct.
A practical setup usually includes a business owner who makes final priority decisions, process owners who validate the data, and a technical lead who maps, transforms and loads it. In a smaller business, one person may cover more than one role. What matters is that decisions do not disappear into a shared inbox.
Agree how decisions will be recorded. A short migration log is usually enough. It can capture questions such as whether inactive contacts should move, how missing delivery addresses are handled, and what to do with records that fail validation. This saves time when the same issue surfaces during testing or after launch.
Map fields carefully, including the awkward ones
A field mapping document is the working bridge between the old and new systems. It identifies the source field, destination field, expected format and any transformation required.
Straightforward fields such as first name and telephone number are rarely the problem. The risk usually sits in the awkward details: dates stored in different formats, one address field that needs splitting into several, values hidden in notes, or a single old status that needs to become several more useful statuses in the new workflow.
Do not assume matching labels mean matching meanings. An old “completed” job may mean work finished, invoice raised, invoice paid, or simply that someone stopped updating the record. The definition must be agreed before it is mapped.
Where data is being drawn from spreadsheets, check for hidden rows, formula results, multiple tabs and local copies. Spreadsheet-led processes often contain important information outside the file everyone believes is current.
Test with real scenarios, not just record counts
A migration that imports 5,000 customers without error is not necessarily successful. The real question is whether staff can complete day-to-day work using those customers once the data has arrived.
Run a test migration early enough to learn from it. Ask users to find a customer, create a quotation, place an order, check a price, raise an invoice and produce a report. Use realistic examples, including awkward cases such as a customer with multiple sites, an order containing discontinued products or an invoice linked to a partial delivery.
Check both quantity and quality. Record counts should reconcile between source and destination, but spot checks are equally important. Compare a sample of high-value customers, current orders and important financial records against the source. If totals differ, investigate before proceeding rather than accepting a vague explanation about “data differences”.
Plan the cutover around how the business works
Cutover is the point when the business stops relying on the old process and begins using the new one. The plan should be shaped by operational reality. A business that takes orders constantly may need a short, carefully managed freeze period. A business with a quieter weekend or month-end window may have more flexibility.
Set a clear point after which changes in the old system will not be included unless they are entered manually into the new one. Communicate this plainly. If staff continue updating old spreadsheets after the final export, the business quickly ends up with two competing versions of the truth.
A cutover plan should cover the final export, data load, validation, user access, communications and support for the first few working days. It also needs a fallback decision. If a critical issue is found, can the old system remain in use temporarily, or is there a safe way to reverse the change? The answer depends on the system and the work involved, but it should never be improvised under pressure.
Treat the first weeks as part of the migration
Go-live is not the finish line. The first week usually reveals the questions nobody thought to ask during testing. A field may be technically present but difficult to find. A report may need an extra filter. Staff may discover that an old workaround was compensating for a genuine process gap.
Monitor data quality and usage closely at this stage. Deal with genuine faults quickly, but avoid rebuilding the system around every individual preference. Separate issues that block work from requests that can be reviewed once the team has settled into the new process.
Good migration planning gives a growing business more than a clean database. It creates confidence that people are working from the same information, using a process that can support the next stage of the business rather than holding it back.