ServiceNow to Salesforce migration: field service data and workflow
What moving from ServiceNow to Salesforce actually involves for field service teams — data mapping, timeline, effort range, and the hardest part.
Why teams move from ServiceNow
ServiceNow's thin financial module and lack of native inventory management cause teams to move when they need a full-stack FSM/ERP — ServiceNow excels at workflow but cannot replace a financial ERP.
What you're moving to: Salesforce
Salesforce (CRM + Field Service) is a CRM platform from Salesforce Inc., best suited for SMB to Enterprise organisations in Technology, Healthcare, Financial Services, Manufacturing. Strengths relevant to this migration: Market-leading CRM; Field Service Lightning strong for scheduling; AppExchange ecosystem. Known limitations to factor in: Not a financial ERP (requires integration for AP/AR/GL); high per-user cost at scale.
The hardest part of this migration
This is the step that consistently takes longer than planned. Budget time for a data audit before any tooling decisions — the quality and structure of your ServiceNow data determines whether the migration runs in months or quarters.
What data needs to move
| Data entity | Migration complexity | Notes |
|---|---|---|
| Work order history | Medium–High | Volume and schema complexity vary; closed work orders with all linked records (parts, labour, notes) are the most complex |
| Customer and site records | Low–Medium | Usually cleaner than work orders; watch for duplicate records and address format differences |
| Asset and equipment register | Medium | Hierarchy structures (parent/child assets) must map to Salesforce's asset model exactly |
| Technician profiles and skills | Low | Skills taxonomy must be rebuilt in Salesforce before work order assignment logic works correctly |
| Parts and inventory | Medium | Part numbers, UoM, and bin locations need mapping; in-flight inventory levels need a cutover count |
| SLA and contract terms | High | SLA configuration in Salesforce must be built before any work orders are dispatched from the new system |
| Open work orders at cutover | High | In-flight jobs at cutover date need manual reconciliation — no automated tool handles this reliably |
Migration sequence
- Data audit (weeks 1–3). Extract a sample of ServiceNow records. Assess completeness, duplicates, and schema gaps. This is where the effort estimate gets refined — everything that follows depends on data quality.
- Target system configuration (weeks 2–8, parallel). Configure Salesforce before any data arrives: work order types, skill definitions, SLA rules, dispatch board layout, and mobile app settings. Data migration into an unconfigured system creates rework.
- Historical data migration (weeks 6–14). Migrate closed work orders, customer records, asset register, and technician profiles. Validate record counts and spot-check a sample of complex records.
- Integration cutover (weeks 10–16). Connect Salesforce to your billing system, ERP, and any other adjacent tools. Test the full job lifecycle — intake to invoice — end to end before go-live.
- Parallel run (4–8 weeks). Dispatch from Salesforce. Maintain ServiceNow as a read-only reference. Reconcile daily. This is the phase that teams consistently underestimate — budget the dispatcher time to run both systems simultaneously.
- Cutover. Freeze ServiceNow data. Complete delta migration of records created during parallel run. Go live. Retain ServiceNow read-only access for 90 days minimum.
Effort and cost range
| Component | Estimate |
|---|---|
| Salesforce implementation (net-new) | $50,000–$1,000,000 |
| Migration-specific effort (data extraction, mapping, validation) | 60–80% of implementation cost on top |
| Total migration budget range | $30,000–$800,000 |
| Timeline | 3–12 months from kickoff to cutover |
These are ranges, not quotes. The actual number depends on data quality, integration count, and how much ServiceNow has been customised. A data audit in the first 3 weeks will produce a tighter estimate than any figure given before the audit.
Frequently asked questions
3–12 months from kickoff to cutover, including parallel run. The variable is data complexity and integration count. Clean, well-structured ServiceNow data migrates faster than heavily customised instances with years of accumulated work order history.
ServiceNow FSM data is relatively accessible via its Table API, but the data model is heavily workflow-driven — task states, assignment groups, and SLA timers are embedded in records in ways that do not map cleanly to asset-centric FSM platforms. Beyond the technical extraction, the hardest operational challenge is the parallel run — running two dispatch systems simultaneously while keeping records reconciled.
In-flight work orders at cutover are the most difficult records to migrate cleanly. Most teams handle these manually: freeze ServiceNow at cutover, complete a snapshot of open orders, and create them fresh in Salesforce. Automated migration of open work orders with live technician assignments rarely works without significant reconciliation effort.
Get a migration estimate
Tell us your ServiceNow instance details — how long it's been running, how many open work orders, and what integrations are in place. We'll give you a realistic effort range before you commit to anything.
Get a quoteRelated: Work order management software guide · ServiceNow vs Salesforce comparison · Salesforce to ServiceNow migration