Home services and trades
Field service software migration: data fields that usually break
By SourceX Editorial · Updated
Short answer
In a field service software data migration, the fields that usually break are the ones carrying relationships or rules: customer-to-location links, equipment install dates, membership terms and visit balances, pricebook codes, preferred technicians, custom fields and historical job statuses. Test each one with a count, a spot check and a business rule before cutover, and archive the old system untouched.
Key takeaways
- Plain text rarely breaks; fields that encode relationships, rules or lists of allowed values usually do.
- Membership visits remaining and renewal dates deserve their own test, because customers have already paid for them.
- Every field group needs an owner on your team who signs off, not just the migration vendor.
- Keep the old system's export untouched, with original IDs, even after the new system is live.
Why do some fields break and others survive?#
Fields break in a field service migration when the old and new systems model the same thing differently. A customer name survives because both systems treat it as text. A membership breaks because each system has its own idea of plans, billing cycles, visit counts and renewal rules.
Three patterns cause most of the damage. Relationships get flattened, such as a customer with several service locations. Lists of allowed values do not match, such as job types and statuses. Calculated values, such as visits remaining, get recalculated by the new system from incomplete history.
The field-by-field breakage table#
The breakage table lists the fields that most often fail and the test that catches each one. Use it as a starting checklist, then add the fields specific to your trade, such as backflow test dates, refrigerant type or panel schedules.
| Field | How it usually breaks | Validation test |
|---|---|---|
| Customer and service location | Bill-to and service addresses merge, or extra locations drop | Count locations per customer before and after |
| Contacts and roles | Tenants, property managers and owners collapse into one contact | Spot check landlord and commercial accounts |
| Equipment install date and serial | Dates default to the import date; serials get truncated | Compare a sample of equipment records field by field |
| Membership terms | Start, renewal and billing dates shift or reset | Match renewal dates for a sample of members |
| Visits used and remaining | Recalculated from partial history | Compare remaining visits for every active member |
| Pricebook codes | Codes remap, merge or lose their links to history | Check that historical invoice lines still resolve |
| Job type and status | Values do not map one to one, so history lands in a catch-all | Count jobs by type and status before and after |
| Preferred technician | Field is dropped or mapped to the wrong user | Spot check high-value customers |
| Custom fields and tags | Unmapped fields are silently skipped | List every custom field and its destination |
| Notes and timestamps | Author and time are lost, or notes merge into one block | Read the notes on several long-standing customers |
| Photos and attachments | Links break when files are not moved with the records | Open attachments on sampled jobs |
| Open balances and credits | Balances or unapplied credits do not carry over | Reconcile accounts receivable totals |
Records left behind on purpose#
Records left behind on purpose are often the right call for the new system, but the decision should be deliberate and written down. Import scopes are usually built around what dispatch needs tomorrow, so closed jobs, unsold estimates, call recordings and form responses are commonly left in the old system.
Record what was excluded and why, and make sure each excluded record family exists in a complete export before the old system closes. The new platform does not need years of closed tune-ups to dispatch tomorrow's call, but a warranty claim, a buyer or an AI developer reviewing your history may.
Mapping decisions to settle before the first test load#
Mapping decisions settled before the first test load prevent most of the breakage in the table above. Each decision is a business choice, not a technical one, so the owner of each field group should make it in writing and the vendor should build the import to match.
Run at least one test load into a sandbox before the real import, and test against these decisions rather than against the vendor's defaults.
- A value map for job types and statuses, with no catch-all bucket for history.
- A membership plan crosswalk, including how visits remaining and renewal dates carry over.
- A pricebook crosswalk that keeps old codes searchable on historical invoices.
- Whether inactive customers come across, and how they are flagged.
- Whether notes import as separate dated entries or one combined block.
- Where photos and attachments live, and how they stay linked to jobs.
Validation tests to run before cutover#
Validation before cutover combines counts, sums, samples and business rules. Each one catches a different failure, so run all of them rather than relying on the vendor's import report, which usually confirms that rows loaded, not that they loaded correctly.
- Counts: customers, locations, equipment, members and jobs by type, old versus new.
- Sums: open receivables, unapplied credits and deferred membership balances.
- Samples: a spread of records across years, trades and customer types, compared field by field.
- Rules: renewal dates fall where they should, remaining visits match and tax rates apply correctly.
- Workflow: a CSR books, dispatch assigns and a technician closes a test job end to end.
- Sign-off: each field group owner approves in writing before cutover.
Who signs off on each field group?#
Sign-off belongs with the people who live with each field after go-live, not with the migration vendor. The vendor knows the import; your team knows when a record looks wrong.
| Field group | Owner | Sign-off question |
|---|---|---|
| Customers, locations and contacts | CSR lead | Can we find and book any customer the way we did before? |
| Memberships | Service agreement coordinator | Does every member show the right plan, renewal and visits? |
| Equipment | Service manager | Do technicians see accurate equipment history on arrival? |
| Pricebook | Operations or general manager | Do quotes and historical invoices still make sense? |
| Balances and payments | Controller | Do receivables and credits reconcile? |
| Technicians and dispatch rules | Dispatch lead | Are skills, zones and preferred technicians right? |
Illustrative: an HVAC and electrical company switches platforms#
Illustrative: a fictional HVAC and electrical service company moves to a new field service platform after outgrowing its old one. The vendor's import report shows every customer and member loaded without errors.
The service agreement coordinator's sample tells a different story. Remaining visits on multi-system memberships were recalculated from imported history, and some members show none left. Preferred technicians did not map, and a group of commercial jobs landed under a catch-all type because the old job types had no match.
The team fixes the mappings, reloads memberships from a dedicated export of visits remaining and reruns the tests. The old system's full export, with original IDs and the vendor's mapping file, is sealed as an archive before the subscription ends.
Why the legacy archive still matters#
The legacy archive matters because it holds exactly the history the migration chose not to carry. Equipment failures, repair decisions, callbacks and parts used across years of work are useful to the next buyer of the business, to manufacturers studying field failures and to AI developers building tools for service operations.
SourceX looks at that archive through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The first fit check uses metadata only. If a package proceeds, the SourceX Evidence Packet records which system produced each file and when, so the provenance of a migrated company's history stays clear.
Frequently asked questions
Should we migrate all history or only active records?
Many companies bring across only what the new system needs to operate, such as current customers, open work, equipment and live memberships, and archive the rest. Importing full history can slow the project and drag old data problems into the new system. What matters is that the archive is complete and searchable.
How long should we keep the old system running?
Keep it available until validation passes, the first month-end close in the new system reconciles and the complete export has been checked. The deciding factor is reconciliation, not a date on the calendar.
Should we clean data before or after migration?
Fix what affects the mapping before migration, such as duplicate customers and retired pricebook items. Leave cosmetic cleanup for later. Never clean the archive copy itself; it should stay exactly as the old system held it.
Is the vendor's mapping file worth keeping?
Yes. The mapping file shows how each old field and value landed in the new system. Keep it with the archive, because it is the only record of how history was translated if someone later compares old and new data.
Do customers need to be told about a migration?
A back-office switch rarely needs notice, but membership billing changes, new payment links or a new customer portal should be explained before they happen. If a new vendor will process customer data, check that your privacy notice still describes it accurately.
Related resources
- QuestionDo AI labs buy code?
- InsightCan you license CAD and engineering drawings to AI companies?
- InsightCan you license code reviews and pull requests to AI companies?
- InsightCode snapshot vs full git history: what to include in a code license
- SolutionEnterprise data: the records of how organizations actually work
- SolutionProprietary data: information only your company has
See if your company qualifies
A short company assessment. No data uploads are needed.