Data Portability When Switching Field Service Management Software
Why this matters
A trade business that has run on one FSM platform for three or more years has hundreds of customer records, thousands of job records, equipment history, photo attachments, and signed documents accumulated. Switching platforms is sometimes necessary (the current platform has been acquired, prices have risen sharply, features have stalled, support has degraded) but the data-migration burden is the biggest source of post-switch pain. Most owners discover at the migration stage that the data they thought was theirs is locked in, partially exportable, or formatted in a way that no destination platform can ingest cleanly. The playbook to avoid that pain is to plan the switch like a data-engineering project, not a software-shopping exercise.
Decide whether to switch
Before the migration project, validate the decision. Switching has real cost: 80 to 200 hours of internal time depending on data volume, plus the destination-platform implementation cost, plus the parallel-running period where two systems are live.
Switch only when:
- Current platform has materially failed (acquired and stopped developing, pricing increased sharply, critical capability missing)
- Destination platform delivers a year-one ROI clearly greater than migration cost
- Internal capacity exists to run the migration without dropping operations
If the decision is "destination is somewhat better" rather than "current is failing," consider staying. The migration cost is rarely justified by incremental improvement.
Map the data domains
Before anything else, list what data exists and where it lives. Typical domains in an FSM platform:
- Customers. Name, address, contact info, customer type, tags, custom fields.
- Customer contacts. Secondary contacts at each customer (decision-maker, AP, on-site).
- Customer sites. For commercial and multi-property residential, separate sites under one customer record.
- Equipment. Customer-owned equipment with serial, make, model, install date, warranty.
- Service history. Every job ever performed, with date, description, technician, status.
- Estimates. All issued estimates with status (approved, declined, expired).
- Invoices. All issued invoices with status (paid, partial, outstanding, written off).
- Payments. Payment history per invoice.
- Photos and attachments. Job-attached photos, signed work orders, signed proposals, signed change orders.
- Notes. Customer notes, job notes, technician notes.
- Time entries. Technician time per job.
- Recurring schedules. Maintenance plans, recurring jobs, recurring invoices.
- Custom fields. Anything the business added to the standard data model.
For each domain, document the record count, the data structure, and the export capability.
Assess export capability per domain
Open the current platform and verify what can be exported. Three classes of export:
Class A. Self-service CSV export. Most platforms support this for customers, jobs, invoices. Quality varies. Test the export on each domain.
Class B. API export. The platform has an API; data can be extracted programmatically. Requires technical capacity (developer or migration vendor).
Class C. Vendor-assisted export. The platform's support team will produce a data dump on request. Sometimes free, sometimes paid. Required for proprietary data formats and for photo attachments on many platforms.
Photo attachments are the most-common Class C item. Self-service export typically gives a list of attachment URLs, not the actual files. Downloading thousands of files manually is impractical; either the API or the vendor-assisted export is required.
Negotiate the data exit
Before formally announcing the switch, ask the current vendor in writing what data can be exported in what format, what the vendor will assist with, timeline, cost, and post-cancellation data retention. The written response sets expectations and prevents surprise. For uncooperative vendors, the cancellation date is the negotiation lever; 90-day notice often produces better export terms than immediate cancellation.
Build the data map and scope
The data map records each source field, source data type and format, destination field, destination data type and format, transformation needed (e.g., phone formatting differences), and special handling (e.g., source has Customer.Type "Multi-Family" but destination only "Residential" / "Commercial").
Common transformation issues: phone number format, address structure (line 1/line 2 vs single field), date/time format, boolean encoding, status enums between platforms, character encoding for special characters and smart quotes.
Scope: migrate active customers and prospects, equipment for active customers, recurring schedules and maintenance plans, open invoices and AR balance, and 12-to-24-month job history. Archive (not migrate) old service history beyond 24 months, old paid invoices, dead estimates, and notes on inactive customers. Customers with no transaction in 24 months and no recurring plan are likely lost; the static archive preserves them for the rare lookup.
Run a pilot migration
Migrate a small subset (10 to 25 customers including a mix of residential and commercial, with active equipment, jobs, invoices) into the destination platform's sandbox or test tenant.
Verify:
- All data fields populated correctly
- Photo attachments visible
- Notes legible
- Equipment linked to the right customer
- Service history in chronological order
- Custom fields preserved
The pilot uncovers data-quality issues, mapping errors, and destination-platform limitations. Fix all issues before full migration.
Execute, validate, and train
Two cutover patterns: hard cutover (source locked at a defined moment, migration runs over a weekend, new platform live Monday) is right for lower-volume businesses; parallel run (both live for 30 to 90 days) is right for higher-volume. Five-employee operations almost always pick hard cutover.
After cutover, validate: customer count, equipment count, open AR balance (should reconcile to the cent), recurring schedule count, and spot-check 25 random customers. Document discrepancies; some platforms support post-migration bulk-import fix-ups.
Train the team before cutover, not after. Communicate to customers via the portal: email 30 days ahead, reminder one week ahead, instruction at cutover. Update marketing materials, email signatures, and Google Business Profile descriptions for any changed booking, payment, and document links.
Common failures: underestimating photo migration (largest data volume); skipping the pilot; no data-quality cleanup (dirty data carries forward); no cutover plan (drift into chaos); no customer communication (dead portal links produce panic calls).
References
- General Data Protection Regulation (GDPR) Article 20 - Right to Data Portability (US trades rarely subject, but the principle is sound)
- California Consumer Privacy Act (CCPA), Section 1798.130 - data portability rights for California residents
- AICPA SOC 2 Type II audit requirements (data handling at the vendor side)
- ASTM E1340 - Standard Guide for Rapid Prototyping of Computerized Systems (general data-migration discipline reference)
- ISO/IEC 27001 - Information security management (relevant when handling customer PII during migration)