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

The short answer

Switching field software almost always orphans your historical job-cost data because migration tools map standard fields cleanly but break custom fields and record IDs. Data problems are a leading cause of trouble: in Panorama Consulting's 2024 ERP research, 46% of projects that ran past schedule blamed data issues, and McKinsey and Oxford found large IT projects run 45% over budget while delivering 56% less value than promised. Protect the history with a full CSV export before cutover, 90 days of parallel running, and a 30-day reconciliation audit before you trust the new system's reports.

Key takeaways

Migration tools handle standard fields well and custom fields poorly, so tech specialties, equipment categories, and customer tiers usually land as unqueryable freeform text.
New systems mint fresh customer, job, and technician IDs, so a customer with 47 prior jobs can show up as a first-time customer and the history goes operationally invisible.
Software rollouts routinely run past their promised timeline (Panorama Consulting finds a large share over schedule), so budget 5-7 months from decision to confidence, not the 30 days the vendor quotes.
Re-syncing historical invoices carelessly can double-count revenue and make a P&L unreadable, so reconcile revenue and per-job cost within 5% before the parallel period ends.

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. This is the same seam that plagues contractors who never migrate at all, which is why your field platform and accounting never agree.

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 benchmark review

See whether your books are benchmark-ready.

We check whether your financial data is clean enough to trust, then show the fastest path to a useful benchmark.

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.

See whether your books are benchmark-ready.

Want next week's benchmark in your inbox?

See whether your books are benchmark-ready.