Zendesk-to-ServiceNow migration requires classifying every flat ticket as an Incident or Service Request, handling API limits on both sides, and redesigning SLAs for ITIL — treat it as a data-model redesign, not a data export.
Zendesk to ServiceNow migration has no native migration path and represents a paradigm shift from a flat, customer-support-oriented ticketing system to a structured, ITIL-driven enterprise platform built on separate tables for Incidents, Service Requests, Changes, and Cases. The fundamental data model difference means every Zendesk ticket must be classified and routed to the correct ServiceNow table based on ITIL process type, rather than mapped field-to-field. Significant custom work is required to build classification logic, rebuild automations as Business Rules or Flows, re-host Knowledge Base assets, map users to ServiceNow's granular role model, and optionally link records to CMDB Configuration Items.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not make ticket → incident your default rule for everything
If you flatten access requests, onboarding asks, equipment orders, and information requests into incidents, you preserve history but break future SLA reporting, catalog fulfillment, and queue ownership.
Do not try to replicate every Zendesk trigger in ServiceNow
Many triggers exist because of Zendesk's limitations. ServiceNow's out-of-the-box ITSM workflows handle most routing and notification scenarios natively. Audit your triggers first, migrate only the ones that map to genuine business logic, and let ServiceNow's OOB features handle the rest.
Do not use a migration as an excuse to map 100% of your Zendesk custom fields into ServiceNow
Audit your instance and drop fields that have not been utilized in the last 12 months.
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 Zendesk
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 Zendesk → 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
Zendesk → ServiceNow specifics
- Mapping Build
- (3–7 days): Build Transform Maps, create custom fields, configure Import Sets, write classification logic. Deploy via Update Sets to sub-production.
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 Zendesk 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 Zendesk 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
Zendesk → ServiceNow specifics
- Sample Extract
- (1–2 days): Extract 500–1,000 representative tickets via API. Validate extraction completeness including comments and attachments.
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 Zendesk 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 Zendesk → 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.
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 Zendesk. 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 Zendesk. 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.
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 Zendesk 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 Zendesk 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 Zendesk read-only as the archive and rollback path.
-
Delete imported records
from ServiceNow using the u_zendesk_ticket_id custom field as the filter. A scripted background job using GlideRecord can bulk-delete by source ID.
-
Define rollback decision criteria upfront
e.g., "If more than 5% of migrated records have incorrect classification or missing comments, we revert to Zendesk and re-migrate."
Zendesk → ServiceNow specifics
- Revert schema changes
- by backing out the Update Set that added custom fields and Business Rules.
- Restore from snapshot
- if your ServiceNow instance supports instance cloning or backup snapshots (available on most ServiceNow plans).
- Maintain Zendesk in read-only mode
- for 2–4 weeks after cutover. Do not decommission immediately.
- Delta Cutover
- (1–2 days): Migrate remaining tickets created since initial sync. Final validation. Go-live.
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 Zendesk 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 Zendesk 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
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
How Map Zendesk Data to ServiceNow
| Zendesk field | ServiceNow field | Notes |
|---|---|---|
| Ticket (break/fix) | Incident | Requires ITIL classification logic |
| Ticket (request) | Requested Item (RITM) | Routed via Service Catalog; requires Service Catalog licensing |
| Ticket (external customer) | Case | If using CSM module; requires CSM entitlement |
| Organization (ITSM) | Company | Map org fields to company fields |
| Organization (CSM) | Account | If using Customer Service Management |
| User (end user) | User | Deduplicate by email |
| User (agent) | User (ITIL role) | Assign itil role; see role mapping section below |
| Ticket comment | Journal entry | Public → Additional Comments, Internal → Work Notes |
| Custom field | Dictionary entry | Create via Table schema |
| Tag | Label / Category | No direct equivalent; use labels or categories |
| Trigger | Business Rule / Flow | Server-side; condition + script |
| Automation | Scheduled Job / Flow | Flow Designer preferred |
| Macro | Template | Pre-fill field values |
| Zendesk Guide article | Knowledge Article | Map sections → categories |
| SLA Policy | SLA Definition | Fundamentally different model |
| Asset (if tracked) | Configuration Item | See CMDB section below |
Role Role(s)
| Zendesk field | ServiceNow field | Notes |
|---|---|---|
| End user | snc_internal or snc_external | Internal employees vs. external contacts |
| Agent | itil | Base ITSM fulfiller role |
| Agent (KB author) | itil + knowledge | If agent wrote Guide articles |
| Agent (catalog manager) | itil + catalog_admin | If managing service catalog items |
| Admin | itil_admin or admin | Scope based on actual admin duties |
| CSM agent | sn_customerservice_agent | If migrating to CSM module |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets (Incidents) | high | Each ticket requires ITIL classification logic to determine if it belongs in the incident, sc_req_item, problem, or case table, and misclassification corrupts ITSM reporting and SLA frameworks. |
| Tickets (Service Requests) | high | Service requests must be routed to the Service Catalog module with proper RITM records and require catalog item definitions and ServiceNow Service Catalog licensing to function correctly. |
| Users and Agents | medium | Users must be deduplicated by email and mapped to ServiceNow's role-based model, with agents receiving appropriate ITIL roles based on function rather than Zendesk labels to avoid security over-provisioning. |
| Organizations | medium | Organizations map to either Companies (core_company) for ITSM or Accounts (customer_account) for CSM, requiring a decision on target module before mapping can begin. |
| Ticket Comments | low | Public and internal comments map cleanly to ServiceNow's Additional Comments and Work Notes journal fields respectively, with straightforward field-level translation. |
| Custom Fields | medium | Custom fields must be recreated as dictionary entries on each target table individually, and fields containing CI-adjacent data need additional mapping to CMDB references. |
| Tags | medium | ServiceNow has no direct tag equivalent, so tags must be converted to labels, categories, or custom field values, and many tags serve as critical inputs to the ITIL classification rules engine. |
| Knowledge Base Articles | high | Articles require structural remapping, bulk inline image re-hosting from Zendesk's CDN, HTML sanitization for ServiceNow's editor, and systematic rewriting of all internal cross-links. |
| SLA Policies | high | Zendesk's SLA model is fundamentally different from ServiceNow's contract_sla definitions, requiring complete reconstruction rather than migration of SLA logic and target configurations. |
| Triggers and Automations | high | There is no automated conversion from Zendesk triggers to ServiceNow Business Rules or Flows, and each must be audited, rebuilt manually, and promoted through the dev-test-prod instance pipeline. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
ITIL Ticket Classification Logic
Every Zendesk ticket must be inspected and conditionally routed to the correct ServiceNow table (Incident, Requested Item, Problem, or CSM Case), requiring a custom rules engine built from ticket types, tags, and group assignments.
Status and State Mapping
Zendesk's flat status model (New, Open, Pending, Solved, Closed) must be translated into different numeric state values depending on whether the target record is an Incident, RITM, or Case in ServiceNow.
Automation and Trigger Rebuild
Zendesk triggers and time-based automations have no automated conversion path and must be manually rebuilt as ServiceNow Business Rules, Flow Designer flows, or Notifications, while filtering out those already handled by OOB ITSM workflows.
Knowledge Base Asset Re-hosting
Zendesk Guide articles contain inline images hosted on Zendesk's CDN and internal cross-links that will break post-migration, requiring bulk image download, re-upload as ServiceNow attachments, and systematic URL rewriting in article HTML.
CMDB Reference Population
Zendesk has no native CMDB, so CI-related data buried in custom fields and tags must be identified, matched to existing ServiceNow Configuration Items, and linked via reference fields on incident and request tables.
Granular Role Provisioning
Zendesk's simple end-user/agent/admin model must be decomposed into ServiceNow's granular role architecture (itil, knowledge, catalog_admin, sn_customerservice_agent, etc.) based on actual job function to avoid over-provisioning.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How long does a Zendesk to ServiceNow migration take?
For most mid-market companies (10K–100K tickets), expect 1–3 weeks including planning, test migration, and go-live. The timeline is driven by ITIL classification decisions and ServiceNow configuration, not the data transfer itself. Companies with clean, consistently tagged data and a pre-configured ServiceNow instance can finish in under a week.
Can I migrate Zendesk attachments and inline images to ServiceNow?
Yes, but not through Zendesk's built-in export — native exports drop attachments and comments. A proper API migration downloads all binaries from Zendesk and uploads them to ServiceNow's sys_attachment table, rewriting inline HTML image links to preserve visual context. This per-file process is the most time-consuming part of the migration.
How do I map Zendesk custom fields to ServiceNow?
Create matching fields on the target ServiceNow table (e.g., incident or sc_req_item) before migration. Zendesk dropdown fields map to ServiceNow choice fields. Text fields map to string fields. Multi-select fields need special handling since ServiceNow does not natively support multi-select on all field types — you may need to convert these to delimited strings or use a related table.
Do I need to rebuild Zendesk SLA policies in ServiceNow?
Yes — this is not a copy-paste operation. Zendesk SLAs are flat, priority-based rules with fixed metrics. ServiceNow SLA Definitions support condition-based start/stop/pause logic, schedule-aware duration calculations, and multi-tier escalation workflows. You need to redesign your SLA framework for ServiceNow's model, not replicate Zendesk's limitations.
Do we have to freeze Zendesk during the migration?
No. A zero-downtime migration involves a historical sync while your team works normally in Zendesk, followed by a final delta sync right before your go-live cutover to catch any tickets created or updated during the transfer window.