Migrate from OpenText ZENworks Service Desk to Zendesk

ZENworks Service Desk Incidents map to Zendesk Tickets. The ZSD incident.title maps to Zendesk ticket.subject, incident.description maps to ticket.comment.body, incident.priority maps to Zendesk ticket.priority (urgent/high/medium/low), incident.status maps to a configured Zendesk custom ticket status set, and incident.category maps to Zendesk ticket.tags or a custom field. Assigned technician from ZSD maps to Zendesk ticket.assignee_id. We use Zendesk's Tickets API (POST /api/v2/tickets) with batched requests and exponential backoff on rate limit responses.

ZSD Service Requests follow the same relational schema as Incidents but use the request workflow type. We distinguish them from Incidents in Zendesk using a custom field sd_request_type__c = 'Service Request' so that the customer's admin can configure different SLA policies, routing rules, and views per request type. The original ZSD request definition ID is preserved in sd_original_request_id__c for reconciliation.

ZSD Changes (RFCs) carry Change Owner, CAB status, Risk/Impact/Urgent flags, and Scheduled Start/End fields that have no native Zendesk equivalent. We map Changes to a custom Zendesk object or to Tickets with a custom change_type__c field and structured custom fields for risk, impact, CAB status, and schedule. SLA timers on Changes do not migrate as live timers; they are preserved as metadata fields (sla_target__c, resolution_hours__c) for the customer's admin to configure as Zendesk SLA policies post-migration.

Problem records store root cause analysis, linked Known Errors, and associated Incidents. Zendesk has no native Problem management object. We map Problems to a custom Zendesk object (Problem__c) or to a Ticket with problem_type__c = true and the root_cause__c field carrying the description. The Known Error linkage is preserved as a custom lookup or a tagged relationship for the admin to implement a Problem management workflow in Zendesk post-migration.

ZSD Knowledge Articles with title, HTML content, keywords, category, and visibility flags map to Zendesk Help Center Articles. HTML content is imported into Zendesk's article body via the Help Center Articles API. Embedded image URLs and internal links are flagged for post-migration review as HTML re-encoding may affect rendering. Keywords from ZSD become Zendesk article labels. We flag articles with broken link density above a threshold for targeted editor review after cutover.

ZSD Configuration Items store CI Class (Hardware, Software, Service), Name, Serial Number, Status, and owner. We export CIs with their class hierarchy to a Zendesk custom object (CI__c or Asset__c depending on the Zendesk plan) with custom fields for ci_class__c, serial_number__c, status__c, and owner_id__c. The CI relationship map is preserved as a custom lookup field or as structured metadata for the customer's admin to connect to a CMDB add-on or Zendesk Explore reporting post-migration.

ZSD user records include login name, email, full name, phone, location, department, and manager hierarchy. We bypass ZSD's broken Entra ID import by querying the source Active Directory or Microsoft Entra ID directly and resolving users by UPN or objectGUID. ZSD user records are matched to Zendesk end users by email as the deduplication key. Department and manager hierarchy are preserved as custom fields (dept__c, manager_email__c) on the Zendesk user record since Zendesk does not have a native organizational hierarchy on end users.

Attachments stored as file references linked to Incidents, Requests, Changes, or Knowledge Articles are exported as file blobs alongside their association metadata. We upload each attachment to Zendesk via the Attachments API (POST /api/v2/uploads) and link it to the corresponding ticket or article. Large attachment volumes (over 10,000 files) may require chunked migration with attachment count validation per phase.

Approval chains and multi-step workflows are stored as configuration in ZSD's workflow engine. We export workflow step definitions and approval assignments as structured metadata in a written workflow inventory document. Zendesk does not receive these as live configurations. The customer's Zendesk admin uses the inventory to rebuild equivalent routing, escalation, and approval logic using Zendesk's native Workflows, Business Rules, and any Marketplace automation apps.

SLA timers and calendar definitions from ZSD are preserved as metadata fields on migrated tickets (e.g., sla_response_hours__c, sla_resolution_hours__c, sla_priority__c). Zendesk's SLA Policies are configured post-migration by the customer's admin based on the preserved ZSD SLA mapping document we deliver. Actual SLA breach status is not carried over as it is calculated live by the target platform's SLA engine.