Migrate from OpenText Service Manager to Zendesk

OpenText Incidents map to Zendesk Tickets. We set the ticket Type field to 'incident' to preserve the ITSM semantics. Source fields including Incident ID (mapped to a custom field ot_sm_id__c for cross-reference), Priority, Description, Resolution, and Created Date migrate directly. The assignee from OpenText (Analyst) resolves to a Zendesk Agent via email match. Incidents linked to Problems carry the Problem relationship into a custom field ot_problem_id__c on the Zendesk Ticket.

Service Requests from OpenText map to Zendesk Tickets with Type set to 'task' or a custom request type field. The service catalog item name from OpenText becomes the ticket Subject or a custom request_type field. Fulfillment group assignments map to Zendesk Teams. Approval status on the OpenText request migrates to a custom approval_status field on the Zendesk Ticket, with the recommendation to rebuild approval routing in Zendesk's workflow builder post-migration.

Problem records map to Zendesk Tickets with Type set to 'problem' and linked to related Incident Tickets via a custom field ot_incident_refs__c containing a comma-separated list of related Zendesk Ticket IDs. Problem title, description, priority, root cause, and status migrate directly. We flag Problems linked to Change records via a custom field ot_change_id__c so that change context is preserved at the ticket level.

Change records map to Zendesk Tickets with a custom type 'change'. CAB approval status, risk rating, implementation plan, rollback plan, and scheduled start and end dates migrate to custom fields on the Zendesk Ticket. Because Zendesk does not have a native Change Advisory Board approval workflow, we document the approval chain from OpenText for the customer's admin to rebuild using Zendesk's Business Rules or a workflow automation tool.

OpenText Knowledge Articles with publish status Active migrate to Zendesk Guide Articles. Article title, body (HTML/RTF), author, publish date, last modified date, and status transfer directly. Category and folder structure from OpenText maps to Zendesk Guide Sections and Categories. Article-to-CI links do not migrate as native Zendesk Guide references; we document the relationships in a separate lookup table for the admin to re-establish in Zendesk Guide if the articles reference specific CIs in the OpenText knowledge base.

OpenText CIs map to Zendesk Organizations. CI name becomes Organization name, CI class (Hardware, Software, Network, etc.) maps to a custom Organization field ci_class__c, and CI status (Active, Decommissioned, etc.) maps to a custom Organization field ci_status__c. For organizations with complex CI relationship graphs (Parent-Child, Dependency, Impact), we migrate the CI records and deliver a relationship adjacency list as a CSV reference document for the admin to re-implement in a Zendesk Custom Object if relationship tracking is required in Zendesk.

OpenText Users (requesters) map to Zendesk End Users. We match on email address as the dedupe key. Name, email, department, phone, and site/location migrate directly. Role (Requester vs Analyst) maps to a Zendesk Role assignment: Analysts become Agents, Requesters become End Users. Users without email addresses are flagged in a reconciliation report with a recommended email alias or the suggestion to merge with an existing Zendesk End User record.

File attachments on Incidents, Requests, Problems, Changes, and Knowledge Articles are exported as binary blobs and re-uploaded to the corresponding Zendesk Ticket or Article via the Zendesk Attachments API. File name, MIME type, and file size are preserved. Attachments exceeding 50MB are flagged individually because Zendesk's Attachments API has a 50MB per-file limit. We validate attachment re-association by comparing file hash before and after migration.

OpenText SLA rules (response time, resolution time targets by priority and service category) do not have a direct Zendesk import mechanism. We map SLA targets to Zendesk SLA Policies with business hours defined per the OpenText SLA calendar. SLA assignment (which SLA applies to which ticket category) migrates as a mapping configuration documented for the admin to apply in Zendesk Admin > Business Rules > SLA Policies. We recommend configuring Zendesk SLA Policies before the first ticket import so that SLA timers are active from day one.

OpenText Studio-defined custom fields on Incident, Request, Problem, and Change records are extracted with name, data type, and picklist values. We create equivalent Zendesk custom ticket fields (text, integer, decimal, date, dropdown, multi-select, checkbox) in the Zendesk Admin interface before migration. Field display order and section placement are documented separately for the admin to configure in Zendesk's ticket field editor. Custom fields with validation logic (format, range) are noted as requiring equivalent Zendesk validation rules to be added post-migration.

OpenText service catalog items and their fulfillment workflows do not migrate as data. We extract the catalog item names, descriptions, category structure, and associated request type from OpenText. If the destination is on Zendesk Suite Enterprise, we recommend enabling the native Service Catalog and configuring request forms that match the OpenText catalog. For Suite Team or Growth tiers, we map catalog items to Zendesk ticket fields and Topics for categorization. The fulfillment routing logic is documented for manual rebuild.

OpenText workflow definitions, escalation timers, conditional routing rules, and approval chains are stored in a proprietary format that is not accessible as export data. We do not migrate them. We deliver a written workflow inventory during discovery: for each active workflow we document the trigger condition, the record types it applies to, the actions it performs, and the recommended Zendesk equivalent (Triggers, Automations, or Macros). The customer's Zendesk admin or a certified Zendesk partner rebuilds these post-migration.