Migrate from Xurrent to Zendesk

Xurrent Requests map directly to Zendesk Tickets with subject, description, status, priority, requester, and assignee fields preserved. Custom properties migrate to Zendesk custom ticket fields. Request IDs are stored in a custom field xurrent_request_id__c for cross-reference. Status values are mapped from Xurrent states to Zendesk ticket status workflow during import.

Xurrent Services define the multi-tenant scoping boundary. Zendesk has no direct service catalog scoping. We map each Xurrent Service to a Zendesk Organization (for customer-scoped views) or to a ticket tag prefixed with service_ for filtering. The customer chooses the strategy during scoping. Records without a service assignment default to a xurrent_default_org destination.

Xurrent IMR Incidents map to Zendesk Tickets. The incident_responders, on_call_schedule, and timeline events transfer as custom fields and ticket comments. Note that Zendesk does not natively fire alert routing or escalation workflows on imported records — the responder assignment migrates as data but the escalation automation must be rebuilt in Zendesk Triggers or Macros.

Xurrent Problems link to related Incidents and store root cause analysis. We migrate Problems as Zendesk Tickets with a custom field xurrent_problem_id__c. The problem-incident linkage graph is preserved by linking the Problem ticket to the Incident tickets via xurrent_linked_incidents__c custom field listing the related ticket IDs.

Xurrent Changes carry risk assessment, approval chains, and implementation plans. Approval workflow configuration cannot migrate as automation. We import Change records as Tickets with risk level and change type preserved in custom fields. The approval chain logic is exported as a JSON reference document for the Zendesk admin to rebuild using Zendesk Triggers and Macros.

Knowledge Articles migrate to Zendesk Guide Articles with title, body, author, and status preserved. Article visibility tied to Xurrent Services maps to Zendesk Help Center section permissions or article labels. If the customer uses Zendesk Guide, we create the section hierarchy (up to 5 levels for Enterprise) during migration; otherwise articles migrate as draft content in the Zendesk article API.

SLA policy definitions (response time, resolution time, business hours, priority mapping) are configuration rather than data records. We export them as structured JSON with the policy name, first response time, next update time, resolution time, and applicable schedules. Rebuilding SLA Policies in Zendesk is an admin task using Zendesk's built-in SLA Policy editor, which supports per-entity assignment and business hour calendars.

Escalation policies define multi-step notification sequences with step order, conditions, assignee rules, and channel routing. We export the full escalation chain structure as reference JSON listing each step, its delay, conditions, and target. Rebuilding escalation logic in Zendesk requires Triggers (for automated routing and notifications) and Macros (for standardized response templates) configured by the Zendesk admin.

Playbooks automate incident response steps and link to knowledge articles. The step definitions and conditional logic are structured configuration that does not export as transferable data records. We export the full Playbook JSON (step order, conditions, actions, linked articles) as a reference document and flag it in the migration manifest. The Zendesk admin rebuilds Playbook logic using a combination of Triggers, Macros, and optionally Zendesk's Workflows (on Advanced plans).

On-call schedules define rotation order and coverage windows. The calendar-layer scheduling logic cannot migrate to Zendesk natively. We export schedule configurations as JSON showing rotation sequences, coverage windows, and escalation links. If the customer uses PagerDuty or another scheduling tool, we map the on-call schedule export to that system's schedule import format. Zendesk does not have a native on-call scheduling engine in core Support or Suite.

Custom fields on Xurrent objects (dropdown, text, date, numeric, boolean) map to Zendesk custom ticket fields of equivalent type. Dropdown fields map to Zendesk drop-down ticket fields with options preserved. Multi-select maps to Zendesk tag-based or multi-select fields. Custom field IDs and API names are documented in the field mapping manifest for admin reference during rebuild.

File attachments on Requests, Incidents, Problems, and Knowledge Articles migrate as binary blobs with association to the parent ticket preserved via Zendesk's attachment API. Large attachment volume (over 5,000 files) requires chunked migration with resume capability. We verify attachment integrity by comparing file hash post-import for a random sample of 50 records.

Xurrent Requesters (the person who submitted the request) map to Zendesk End Users. Email address is the dedupe key. Requester organization membership in Xurrent maps to Zendesk Organization membership if the customer uses Zendesk Organizations. Agents (internal users) are provisioned separately as Zendesk Agents by the customer's Zendesk admin before migration, and we reconcile by email match.