Migrate from ServiceNow Field Service Management to Nutshell

ServiceNow FSM state flows require value-mapping rebuild in Nutshell

ServiceNow FSM work orders use state flows (Open → In Progress → Pending Parts → Closed Complete) that are configurable per FSM plugin. Nutshell's deal stages are a flat pick-list per pipeline with no conditional state progression logic. We map each ServiceNow FSM state value to a corresponding Nutshell stage, but the underlying state-flow rules (mandatory fields per state, auto-transitions, SLA timers) have no Nutshell equivalent. If your FSM state model is complex, document the state mapping requirements before migration — our field-level diff step surfaces any states that don't have a clean stage target.

Asset and inventory data collapses to custom fields with limited queryability

ServiceNow's fm_asset table, fm_expense_line (parts used), and fm_labor_rate_card (technician rates) form a rich field-service data model. Nutshell has no asset object, no inventory tracking, and no labor-cost accounting. We migrate asset serial numbers, model info, and install dates as custom fields on the Nutshell Company record, and expense totals as custom fields on the Deal. However, Nutshell's reporting cannot natively filter or group by these custom fields the way ServiceNow's performance analytics can. If asset-level reporting is critical post-migration, plan for a separate reporting layer or a connected BI tool.

Scheduling and dispatch data does not migrate — routes are lost

ServiceNow FSM's core value is its intelligent scheduling engine that matches technicians to work orders based on skills, territory, availability, and real-time traffic. Nutshell has no scheduling, dispatch, or route-optimization capability. We do not migrate ServiceNow scheduling assignments, route data, or dispatcher configurations. The technician-to-work-order assignments (the 'who is assigned') migrate as owner links on Nutshell Deals, but the scheduling rules, territory boundaries, and optimization constraints are destination-side rebuild items. Plan 10–20 hours of process design with your Nutshell admin to define how field service routing will work post-migration.

ServiceNow API rate limits constrain FSM data extraction volume

ServiceNow enforces REST API rate limits based on your licensing tier and system resources. Large FSM deployments with 50,000+ work orders, 20,000+ assets, and extensive task history can exhaust ServiceNow API quotas during a migration run, causing 429 errors and stalled extraction. We mitigate this by using ServiceNow's CSV/Excel export processor for bulk data extraction and our ETL layer for transformation, reducing API call volume. However, for real-time delta-pickup during cutover, we rely on the Table API and will coordinate with your ServiceNow instance's throttling profile to stay within quota limits.

Nutshell's contact-role model limits multi-company associations

ServiceNow FSM allows a technician or asset to be associated with multiple customer accounts simultaneously. Nutshell's person-to-company association is primarily 1:1 for the 'primary company' link, with secondary associations available but less structured. If your FSM data has complex N:N relationships (one asset serving multiple customers, or one technician working across multiple accounts), those relationships migrate as serialized data in custom fields or as Activity notes — they won't appear as native linked records in Nutshell's UI. We flag N:N relationships during the migration plan phase so you can decide how to represent them.