Migrate from Xurrent to Zoho Desk

Xurrent Requests map 1:1 to Zoho Desk Tickets. Standard fields (subject, description, status, priority, requester, assignee) map directly. Xurrent's Service scope maps to Zoho Desk's Department; we require the customer to confirm whether all Xurrent Services map to one Zoho Desk Department or whether the service catalog should be split across multiple departments. Custom fields on Request migrate to Zoho Desk custom fields on Ticket. Historical Request timestamps (createdAt, updatedAt) are preserved where the Zoho Desk API accepts them; see the 'Created at date' gotcha below.

Xurrent Requesters map to Zoho Desk Contacts. Email address is the dedupe key. We import Contacts before Tickets so that the Contact lookup is satisfied at insert time. If the Xurrent deployment uses Requester organizations (account-level requesters), these map to Zoho Desk Accounts which are created before Contact import. Phone, address, and custom profile fields migrate to their Zoho Desk equivalents.

Xurrent Services map to Zoho Desk Departments as the primary organizational unit. Service hierarchy (parent-child) maps to Zoho Desk department nesting. Each Department controls SLA assignment, agent visibility, and ticket routing on the destination side. We flag any Services that contain cross-Service dependencies and note them in the migration manifest for the customer's admin to resolve in Zoho Desk's department structure. Multi-tenant Xurrent deployments with per-client services map to one Zoho Desk Department per client if the customer's business model requires separation.

Xurrent IMR Incidents migrate to Zoho Desk Tickets with a flag imr_incident__c set to true and the original incident type preserved. IMR-specific fields (responders, alert routing, on-call schedule references) are exported as structured reference data but cannot be recreated in Zoho Desk because Zoho Desk lacks a native incident-response responder workflow engine. The customer's admin maps responder names and escalation chain logic to Zoho Desk Blueprint steps or a third-party on-call integration (PagerDuty, OpsGenie) post-migration.

Xurrent Problems (root cause analysis linked to Incidents) have no direct Zoho Desk equivalent. We migrate the Problem record as a Zoho Desk Ticket with a tag 'problem-record' and the linked Incident IDs preserved in a custom field linked_incident_ids__c. The Problem-Incident linkage graph is exported as a reference CSV so the customer's admin can recreate the relationship using Zoho Desk's linked tickets feature or a tag-based grouping strategy.

Xurrent Changes carry risk assessment, approval chains, and implementation plans. We migrate Change records as Zoho Desk Tickets with a tag 'change-record' and risk level preserved in a custom field. Approval chain logic is configuration and does not transfer as workflow rules. We export the approval sequence (approver name, order, threshold) as a structured reference document for the customer's admin to rebuild in Zoho Desk Blueprint or as a manual checklist process.

Xurrent Knowledge Articles migrate to Zoho Desk Knowledge Base articles with category mapping from Xurrent's article categories to Zoho Desk categories. Article visibility settings tied to Services map to Zoho Desk department-level visibility. We flag any Knowledge Articles attached to Incidents or Changes with a reference to the linked record ID so the customer can update internal links post-migration. Article attachment handling has limitations; see the gotcha on Knowledge Base attachments below.

Xurrent SLA Policies define response and resolution times tied to priority levels and Services. We export SLA policy definitions (priority-to-time mapping, business hours calendar, escalation triggers) as structured reference records. Zoho Desk has native SLA Policy configuration from the Professional tier. We note which SLA policies apply to which Departments on the destination so the customer's admin can configure Zoho Desk SLAs to match the Xurrent definitions. SLA policy logic is configuration, not data, and must be rebuilt in Zoho Desk's SLA setup.

Xurrent Escalation Policies define multi-step notification sequences (who is notified, via which channel, after how long). We export the full escalation policy structure including step order, time delays, condition logic, and assignee rules as a reference document. Zoho Desk's Blueprint tool (Professional tier and above) is the closest equivalent for multi-step process automation. We do not migrate escalation policies as executable rules; we deliver the step-by-step reference so the customer's admin can rebuild them in Blueprint.

Xurrent Playbooks automate incident response steps and link to Knowledge Articles. We export the playbook structure including step definitions, conditional branching, linked articles, and step-to-user assignments as a reference document. Zoho Desk Blueprint is the destination-side equivalent for multi-step process flows. We flag which IMR incidents each playbook applies to and note the knowledge article links so the customer can reconnect articles in Zoho Desk's Knowledge Base post-rebuild.

Xurrent On-Call Schedules define rotation order and coverage windows. We export schedule configurations and rotation sequences as structured reference data. Zoho Desk does not have a native on-call scheduling module. We recommend the customer connect Zoho Desk to Zoho Cliq for team notifications or integrate with a dedicated on-call tool (PagerDuty, OpsGenie) post-migration. The exported schedule reference enables the customer's admin to configure equivalent rotations in the chosen tool.

Custom fields on Xurrent Requests, Services, Incidents, and other objects are supported via Xurrent's extensibility. We map custom field definitions and their values to Zoho Desk custom fields on the corresponding Ticket, Contact, or Department module. Custom field types (dropdown, text, date, numeric, boolean) are matched to Zoho Desk field types during the schema review phase. We flag any Xurrent custom field types that have no direct Zoho Desk equivalent (e.g., nested objects, multi-reference fields) and propose a flattening strategy.

File attachments on Xurrent Requests, Incidents, and Knowledge Articles migrate as binary blobs with their association to the parent record preserved. Large attachment volume may require chunked migration with progress reporting. We flag any attachments exceeding Zoho Desk's file size limits and note them for the customer to address manually or via Zoho WorkDrive integration.

Xurrent Service Dependencies define which services or infrastructure components are related to others for impact analysis. We export the dependency graph data as a reference CSV. Zoho Desk does not have a native service dependency or CMDB module. We recommend Zoho ManageEngine or a dedicated IT asset management tool for this use case post-migration and note the dependency graph so it can be rebuilt in the chosen tool.