Switching FSM software is an operational decision, not just a technology swap. The platform change is often the easier half. Getting your data — customer records, service history, open work orders, equipment assets, technician profiles, price books — out of one system and correctly into another is where implementations stall or fail.
This guide covers what data migration actually looks like when a field service business moves off spreadsheets or an older FSM tool onto a modern platform. No Oracle enterprise architecture. Practical advice for real field service operations.
Key takeaways
- Audit and clean your data before migration, not after — importing dirty data just recreates the problem in a new system
- Customer records and equipment histories are the most common sources of migration errors; tackle these first
- Plan for at least 30 days of parallel running where both systems are live
- CSV import handles most data; open work orders are often better re-entered manually at cutover
- Major FSM platforms — Jobber, Housecall Pro, ServiceTitan, FieldEdge, Service Fusion — each have distinct import capabilities and limitations
What data actually needs to migrate
Before touching any export or import tool, map what you’re moving. Field service migrations typically involve five categories of data:
Customer records — billing contacts, service addresses, account notes, and any customer-specific pricing or contract terms. This is usually the largest dataset and the messiest.
Equipment and asset history — serial numbers, installation dates, model information, and service history tied to specific units at specific locations. For HVAC, plumbing, electrical, and similar trades, this is often the most valuable data in the migration.
Work order history — completed jobs, dates, technician assignments, labor and parts used, and invoiced amounts. Recent history (last 2-3 years) is worth migrating; older records can often be archived.
Open and recurring work orders — active jobs in progress and any scheduled recurring service agreements. These require special handling at cutover.
Price books and service catalog — line items, flat-rate pricing, labor rates, parts catalog. Often a mess because one-off pricing adjustments accumulate over years without documentation.
Technician profiles — names, contact info, skills, certifications, territories. Usually the smallest and cleanest dataset.
Cleaning your data before you migrate
This step is not optional. Importing dirty data into a new FSM platform recreates every problem you have now — it just costs you a fresh start.
Deduplicate customers first
Most field service businesses accumulate duplicate customer records over time. The same customer appears twice because someone created a new record instead of searching, or because a name was entered differently (“Bob Smith Plumbing” vs. “Smith Plumbing - Bob”). In some older systems, duplicates appear because multiple service addresses for the same customer were each set up as separate accounts.
Run a deduplication check before export. Sort by phone number, email, or service address to surface matches. Merge records manually — don’t trust automated merge tools to handle address or notes fields correctly.
Standardize address formats
Inconsistent address entry causes problems in any FSM platform that uses GPS routing or maps integration. “123 Main St” and “123 Main Street” are technically different strings. Pick a standard format and normalize before migration.
Review equipment records
Equipment tied to wrong job sites, missing serial numbers, and model names entered inconsistently all create problems post-migration. If your new platform will use equipment records for maintenance scheduling or warranty tracking, this data needs to be clean.
Archive instead of migrate old history
Not all historical data needs to move. Completed work orders from five years ago rarely get referenced in daily operations. Keep them in your legacy system or export them to a spreadsheet archive. Migrating less data reduces import complexity and speeds up the process.
CSV imports vs. API migration paths
Most FSM platforms offer two primary ways to bring data in:
CSV import is the standard path for customer records, equipment lists, and price books. Every major platform provides import templates. You format your data to match the template, upload, and review errors. It works well for clean, structured data and gives you full control over what goes in.
The limitation is that CSV imports are manual and sequential. You typically import customers first, then equipment (linked to customers), then price books. Order matters because later records reference earlier ones.
API migration is used by implementation teams when volume is large or when migrating between two platforms that both have open APIs. The vendor’s implementation team or a third-party migration service handles this. It’s faster for large datasets but requires technical resources and costs more. For businesses with under a few thousand customer records, CSV import is almost always the right path.
Some platforms — particularly ServiceTitan — have dedicated data migration teams for onboarding. Others, like Jobber and Housecall Pro, rely primarily on self-serve CSV imports with support documentation.
How major FSM platforms handle imports
Import capabilities vary meaningfully across platforms. Here’s what matters for each:
Jobber has clean CSV import for customers, with some equipment and property fields supported. Their onboarding team walks new customers through the process. Price book imports are manual line-by-line. Good for smaller operations; less suited to very large datasets.
Housecall Pro supports customer import via CSV and handles some equipment fields. Their import process is guided through the app. Like Jobber, price book entry is mostly manual.
ServiceTitan has the most robust migration support in the category, with dedicated migration specialists for new customers. They handle customer records, equipment history, membership agreements, and historical work orders. The process is more structured and managed — and takes longer to complete, typically 60-90 days.
FieldEdge and Service Fusion both support CSV-based imports. Their onboarding teams assist with mapping. FieldEdge is particularly common for HVAC shops switching from older desktop software — including Wintac, the legacy desktop product FieldEdge itself acquired and retired, which it runs a dedicated migration path off of.
If you’re mid-evaluation, check the methodology for how this site assesses migration support as part of platform scores.
Handling open work orders at cutover
Open work orders are the trickiest data to migrate. The problem: they’re actively changing. A job that’s “in progress” has status, notes, and parts that can update between when you export and when you import.
The cleanest approach most businesses use is a hard cutover date. Pick a date, drive toward completing or rescheduling everything you can before then, and treat the remaining open jobs differently:
- Low complexity, upcoming jobs: re-enter manually in the new system
- Multi-visit or complex open jobs: complete them in the old system before switching
- Recurring service agreements: set these up fresh in the new system using your records, not an automated import
Manual re-entry for open jobs sounds like more work, but it forces a review of each active job and prevents the status mismatches and missing notes that imported open work orders often produce.
Recurring schedules and service agreements
Recurring maintenance schedules — quarterly filter changes, annual tune-ups, semi-annual inspections — are often stored in formats specific to your current platform. They usually don’t export cleanly.
Most businesses rebuild these in the new system rather than migrating them. Before cutover, run a report from your old system showing every active recurring schedule: customer, service type, frequency, last completed date, next due date. Use this as a rebuild checklist in the new platform.
This is labor-intensive but typically takes a few days for most operations, and it’s more reliable than trying to import recurring schedule logic across platforms.
A realistic migration timeline
Timeline depends on company size, data volume, and how clean your existing data is. A rough framework:
Weeks 1-2: Audit and plan. Export data from your current system. Run deduplication checks. Document what you have and what you’re migrating versus archiving. Identify gaps.
Weeks 3-4: Clean and format. Deduplicate customers, standardize addresses, clean equipment records. Format data to match new platform’s import templates.
Weeks 5-6: Test imports. Run imports in a test or sandbox environment. Review errors. Fix source data. Repeat until a clean import run succeeds.
Weeks 7-8: Parallel running. Go live in the new system while keeping the old one accessible. Take new jobs in the new platform; reference old for history questions. This phase catches problems before the old system is turned off.
Week 9+: Cutover and cleanup. Transfer remaining open jobs, rebuild recurring schedules, decommission old system access.
For businesses moving off spreadsheets, the timeline compresses — often 3-4 weeks total. For larger operations switching between enterprise FSM platforms, 90 days is more realistic. The FSM implementation guide covers the broader rollout context that surrounds the data migration piece.
Common pitfalls
Migrating without cleaning first. The most common mistake. The impulse is to export everything and sort it out in the new system. But import errors are harder to fix than spreadsheet cleanup, and bad data imported at go-live creates day-one problems for your team.
Underestimating equipment history complexity. Customer name and address fields translate easily. Equipment records — especially when service history is attached — require careful field mapping and often manual review for each major asset.
Forgetting price book alignment. Technicians using a new system that doesn’t have the right line items will improvise or call the office. Before go-live, make sure your price book in the new platform matches what your team actually sells.
Skipping parallel running. The temptation is to cut over clean and not maintain two systems. Don’t. Running both systems for 30 days catches the gaps — the customer who calls about a job that wasn’t migrated, the equipment record that’s missing, the recurring appointment that didn’t carry over.
Assuming the vendor handles it all. Even platforms with migration specialists rely on you to provide clean, complete data. The work of auditing and cleaning your own records is yours regardless of who does the technical import.
Data migration is the most skipped and most underestimated part of FSM software adoption. Getting it right means the new platform starts with clean, complete data that your team can actually trust — and that makes the rest of the implementation substantially easier.