How Data Migration Works When You Switch Platforms
Migration is the part of switching software that determines whether you keep twelve years of accumulated knowledge or start again with a customer list. Most of the outcome is decided before anything is transferred.
Data migration is not a single event. It is export, clean, map, load, validate — and the cleaning step is where the work actually is.
The single largest determinant of success is whether your addresses are consistent. Everything else is mechanical.
What actually has to move
Four categories, and they behave completely differently.
| Category | Examples | Difficulty |
|---|---|---|
| Simple records | Customer names, phone numbers, addresses, email | Low. Structured, standard, exports as CSV |
| Relational records | Jobs linked to customers, equipment linked to addresses, invoices linked to jobs | Medium to high. The links are what break |
| Configuration | Price book, job types, agreement templates, user permissions | Medium. Usually rebuilt rather than migrated |
| Binary attachments | Photos, PDFs, signatures, documents | Very high, often impossible. Assume loss |
The second row is where most disappointment lives. A CSV of customers migrates fine. A CSV of jobs that references customer IDs from the old system needs those IDs mapped to the new system’s IDs, and if that mapping is imperfect you end up with orphaned jobs attached to nobody.
What does and does not survive is covered in more detail in questions to ask before signing a contract — and it is worth reading before you choose the new platform, not after.
The sequence
Cleaning: where the work actually is
Your existing data has years of accumulated inconsistency in it. Migrating it unchanged carries all of that into the new system, where it is harder to fix.
Address normalisation
The biggest single task, and the one that determines whether your equipment history stays connected to the right places.
One house will exist in your data as several variants — differences in whether the street type is abbreviated, whether there is a trailing full stop, whether the unit number sits before or after, whether the town is included. Each variant looks like a different property to an import routine.
Do this before you export anything else. Agree a single format, apply it consistently, and merge the duplicates. Everything downstream depends on it.
Deduplication
The same customer entered twice with different phone numbers. Husband and wife as separate records for one house. A commercial client as three entries because three different people booked work.
Merge on address first, then on phone number, then review what is left by hand.
Deciding what not to bring
The instinct is to migrate everything so the new system feels complete. Resist it — bulk historic data is the largest time sink in the process and almost none of it gets read.
| Bring | Leave behind |
|---|---|
| Customers seen in the last three years | Customers not seen since before that |
| Equipment at active addresses | Equipment you already replaced |
| Active service agreements | Expired agreements |
| Open estimates still in play | Estimates older than six months |
| Last two years of job history | Everything before that |
| Current price book | Old price lists “for reference” |
Keep the old system readable, or keep a full export archived. Then when someone genuinely needs 2018, it exists — you just did not spend three weeks importing it.
Mapping fields
Old system fields have to be matched to new system fields, and they will not correspond neatly. Three situations recur:
One field to many. A single “notes” field in the old system contains equipment details, access instructions and customer preferences all mixed together. Splitting that is manual, and it is worth doing for active customers at least — structured equipment data is what makes the new system useful.
Many to one. Separate old fields that the new system holds in one place. Straightforward.
No equivalent. A custom field with nowhere to go. Decide whether to create a custom field in the new system or accept the loss. Do not default to creating custom fields for everything, or you rebuild the old system’s clutter inside the new one.
Import 50 customers with their linked jobs and equipment. Then examine them in detail before loading the remaining thousands.
You will find something wrong — a date format reversed, phone numbers losing their leading digit, equipment attached to the wrong address. Finding it in 50 records is a correction. Finding it in 4,000 is a re-migration.
Validating that it worked
Three levels, and all three matter.
Counts. Did 4,182 customers go in and 4,182 arrive? Same for jobs, equipment records and agreements. Discrepancies point at rejected records, usually for a fixable reason.
Spot checks. Pick twenty customers at random — including your most complex ones, a property manager with multiple addresses, a customer with several pieces of equipment. Check every field against the old system by eye.
Relationship checks. This is the one that gets skipped and the one that fails. Are jobs attached to the right customers? Is equipment attached to the right addresses? Are agreements linked to the right properties? Run a report of orphaned records — anything with no parent — and investigate every one.
Who does the work
Three models, and the middle one is what most small shops actually need.
Vendor-managed. They handle export, mapping and load. Costs money, often part of an implementation fee. You still have to do the cleaning, because only you know which duplicate is the real customer.
Vendor-assisted. They provide templates and validation; you prepare the data. The common arrangement and usually the right one, because the cleaning judgement has to come from inside your business anyway.
Self-managed. Viable for a small shop with clean data and someone comfortable in a spreadsheet. Budget more time than you expect.
Whichever model, one person in your business has to own it, with hours actually allocated — for the same reasons set out in moving from paper to software. Migration without a named owner drifts, and drifting migration means running two systems for months.
Parallel running: usually a mistake
The instinct is to run old and new together for a month as insurance. It rarely works.
Everything gets entered twice, staff pick whichever system feels easier for each task, and within three weeks neither is complete. You now have two partial records of the same period and no reliable source.
Better: a hard cutover with the old system readable. New work goes into the new system from a specific date. The old system stays available in read-only form for ninety days so anyone can look something up. Nothing new gets entered into it.
Frequently asked questions
How long does data migration take?
What is the most important preparation step?
Should I migrate all my historic data?
Will my job photos and attachments transfer?
Should I run both systems in parallel for a while?
How do I know the migration actually worked?
What to do next
- Standardise your addresses now, before you have chosen a platform. It is useful regardless and it is the largest single prep task.
- Decide your cut-off for historic data. Two years of job history is usually plenty.
- Name the owner and put the hours in their week.
- Insist on a 50-record test load before the full migration, and check it by eye.
- Questions to ask before signing a contract — what exports and what does not
- Moving from paper to software — the wider rollout sequence
- How to evaluate HVAC software — asking about migration during evaluation
The timings in this guide are illustrative estimates for a small to mid-sized shop, not commitments. Migration effort varies enormously with data volume, data quality and how much cleaning is required. Export capabilities differ between platforms — confirm what can actually be extracted before planning anything.