Migrate your Field Pros data

Work Orders are the primary FSM object; naming, lifecycle stages, and custom fields vary widely between platforms (e.g., JobEngine uses Jobs, ServiceTitan uses Work Orders). We map status enums and custom properties field-by-field at migration scoping.

Many FSM platforms call the primary job object 'Jobs' rather than Work Orders. Where the destination uses a different primary object name, we merge fields into the target's equivalent and preserve the original Work Order/Job identifier as a custom property.

Standard Contact/Account-style objects present in most FSM platforms. Name, phone, email, and address fields are stable across migrations with minimal transformation required.

Business accounts associated with Customers. Most FSM platforms store Company/Account data in a flat schema compatible with standard CRM account objects.

Asset hierarchies (parent-child relationships, installed-at location) are handled via mapping since destination systems often flatten or omit parent-child relationships. Serial numbers and model numbers are preserved as custom properties.

Technician records map to Users or Contacts in the destination depending on whether the technician also receives customer-facing communications. Certification and skill fields are migrated as custom properties.

Service locations tied to Assets or Customers may have a different schema in the destination. We map address, contact, and location-specific notes, and we flag any location-specific pricing rules that will not carry forward.

Open invoices present migration risk because FSM platforms handle tax, line-item rounding, and payment status differently. We export invoices as line-item records and flag any that were partially paid or have outstanding balances for manual review before closure.

Estimates in FSM platforms often contain bundled line items and custom pricing rules that do not map cleanly to standard quote objects. We migrate line items and flag any bundle structures that require manual recreation.

Recurring maintenance schedules are not reliably migratable because their trigger logic (time-based, meter-based, usage-based) is platform-specific and depends on Asset telemetry that does not transfer. We document the schedule rules for manual recreation.

Photos, PDFs, and signed documents attached to Work Orders or Assets are exported as binary blobs and reattached in the destination. File naming conventions may change during migration.

Custom properties on Work Orders, Jobs, and Assets are migrated only if the destination schema can receive them. We flag any custom fields that reference platform-specific picklist values that have no equivalent in the target system.

Parts and inventory levels map to Items or Products in the destination, but current stock quantities are approximate due to real-time inventory changes. We migrate the parts catalog and flag post-migration stock discrepancies.

Payment transactions are migrated as financial records but not re-posted to accounting systems. Outstanding balances and partial payments require manual reconciliation review.