Migrate your ServiceNow Field Service Management data

Work Orders (table: sm_work_order) are the primary FSM entity and migrate cleanly as the root record. We export all core fields including state, priority, short_description, description, and the parent Work Order reference. FSM-specific fields like service_address, customer, and assigned_to are mapped directly to the corresponding sys_user or location sys_id values in the target system.

Work Order Tasks (table: sm_work_order_task) are child records of Work Orders. We preserve parent-child relationships by exporting the parent Work Order sys_id alongside each task and reconstructing the hierarchy in the destination system. Task-level states, assignees, and durations migrate as-is.

Technicians in FSM are represented as records in the Field Service Resource (sm_resource) table linked to sys_user records. We export the sys_user reference, skill set, work location, and availability windows. Where the destination system represents technicians differently (e.g., as Users with custom role fields), we merge the resource attributes into the destination user record and flag the mapping for review.

Locations in FSM (table: sm_location) include both Internal Business Locations and External Business Locations. We export the full location hierarchy including address, geographic coordinates, location type, and parent location reference. Location-to-Work Order assignments are preserved as reference fields during migration.

FSM references Customer and Account records that may originate in CSM or other modules. We map the customer reference by exporting the account sys_id and re-resolving it against the target instance's account table. Where accounts have been customized with extended fields, we flag each extended field for explicit mapping.

FSM Work Orders frequently reference Assets (table: alm_asset) and Configuration Items from the CMDB. We export the CI sys_id and asset tag but note that CI relationships (affected_by, depends_on, etc.) are not automatically carried across instances and require explicit relationship mapping.

FSM Inventory Management tracks parts at locations and on work orders via the sm_stockroom and sm_reserved_parts tables. We export reservation records and stockroom quantities but flag that inventory replenishment rules and par-level configurations are destination-specific and require manual reconfiguration.

Dispatch records (table: dispatch_dispatched) are derived state records tied to the Scheduling engine. We export the dispatched-to technician, time window, and route assignment as Work Order fields rather than standalone records, since scheduling logic is engine-specific. Actual versus scheduled time is preserved as a comparison set.

Knowledge Articles linked to Work Orders or FSM Problems are exported from the kb_knowledge table with topic and text preserved. We carry the article sys_id as a reference but note that viewing permissions and workflow state (draft/published/retired) are set independently in the destination system and should be confirmed post-migration.

Labor Rate Cards (table: fm_labor_rate_card) define billable rates by skill level and time of day. We export rate card definitions and line items, but rate card assignment to Work Orders or Technicians is a FSM-specific configuration that must be re-established in the target system as part of the financial setup phase.

FSM uses state flows (table: sf_work_order) that govern Work Order lifecycle transitions. These flows differ from CSM state flows. When migrating from a split CSM-FSM instance, we flag all state references in Work Orders and Tasks for manual remapping against the target instance's state flow definitions.