Migrate from OpenText ZENworks Service Desk to Intercom

ZSD Incidents map to Intercom Conversations. We extract the ZSD Incident fields (title, description, category, priority, status, assigned technician, affected CI, created date, resolved date) and map them to Intercom Conversation attributes. ZSD Priority maps to an Intercom custom conversation priority attribute (P1-P4 or Critical-High-Medium-Low per the customer's naming convention). ZSD Incident status (New, In Progress, Pending, Resolved, Closed) maps to Intercom Conversation state. The ZSD assigned technician resolves to an Intercom admin or team assignment. Incidents are migrated as historical closed conversations; open Incidents are migrated as open conversations with the same assignee.

ZSD Service Requests follow the same schema as Incidents but use a distinct workflow type. We map Service Requests to Intercom Conversations with a custom conversation attribute request_type set to 'Service Request' to distinguish them from Incidents. Request definitions linked to ZSD Catalog Categories are preserved as a custom attribute catalog_category. Approval workflow status from ZSD is preserved as a custom approval_status attribute. Open Service Requests migrate as open conversations; completed requests migrate as closed conversations with resolution notes preserved.

ZSD Change records (RFCs) with Change Owner, CAB status, Risk/Impact/Urgent flags, and Scheduled Start/End dates have no native Intercom equivalent. We migrate Change records as Intercom Conversations with a custom conversation attribute change_record set to true and populate the following custom fields: change_owner, cab_status, risk_level, scheduled_start, scheduled_end. Change Advisory Board approval notes migrate as internal notes on the Conversation. The customer maps each Change to the relevant Intercom Conversation (typically the related Incident or Service Request) via a change_ticket_id custom field. If no related ticket exists, the Change migrates as a standalone conversation for audit purposes.

ZSD Problem records store root cause analysis and linked Known Error associations. We migrate Problems as Intercom Conversations with a custom attribute problem_record set to true and populate root_cause_description, known_error_reference, and linked_incident_ids. The Problem-Known Error association is preserved as a custom field known_error_id. Problems without a linked Incident are migrated as standalone conversations for audit trail purposes. Intercom does not have a native Problem management module, so the full Problem lifecycle (investigation, known error, workaround) is preserved as conversation metadata.

ZSD Knowledge Articles with title, content, keywords, category, and visibility flags map to Intercom Help Center Articles. HTML content is re-encoded to Intercom's rich-text format (Markdown or the Intercom Article editor format). Embedded images are extracted from ZSD HTML, re-uploaded to Intercom's file storage, and the image URLs are updated in the article body. Keywords and tags migrate as Article labels in Intercom. ZSD article visibility (internal vs. public) maps to Article collection visibility. We flag Knowledge Articles with complex HTML tables, embedded iframes, or broken link references for post-migration review and provide a content diff report so editors can verify article integrity.

ZSD Configuration Items with CI Class (Hardware, Software, Service), Name, Serial Number, Status, and linked owner map to Intercom Customer custom attributes. For CIs with an associated end-user (the Affected User on the linked Incident or Service Request), we attach the CI data as a custom attribute on the corresponding Intercom Customer. For CIs without an associated end-user, we create a placeholder Intercom Customer record to preserve the CI data for asset inventory purposes. CI relationships (parent-child hierarchies) are preserved as custom attributes ci_parent and ci_children (JSON array). The customer specifies during scoping whether all CIs should migrate or only CIs linked to active Incidents or Service Requests.

ZSD User records with login name, email, full name, phone, location, department, and manager hierarchy map to Intercom Contacts. We resolve the Microsoft Entra ID synchronization failures by querying the source Active Directory or Entra ID directly and mapping users by UPN or object GUID, bypassing ZSD's broken import module. Department assignments and manager hierarchy are preserved as custom Contact attributes. ZSD user status (active, inactive, terminated) maps to Intercom Contact unsubscribed status for terminated users. Users linked to Incidents or Service Requests are migrated first so that the Contact-to-Conversation associations are satisfied at migration time.

Attachments stored as file references linked to Incidents, Requests, Changes, or Knowledge Articles migrate as Intercom Conversation Parts (file attachments). We extract file blobs from ZSD's storage volume, validate file type and size against Intercom's limits (25 MB per attachment), and upload to Intercom's file storage. Files are then linked to the corresponding Conversation Part. Large attachment volumes may require chunked upload with retry logic. Attachments on Knowledge Articles are re-linked to the corresponding Article after the article content is migrated.

SLA timers and calendar definitions are stored per ZSD configuration but are not enforceable in Intercom's conversation model without an SLA add-on or third-party integration. We preserve the SLA name, priority mapping, and response/resolution hour targets as custom attributes on the migrated Conversation: sla_name, sla_priority, sla_response_hours, sla_resolution_hours. Actual SLA breach status is not migrated (breach state is ephemeral and tied to ZSD's live timer). Intercom's Advanced plan ($49/seat/mo) includes rule-based SLA management, which the customer can configure post-migration to recreate SLA logic against the migrated sla_priority and sla_response_hours attributes.

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 JSON inventory document. This document lists each ZSD workflow with its trigger conditions, approval sequence, escalation paths, and assigned SLAs. Workflows do not migrate as live Intercom rules because ZSD workflows and Intercom rules are fundamentally different automation models. The inventory document is delivered to the customer's admin team as the blueprint for rebuilding approval logic in Intercom's Rules engine post-migration.