Freshservice to ServiceNow migration requires ticket table decomposition, CMDB relationship extraction, manual workflow rebuilds, and careful API rate limit management — plan 3–16 weeks depending on complexity.
There is no native migration path from Freshservice to ServiceNow; the migration requires significant custom engineering. The fundamental challenge is that Freshservice uses a unified ticket model with flat CMDB structures, while ServiceNow employs a task table hierarchy (incident, sc_request, sc_req_item, sc_task, problem, change_request) and a prescriptive CMDB built on the Common Service Data Model (CSDM). Custom work is required to decompose Freshservice service requests into ServiceNow's multi-table catalog structure, rebuild Workflow Automator logic in Flow Designer, extract CMDB relationships via per-CI API calls, preserve audit timestamps by overriding system fields, and rewrite inline image references in knowledge base articles before the source instance is decommissioned.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Freshservice Service Requests include requested item data alongside the ticket
In ServiceNow, the catalog request (sc_request), requested item (sc_req_item), and catalog task (sc_task) are separate, linked records. A flat 1:1 migration will lose the requested item structure. You need to decompose each Freshservice SR into its ServiceNow equivalents and map service item fields to request variables — not generic custom fields. Freshservice's standard ticket export does not include Service Request item fields, so you need API extraction for full-fidelity mapping. (support.freshservice.com)
Audit field override warning
By default, ServiceNow timestamps all imported records with the migration date and assigns "Created By" to the API user. To preserve historical data, you must explicitly map Freshservice's creation dates to ServiceNow's sys_created_on and sys_created_by fields. Your migration account needs the admin role to override these system fields. See the timestamp preservation section below for technical details and a working script example.
Freshservice documents a separate IT Asset Management model for accounts created after
Freshservice documents a separate IT Asset Management model for accounts created after March 31, 2026. Do not assume every Freshservice account has the same asset model when scoping extraction. (support.freshservice.com)
Practical approach
Before migration, export a complete inventory of your Freshservice workflows. Document each trigger, condition, and action. During ServiceNow implementation, use this inventory to decide which workflows become Flow Designer flows, which become Business Rules, and which become Scheduled Jobs. Most organizations find that 30–50% of their legacy workflows are obsolete, redundant, or workarounds for limitations that ServiceNow handles natively — treat this as an audit opportunity.
ServiceNow's own KB article (KB0870503) explicitly states that targeting system fields
ServiceNow's own KB article (KB0870503) explicitly states that targeting system fields like sys_created_on in transform map field maps is "generally not supported." The field mapping UI will not reliably write to system fields. You must use the scripted onBefore approach shown above. Test this thoroughly in a sub-production instance before running on production. The migration account requires the admin role — a scoped application role is insufficient for overriding system fields.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in Freshservice
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated Freshservice → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit -
Create a dedicated migration user
with the admin role and the import_set_loader role
-
Set up Update Sets
to package all migration-related configuration (custom fields, transform maps, staging tables) for promotion from dev → test → prod
Freshservice → ServiceNow specifics
- Tune instance performance
- Increase the glide.db.max_transactions property if needed, and schedule imports during off-peak hours
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the Freshservice export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of Freshservice satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
Freshservice → ServiceNow specifics
- Ticket volume by type
- Total incidents, SRs, problems, and changes — broken down by status (open vs. closed) and age
- Workflow Automator rules
- Count, triggers, and actions for every active workflow
- CMDB CI types and counts
- How many asset types exist, how many CIs per type, and how many relationships are defined
- Knowledge base articles
- Total count, folder structure, and articles with embedded images or attachments
- Integrations
- Any third-party tools connected via API or marketplace apps
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how Freshservice record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the Freshservice → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
-
Create custom fields
(u_source_system, u_source_id, u_source_display_id) on all target tables for source record tracking
-
Configure transform maps
with field mappings, coalesce rules, and onBefore scripts for timestamp preservation
Data Format Converter Reshape the export into the format ServiceNow's importer expects
Freshservice → ServiceNow specifics
- Custom fields per object type
- Freshservice allows custom fields on tickets, assets, changes, and problems. Export the field definitions (name, type, dropdown values) for each
- Priority values
- Freshservice uses 1 (Low) through 4 (Urgent). ServiceNow uses 1 (Critical) through 5 (Planning). The scales are inverted and different in range. A Freshservice priority 4 (Urgent) should map to ServiceNow priority 1 (Critical), and Freshservice priority 1 (Low) should map to ServiceNow priority 4 (Low) or 5 (Planning).
- Status values
- Freshservice ticket statuses (Open = 2, Pending = 3, Resolved = 4, Closed = 5) don't map directly to ServiceNow's incident states (New = 1, In Progress = 2, On Hold = 3, Resolved = 6, Closed = 7). Custom statuses in Freshservice require explicit mapping.
- Impact and Urgency
- Freshservice has separate Impact (1–3) and Urgency fields. ServiceNow uses Impact and Urgency to calculate Priority via a priority lookup matrix. Decide whether to map Freshservice's priority directly or decompose it into ServiceNow's Impact × Urgency calculation.
- Custom field types
- Freshservice dropdown fields need their values mapped to ServiceNow choice list values. Multi-select fields in Freshservice may not have direct equivalents — ServiceNow uses glide_list fields or related list patterns instead.
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to Freshservice. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against Freshservice. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
-
Create Import Set staging tables
for each source entity (tickets, assets, CIs, KB articles, users)
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while Freshservice stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze Freshservice and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep Freshservice read-only as the archive and rollback path.
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile Freshservice and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the Freshservice archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | low | Freshservice incidents map directly to ServiceNow's incident table with straightforward field correspondence, making this the simplest ticket type to migrate. |
| Service Requests | high | Each Freshservice SR must be decomposed into separate sc_request, sc_req_item, and sc_task records with item fields mapped to catalog variables, and standard Freshservice exports omit service request item data entirely. |
| Problems & Changes | medium | These map to dedicated ServiceNow tables but require careful status and priority value mapping since ServiceNow's change management includes risk scoring and CAB workflow fields that have no Freshservice equivalent. |
| CMDB / Configuration Items | high | Freshservice's flat CI model must be mapped to ServiceNow's prescriptive CSDM class hierarchy, and CI relationships cannot be bulk-exported, requiring per-asset API calls that multiply extraction effort dramatically. |
| Hardware Assets | medium | Freshservice unifies assets and CIs, but ServiceNow separates ITAM (alm_hardware) from CMDB, so records must be imported into the asset table only to avoid creating duplicate CI entries, and lifecycle state values require explicit crosswalk mapping. |
| Knowledge Base Articles | high | Inline images stored as Freshservice CDN URLs will break after decommissioning, requiring download, re-upload to sys_attachment, and HTML rewriting, while the category hierarchy and article metadata (views, ratings) have no standard ServiceNow equivalents. |
| Attachments | medium | Each attachment requires a separate API upload call, files over 24 MB will fail without configuration changes, and ticket deletions during migration can create orphaned attachment records. |
| SLA Definitions & History | high | SLA policies must be manually rebuilt in ServiceNow, open tickets mid-SLA require backdated task_sla records, and historical breach data has no native target in ServiceNow's active SLA tracking model. |
| Custom Fields | medium | Freshservice custom fields must be mapped to ServiceNow dictionary entries on the appropriate tables, and service request item-level custom fields must be converted to catalog item variables rather than ticket-level fields. |
| Workflow Automations | high | Freshservice Workflow Automator logic cannot be exported or programmatically converted; each automation must be manually rebuilt in ServiceNow's Flow Designer with different trigger and action paradigms. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Service Request Decomposition
Freshservice stores service requests as unified ticket objects, but ServiceNow splits them across three linked tables (sc_request, sc_req_item, sc_task), requiring each SR to be decomposed and its item fields mapped to catalog request variables rather than generic custom fields.
CMDB Relationship Extraction
Freshservice does not support bulk export of CMDB relationships, forcing per-CI API calls to /api/v2/assets/{id}/relationships to reconstruct the dependency graph before mapping to ServiceNow's cmdb_rel_ci table with an explicit relationship type crosswalk.
Audit Timestamp Preservation
ServiceNow defaults to stamping all imported records with the migration date and the API user as creator, so preserving historical created_on and created_by values requires explicit field overrides using an account with the admin role.
Knowledge Base Image Rewiring
Freshservice stores inline KB images as hosted CDN URLs that will break when the source instance is decommissioned, requiring each image to be downloaded, uploaded to ServiceNow's sys_attachment table, and its HTML img tag rewritten to reference the new sys_id.
API Rate Limit Budgeting
High-volume migrations involving per-CI relationship extraction, individual attachment uploads, and full ticket history export can generate hundreds of thousands of API calls against both Freshservice and ServiceNow rate limits, requiring careful batching and off-peak scheduling.
CSDM Class Mapping Complexity
Freshservice's flat CI types must be mapped to ServiceNow's prescriptive CSDM class hierarchy (e.g., cmdb_ci_business_app vs. cmdb_ci_app), and organizations must decide on a target CSDM maturity phase to avoid over-engineering the initial migration.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can we migrate from Freshservice to ServiceNow without downtime?
Yes. Run the migration in the background while your team works in Freshservice. A delta sync captures changes made during the migration window. Schedule the final cutover for off-hours to minimize disruption.
Will we lose ticket conversation history during migration?
Not if handled correctly. Freshservice conversations must be individually extracted via API and recreated as journal entries (sys_journal_field) in ServiceNow with preserved timestamps and author attribution using scripted transform maps with autoSysFields(false). Standard bulk imports don't handle this.
How do Freshservice API rate limits affect migration speed?
Freshservice enforces account-wide per-minute limits (50–500 req/min by plan). Extracting large datasets takes days at default limits. Approved migration partners can get elevated limits of 700 req/min via a special token for a defined window.
Can Freshservice Workflow Automator rules be automatically converted to ServiceNow Flow Designer?
No. There is no vendor-documented conversion path. Each workflow must be manually analyzed, documented, and rebuilt using ServiceNow's Flow Designer, Business Rules, or Scheduled Jobs depending on the use case.
How long does a Freshservice to ServiceNow migration take?
A mid-market migration (50K tickets, basic CMDB) takes 3–6 weeks end-to-end. Enterprise environments (500K+ tickets, complex CMDB, 50+ workflows) typically take 8–16 weeks, with most time spent on CMDB restructuring and workflow reimplementation.