You're Switching Field Software and You Just Lost 18 Months of Job Cost Data.

If this is you

You're moving from Jobber to ServiceTitan. Or BuildOps to Spectrum. Or whatever the migration is. The data transferred. But your historical job costing is orphaned. You can't run profitability by tech, by job type, or by customer for the prior period. You've lost your operational dashboard at the worst possible moment.

FSM migrations are some of the most expensive moments in service business operations. Done well, you upgrade capability and the team stays productive. Done poorly, you lose 18 months of operational history and end up making pricing decisions on gut feel for the next 6 months.

Here's the playbook for doing it right.

Why migrations lose data

Three structural reasons:

1. Custom field decay

Every FSM has different fields. ServiceTitan's "Job Type" maps loosely (or not at all) to BuildOps's "Project Phase." Custom fields you set up in your old system to track tech specialties, equipment categories, or customer tiers usually don't have a clean equivalent.

Migration tools handle the standard fields well. They handle custom fields poorly. The data is "there" — usually as freeform text — but not queryable.

2. ID mapping breaks historical analysis

Customer IDs, job IDs, technician IDs are all different in the new system. The migration creates new IDs. Old IDs become unreferenced.

Result: a customer who had 47 jobs in your old system now appears in your new system as a customer with their first job. The history is technically migrated as records but operationally invisible because nothing connects.

3. Integration drift

If your old FSM was integrated with QuickBooks, Sage, or another accounting system, the integration mapped revenue/cost transactions in a specific way. The new FSM has a different integration with potentially different mappings. So:

Revenue recognition timing might shift (one system recognizes on dispatch, another on invoice)
Cost allocations move between job-level and overhead-level
Tax categorization can change
Class/department coding might break

Your historical accounting data and operational data stop matching, even when each looks "right" individually.

The pre-migration checklist (4-6 weeks before cutover)

Before you start migrating, do this work:

1. Document your current data structure

For your old FSM:

Standard fields you actually use (and which you ignore)
Custom fields and what they mean
ID conventions for customers, jobs, techs
Integration mappings to accounting

This is the "before" state. You need it for reconciliation later.

2. Run a full export of historical data

Pull at minimum:

All customer records with full history (job count, revenue, payment history)
All job records with cost data (labor hours, materials, sub costs)
All technician utilization data
All invoice/payment history
All quote/estimate data

Save these as CSV files. These are your insurance policy. Even if the migration loses something, you have the raw data.

3. Identify the analyses you can't lose

What reports do you run today that you can't function without? Examples:

Customer profitability by trailing 12 months
Tech utilization by job type
Quote conversion rate by lead source
Job cost variance by trade

Map each to specific data fields. After migration, you need to be able to run these same reports. If a field is missing in the new system, you have a gap.

4. Map the integration architecture for the new system

Does the new FSM integrate with your accounting software in a way that preserves your current mappings? If you use QuickBooks classes for location coding, will the new integration preserve those?

This is the most common failure mode. The integration "works" but the mappings change subtly, breaking historical comparison.

Free profitability audit

Books behind? We rebuild from the bank statement up.

We benchmark your books against 2,200+ service businesses and tell you exactly where the money is going.

The during-migration playbook

Run both systems in parallel for 90 days

Yes, it's expensive. Yes, it's annoying. Do it anyway.

For 90 days after cutover:

New work goes into the new system (primary)
Same work also gets entered/synced to the old system (shadow)
Run reports out of both
Compare results

Where they don't match, investigate. The reasons are usually:

New system maps a field differently
Integration is mis-configured
A custom report in the old system used logic that doesn't exist in the new one

After 90 days, you've either confirmed the new system is producing trustworthy reports or you've found the gaps. Without parallel running, you find the gaps 6 months later when you're trying to price a job and realize the data is wrong.

Document every decision

Every time you choose how to handle a data field during migration ("we decided to map ServiceTitan job-type X to BuildOps project-type Y"), write it down. With reasoning.

Six months from now, when something doesn't reconcile, you'll need this documentation.

The 30-day post-migration audit

After cutover, before parallel running ends, do a structured audit:

Audit 1: Reconcile revenue

For the first full month after cutover, compare:

Total revenue per accounting system (the new integration)
Total revenue per FSM (gross billing)
Total revenue per old FSM (if still running parallel)

These should match within rounding. If they don't, the integration is mis-configured. Fix before the parallel period ends.

Audit 2: Reconcile job-cost

Pick 10 random completed jobs from the first month. For each:

Pull labor cost from new FSM
Pull labor cost from accounting (the integration result)
Pull labor cost from old FSM (if still running)

Compare. Match within 5%. Larger gaps = mapping problem.

Audit 3: Reconcile customer records

Pick 5 long-standing customers. Confirm the new system shows their full historical job count and revenue. If history is partial or missing, you have a customer master integration issue.

Audit 4: Verify your critical reports

Run each of the analyses you identified as "can't lose" in the pre-migration step. Do they produce numbers that make sense and tie to other system reports?

If any of them are broken, you have specific work to do — usually building custom reports in the new system or accepting the gap.

When the migration is already done badly

If you've already migrated and are realizing data is broken, three options:

Option 1: Re-import from your CSV exports. If you saved the historical data CSVs (and you should have), you can build a separate analytics system that joins old data with new. Usually requires a data analyst or a tool like Looker / Metabase.

Option 2: Live with it for 90 days, then have a clean go-forward dataset. Accept that history is gone and start building a clean dataset from the migration date. Less ideal but practical.

Option 3: Engage migration consultants. Some FSMs have professional services teams who can come in and clean up a botched migration. Expensive ($25-100K) but sometimes necessary if the data is critical to operations.

What "good" looks like

A well-executed FSM migration:

4-6 weeks of pre-work (documentation, exports, planning)
90 days parallel running
30-day audit + reconciliation
Total elapsed time: 5-7 months from decision to confidence

Yes, that's longer than the FSM vendor will tell you. The vendor wants you to migrate in 30 days. They're not the ones who have to make pricing decisions next year using broken data.

Run a migration readiness check in 2 minutes or book a free 30-min audit — we'll review your pre-migration plan and tell you where the gaps are likely to be.

Books behind? We rebuild from the bank statement up.

Want next week's benchmark in your inbox?

Books behind? We rebuild from the bank statement up.