Field service software migration checklist

A field service migration succeeds when staff can serve the next customer with trusted context, not when every legacy row appears somewhere. The migration plan should preserve necessary relationships among customers, locations, jobs, appointments, evidence, and financial references while limiting unnecessary data. This guide describes a buyer-run method, not a completed migration.

Buyer scenario: active work spans the cutover

Consider a contractor with repeat customers, multiple service addresses, open estimates, scheduled appointments, incomplete jobs, photographs, pricebook items, and historical invoices. Work cannot stop while data moves. Some legacy records are duplicated, and old notes contain information the business should not copy without a retention decision.

Appoint a business data owner, technical migration owner, and acceptance owner. Inventory each object, relationship, attachment type, identifier, source field, target field, volume, quality issue, retention basis, and downstream consumer. Classify records as migrate, archive with controlled access, rebuild, or dispose through an approved process.

Decision criteria for migration readiness

Prioritize identity and relationships: customer, billing contact, service location, equipment or asset, then estimates, appointments, jobs, parts, documents, and financial references. Decide how duplicates are resolved and which identifiers survive. Never copy sensitive payment credentials through an improvised export; map service-provider responsibilities and PCI DSS scope with qualified help.

Define acceptance measures for required fields, relationship integrity, attachment retrieval, active-work status, totals, dates, searchability, permissions, and export. Include rejected-row reporting and correction ownership. FTC guidance supports collecting only needed data and controlling access, while the buyer's legal and contractual obligations determine retention.

Reproducible evaluation plan

Build a representative sample containing a simple completed job, a customer with several addresses, an open estimate, a job awaiting a part, a recurring visit, corrected contact information, and attachments. Export from the source, transform through documented rules, import into a nonproduction target, and preserve logs.

Have office and field users locate each record and perform the next expected action. Reconcile source counts, target counts, rejected rows, and relationship checks. Repeat after corrections until predefined acceptance is met. This is a proposed rehearsal; no production data or vendor system was used for this guide.

Edge case: rollback after new work begins

Suppose launch occurs, technicians create new notes, and a missing relationship is discovered that prevents safe dispatch. The rollback plan must address records created after the freeze, not merely restore the old database. Define how new appointments, job evidence, customer changes, and financial activity are captured and reconciled.

Set a short decision window, named authority, communication plan, and secure transfer method. Preserve immutable source exports, transformation versions, validation results, and the reason for rollback. Avoid a long dual-entry period in which neither system is authoritative.

Plan the archive as a product staff will actually use. Define who can access it, how identity is verified, which searches are possible, how attachments are retrieved, how access is reviewed, and when records may be disposed under approved policy. Test one customer-support request that requires legacy context after cutover. If the answer depends on a former employee or an undocumented database query, the archive is not operational. Keep a field dictionary, transformation rules, and reconciliation report with the migration evidence so later teams understand what moved and what deliberately did not.

Record the archive test result and its owner beside the cutover approval.

Conclusion: migrate decisions, not just rows

Approve cutover only when active work, identity relationships, essential history, permissions, and exports pass the written checks. Archive data that must remain accessible but does not belong in daily work. Document disposal decisions. A smaller trusted dataset is more useful than a complete-looking migration whose duplicates and broken links force staff back to memory.