What actually breaks when you migrate from one field service platform to another?

Sort your data into three piles before you plan anything

Pile one is settled history: completed jobs, paid invoices, closed customers. It has no state to preserve and can be moved, or simply archived, at leisure.

Pile two is live reference data: customers, properties, price book items, tax rates, technicians. It must be correct on day one and it must be deduplicated before it moves, because a migration is the cheapest deduplication opportunity you will ever get.

Pile three is work in flight. This is the pile that hurts.

The items that reliably cause pain

• Open estimates. They carry a value, an expiry and a follow-up obligation. Most exports flatten them into text and lose the option structure and the pricing logic.
• Recurring schedules. Agreements are defined by a rule, not a list of dates. Rules rarely translate cleanly, so occurrences are often rebuilt by hand.
• Partially billed work. Deposits taken in the old system against jobs that will complete in the new one produce revenue that appears in neither place unless you plan for it.
• Stored payment credentials. Card tokens belong to the old processor. They generally do not transfer, which means customers on autopay have to re-enroll.
• Attachments and photos. Often exportable in bulk but not re-linkable in bulk, so they land in a folder instead of on the job.
• Custom fields. The field survives; the reporting built on it does not, because the field ID changes.

A cutover sequence that limits damage

Freeze new estimate creation in the old system a week before go-live and create new ones in the new platform. Let existing scheduled work finish in the old system where practical, and dispatch all new work from the new one. Run both in parallel for one full billing cycle so month-end has a known-good comparison.

Keep the old system in read-only access for at least a year. Historical revenue questions will come up, and reconstructing them from a partial import is worse than looking them up. If continuity of reporting matters, sync both systems into one store during the overlap so revenue reporting does not have a hole in it — that is a common reason companies bring in an integration partner for a migration they could otherwise run themselves.

Decide what history you actually need

Full-fidelity history import is expensive and usually unnecessary. Most operators need customer and property records, service history summaries, and invoice totals by customer. Line-item detail from six years ago rarely earns its migration cost. Say out loud what questions you need history to answer, then import only what answers them.