How do you migrate from one field service system to another without losing your history?

Closed history and open work are different projects

Closed records are facts. They have final states, final amounts and no future behavior, so they import cleanly and are worth moving in bulk. Open records are processes. An in-flight quote awaiting approval, a job scheduled next Tuesday and a partially paid invoice all carry state that the new system models differently.

The mistake is trying to migrate both with one script. The reliable approach is to move closed history in bulk and re-enter open work by hand, then verify that the count of hand-entered items matches a list someone printed before cutover.

Dependency order, and why it is not optional

Records reference each other. If you load them out of order, the references resolve to nothing and you get orphans that are extremely tedious to repair later.

• Customers first. Deduplicate before loading, not after. Phone numbers normalized to one format; addresses standardized.
• Properties and service locations second. Many businesses discover here that their old system conflated the customer with the address.
• Pricebook and items third. Historical line items need something to map to or they land as untyped text.
• Historical jobs and invoices last. Now the foreign keys have something to point at.
• Attachments and photos separately. These are usually the largest volume and the most commonly dropped.

Decide what you are actually keeping

Full-fidelity migration of everything is expensive and usually unnecessary. Most companies need three things from history: the customer with their contact record and equipment, a readable record of past work at that address, and enough revenue history to compare year over year.

Everything else — internal status changes, old notes threads, superseded quote versions — can stay in the archived system. Say so explicitly at the start, because scope creep in migrations is almost entirely made of history nobody ever opens.

Reconcile before you celebrate

Run three checks after load: record counts by entity type, revenue totals by month for the last twenty-four months, and a random sample of thirty customers inspected by a human who knows them. Count mismatches are usually deduplication working correctly; dollar mismatches are usually tax, credits or voided invoices handled differently. Both need an explanation before go-live, not after.

Keep the old system readable for at least a full tax year. Then plan the connections you will need on the other side — call tracking, marketing sources and reporting all have to be rebuilt against the new identifiers, and treating that as part of the integration project rather than an afterthought avoids a second painful month. Our integration approach assumes the join keys change at cutover.