Migrate from OpenText ZENworks Service Desk to Gorgias

ZSD Incidents map directly to Gorgias Tickets. The ZSD Title becomes Ticket Subject, Description becomes the initial Ticket message, Category maps to a Gorgias Tag or Ticket field, Priority maps to Ticket Priority (High, Medium, Low), and Status (New, In Progress, Resolved, Closed) maps to Gorgias Ticket status. We preserve the original ZSD Incident ID as an external ID on the Gorgias Ticket so cross-referencing between systems is possible during parallel operation. ZSD's Assigned Technician maps to the Gorgias Agent via email match against the Agent mapping table.

ZSD Service Requests map to Gorgias Tickets using the same field mapping as Incidents. The ZSD workflow type distinction (Incident vs Service Request) is preserved as a Ticket tag (incident-type or service-request-type) so that the customer's admin can differentiate the origin during the transition period. Linked Catalog Category from ZSD becomes a Gorgias Tag.

ZSD Change records have no direct Gorgias equivalent. We convert each Change to a closed Gorgias Ticket with a tag (planned-change) and a note field carrying the Change Owner, Change Advisory Board status, Risk/Impact ratings, and Scheduled Start/End window. The ZSD Change description becomes the Ticket subject. This preserves the historical record of planned changes without requiring a CI or asset management module in Gorgias that does not exist natively.

ZSD Problem records, which store root cause analysis linked to Known Errors and associated Incidents, map to closed Gorgias Tickets with a tag (problem-record) and a note carrying the root cause description and linked incident references. The Problem-Known Error association is preserved as a tag (known-error) on the ticket. Incidents that were linked to the Problem in ZSD retain a tag referencing the Problem ticket in Gorgias.

Gorgias has no native CI or asset management module. We export ZSD CIs with CI Class (Hardware, Software, Service), Name, Serial Number, Status, and linked owner. For each migrated ticket referencing a CI, we add the CI identifier as a custom Ticket field (ci_reference__c). The customer's admin may also choose to create a custom object or use an external asset tracking integration post-migration; we do not create a standalone CI database in Gorgias as part of the standard migration scope.

ZSD Knowledge Articles map to Gorgias Knowledge Base articles. We preserve title, article body (with HTML content re-encoded for Gorgias' supported format), category, and visibility flags. Articles marked as internal-only in ZSD are created as internal articles in Gorgias. We flag articles with complex embedded tables or broken image references for post-migration review with a content diff report.

ZSD End Users who submitted Incidents and Service Requests map to Gorgias Customers. We map Name, Email, Phone, Department, Location, and Manager hierarchy from ZSD to Gorgias Customer fields. For organizations affected by the ZSD Microsoft Entra ID import failure (ZSD 26.1 and possibly other releases), we query the source Active Directory or Entra ID directly and map users by UPN or object GUID rather than relying on ZSD's broken import module. Deleted or inactive ZSD users are held in a reconciliation queue.

ZSD Technicians map to Gorgias Agents via email match. We export technician records (login name, email, full name, role) and create corresponding Agent records in Gorgias. Agent permissions (Technician vs Administrator in ZSD) map to Gorgias role levels (Agent vs Admin). Any ZSD technician without an email match in the target Gorgias workspace is held for the customer's admin to provision before migration.

ZSD file attachments linked to Incidents, Requests, Changes, or Knowledge Articles migrate as file attachments on the corresponding Gorgias Ticket or Knowledge Base article. We export the file blobs alongside their association metadata. Large attachment volumes may require chunked migration with parent-record resolution to avoid timeout during the Gorgias API ingestion step.

Approval chains and multi-step workflows in ZSD are tightly coupled to ZSD's workflow engine and have no Gorgias equivalent as migrated configurations. We export workflow step definitions and approval assignments as structured metadata in a written inventory document. The customer's admin reviews and rebuilds these as Gorgias rules-based automations or Macro conditions post-migration. SLA timers are preserved as metadata fields (SLA name, priority mapping, response/resolution hour targets) on the migrated Ticket rather than as active SLA configurations, since Gorgias SLA management is plan-dependent.

ZSD SLA timers and calendar definitions are stored per ZSD configuration and are tightly coupled to ZSD's SLA engine. We preserve the SLA name, priority mapping, and response/resolution hour targets as read-only custom fields on the migrated Gorgias Ticket. The actual SLA breach status is not preserved as it is a runtime calculation that would require the ZSD SLA engine. Gorgias SLA enforcement is enabled separately post-migration based on the customer's chosen plan tier.

Post-incident and post-request satisfaction surveys are evaluated by ZSD's built-in survey engine and are tightly coupled to ZSD's survey configuration. These records are not migrated as Gorgias uses a different survey integration model. We flag survey records in the source audit and deliver a reference document listing survey response counts by ticket for the customer's admin to evaluate Gorgias' native satisfaction rating or a third-party survey integration post-migration.