Migrate from Xurrent to Gorgias

Xurrent Requests map 1:1 to Gorgias Tickets with subject, description, status, priority, created_at, and updated_at preserved. The Xurrent requester maps to a Gorgias Customer record; the assignee maps to a Gorgias Agent. We resolve the agent and customer references at migration time by email match. Custom fields on the Xurrent Request transfer to Gorgias Ticket custom fields where types are compatible. High-severity Requests preserve their priority classification via a custom field. Service scoping from Xurrent is handled via the service-to-team mapping step.

Xurrent's Service catalog defines a multi-tenant boundary that controls Request visibility and SLA assignment. Gorgias has no service catalog equivalent. We document the full service hierarchy during scoping, then present two options: (1) map each Xurrent Service to a Gorgias Team and assign all scoped Requests to that Team, or (2) use Tags to replicate service-based categorization without a structural team boundary. For multi-brand MSPs, we recommend separate Gorgias accounts per brand with cross-account tagging as the service boundary analog. This mapping step is high-severity because mis-mapping services leaves teams unable to find their expected tickets.

Xurrent Problems store root cause analysis linked to related Incidents. Gorgias has no separate Problem object. We migrate each Problem as a Ticket with a 'Problem' tag applied, and the root cause description stored in the ticket body. The Problem-Incident linkage graph does not transfer because Gorgias does not support cross-ticket relationship records. The customer chooses whether to include all historical Problems as Tickets or to treat Problems as audit-reference records that are excluded from migration.

Xurrent Knowledge Articles migrate to Gorgias Help Center articles. We preserve title, body content, author, created_at, and updated_at. Xurrent article categories map to Gorgias Help Center sections. Article visibility scoped to specific Services in Xurrent does not have a direct Gorgias analog; we flag articles that were service-restricted so the customer can set appropriate Help Center visibility rules post-migration. Articles linked to Playbooks or Incidents in Xurrent retain their content but lose the workflow linkage.

SLA Policies in Xurrent are configuration records defining response and resolution times tied to priority levels and Services. Gorgias does not have a native SLA management module. We export the SLA policy definitions as a structured reference document listing each policy name, its associated Service, its response and resolution time thresholds by priority, and the business hours definition. The customer maps these to Gorgias Macros or Rules that trigger reminder notifications, or evaluates a third-party SLA tool integrated with Gorgias.

Escalation Policies in Xurrent IMR define multi-step notification sequences: who is notified, via which channel (email, SMS, voice, push), after how long, and with what routing action. Gorgias has no Escalation Policy object. We export the full escalation policy structure including step order, time delays, notification channels, and assignee rules as a reference document. The customer uses Gorgias Rules and Macros to rebuild the notification logic, or retains a separate on-call scheduling tool (PagerDuty, OpsGenie) that pushes notifications into Gorgias.

Playbooks in Xurrent IMR automate incident response steps and link to Knowledge Articles. Playbook step definitions and conditional logic are configuration records that do not export as transferable data. We export the playbook structure (step order, conditions, actions, linked articles, and linked KB references) as a reference document. Gorgias Macros and Rules can replicate individual playbook actions (sending a template reply, assigning to a team, tagging the ticket) but not the conditional branching logic without a workflow rebuild. The rebuild scope is documented per Playbook ID in the migration manifest.

On-Call Schedules in Xurrent IMR define rotation order and coverage windows for responder notification chains. Gorgias has no on-call scheduling capability. We export schedule configurations and rotation sequences as reference data. Teams requiring on-call coverage during and after migration typically implement PagerDuty or OpsGenie as a separate layer, with PagerDuty offering a native Gorgias integration for alert-to-ticket creation. We flag the on-call scheduling gap in the migration manifest so the customer can plan the separate scheduling tool adoption alongside the Gorgias go-live.

Changes in Xurrent carry risk assessment, approval chains, and implementation plan fields tied to the IT change management workflow. Gorgias has no Change object or approval workflow. We migrate Change records as Tickets with a 'Change' tag and preserve risk rating, implementation dates, and the plan description in the ticket body. Approval chain configuration does not transfer and must be rebuilt as a manual process or via a separate change advisory board workflow outside Gorgias. Change dates are preserved as custom fields on the Ticket.

Xurrent IMR Incidents support alert routing, escalation policies, responder assignments, and on-call timeline events that have no Gorgias equivalent. Gorgias Tickets are the closest object but lack alert routing, responder workflow, and escalation chain functionality. We export a manifest of all IMR Incidents with their responder list, on-call schedule references, timeline events, and linked Playbook IDs so the customer can assess which historical incident context to preserve as archived Tickets versus which operational escalation logic to rebuild in a separate tool.

File attachments on Xurrent Requests, Incidents, Problems, and Knowledge Articles migrate as binary blobs with their association to the parent record preserved. We verify file type and size compatibility against Gorgias limits during scoping. Large attachment volume (over 500 MB per ticket on average) may require chunked migration with per-ticket attachment sequencing. Image attachments inline in Knowledge Articles migrate as separate ContentDocument records linked to the article.

Custom fields defined on Xurrent Requests, Services, Problems, and Incidents are exported with their field type, label, and options. We pre-create equivalent custom fields in Gorgias via the API (POST /api/custom-fields with object_type=ticket or customer) and map values during ticket and customer migration. Xurrent custom field types that are not natively supported by Gorgias (such as nested objects or multi-value arrays) are flattened to string fields with the customer choosing the delimiter. Custom field type compatibility review happens during the scoping phase.