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

The short answer

Switching field software can orphan historical job-cost analysis if custom fields and record IDs are not mapped and reconciled. Panorama Consulting's2024 ERP report lists data issues for 46.3% of respondents reporting duration overruns. McKinsey/Oxford's 2012 large-IT research reports 45% average budget overruns and 56% less value than predicted, for projects initially over $15M. These are broader ERP/large-IT populations, not measured SMB field-software migration rates. 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 plan roughly 4-5 months for pre-work and 90-day parallel checks including the audit, plus separately scheduled implementation. A 30-day cutover offer, where made, does not certify reconciled history.
Re-syncing historical invoices carelessly can double-count revenue and make a P&L unreadable, so reconcile aligned revenue and per-job cost bases with an explicit timing/tax/cost bridge and investigate unexplained residuals before parallel checks end.

If this is you

You're moving from Jobber to ServiceTitan. Or BuildOps to ServiceTitan. A move into Spectrum also changes the accounting/ERP layer, so scope that separately. 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. A job-type field in one system may have no exact equivalent in another. This is a hypothetical mapping risk, not proof about a named vendor field. 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.

Standard-field migration and custom-field migration can have different coverage; inspect the actual mapping rather than assuming both work. 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.

Start with a free conversation about your priorities. With agreed access to the relevant records, we compare your numbers with applicable benchmarks and identify what to review first.

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)
Retain an isolated shadow dataset or read-only old-system snapshots for comparison. Do not let a shadow integration post a second copy to the live accounting ledger.
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)

First align entity, report period, revenue basis and transaction population. Bridge sales tax, deposits, credits, write-offs and cutoff timing explicitly. Investigate the unexplained residual before ending parallel checks; a mismatch alone is not proof of connector misconfiguration. Define an approved dollar tolerance for the comparable measure rather than relying on an unexplained percentage.

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)

This 10-job selection is a spot check, not complete-population proof. Identify whether FSM labor is a configured estimate/rate-card amount or actual paid labor, and whether accounting includes employer burden, overtime or different allocation. Compare only aligned bases, preserve a per-job bridge and investigate unexplained residuals against the defined tolerance. A 5% gap alone does not diagnose a mapping defect.

Audit 3: Reconcile customer records

As a 5-customer spot check, pick 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. A$25-100K budget is an unverified planning illustration; actual scope and vendor quotes determine cost.

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
This planning schedule takes about 4-5 months if the 30-day audit occurs inside the 90-day parallel period, plus any separately scheduled implementation/cutover work. Actual readiness is evidence-based, not a calendar guarantee.

Compare this planning schedule with your vendor's actual proposal. A promised 30-day cutover, where offered, is not evidence that historical reporting reconciles. Agree on acceptance criteria before treating the migration as complete.

Use the financial diagnostic as a starting point or book a free 30-min audit, we'll review your pre-migration plan and tell you where the gaps are likely to be.

Source and scope note

The migration checks are Level operating guidance. Panorama's2024 ERP report covers ERP implementations, while McKinsey/Oxford's October 2012 study covers large IT projects initially over $15M. Neither supplies an FSM data-loss incidence, a required 90-day duplication policy or a universal implementation duration. Do not run a shadow integration that posts a second copy of financial transactions to the live ledger; use read-only snapshots or isolated reconciliation outputs instead.

See whether your books are benchmark-ready.

Want next week's benchmark in your inbox?

See whether your books are benchmark-ready.