Migrate from OTRS to Zendesk

OTRS Ticket records map to Zendesk Ticket. We export standard fields (Title, State, Priority, Queue, Owner, CustomerID) and preserve the full article history and attachment references as part of the ticket export pass. The ticket ID from OTRS is stored in a custom field otrs_ticket_id__c for audit reconciliation after migration.

OTRS Article records (emails, notes, external replies) map to Zendesk Ticket Comments. We export article body, content-type, sender information, and create timestamp, then insert each as a Zendesk comment with the correct author (agent or end-user) and visibility (public or internal) determined by the OTRS article communication channel field.

OTRS Customer records (with customer type, contact details, and preferences) map to Zendesk end-users. We evaluate whether each OTRS Customer represents an individual end-user (mapping to a Zendesk User) or an organizational entity (mapping to a Zendesk Organization) during scoping. Customer IDs in ticket records resolve to the correct Zendesk User or Organization at import time.

Dynamic Fields in OTRS are entity-attribute-value rows stored in separate tables. We enumerate every defined Dynamic Field name, type, and current value during scoping and create equivalent Zendesk custom ticket fields before migration begins. Dropdown and multi-select Dynamic Fields generate tags in Zendesk that persist beyond the field lifecycle, which we document for the customer's admin to manage post-migration.

OTRS Queues define ticket routing and access boundaries. We export queue names, assignment rules, and associated group permissions and map them to Zendesk Groups. Access control scoping in OTRS (roles, groups, queues, users) requires translation to Zendesk group membership and permission sets; we produce a mapping matrix during scoping and configure Zendesk Groups before ticket import.

Configuration Items are CMDB entries with a class-based OTRS schema. We export CI data and the CI-to-Ticket linking table (link_delete挂号) as a separate import pass. CIs with high ticket volume are migrated as Zendesk custom object records; CIs with a 1:1 or 1:few ticket relationship are stored as values in a Zendesk custom ticket field. Ticket-to-CI relationships reconstruct via the linking table using the OTRS ticket ID preserved in otrs_ticket_id__c.

OTRS Process Management stores workflow definitions as XML with activity nodes and conditional transition rules. We export the workflow structure and enumerate each activity state, transition condition, and responsible role. These do not migrate as executable code into Zendesk because the process model differs fundamentally. We deliver a written inventory of every Process Management record with its states, conditions, and a recommended Zendesk trigger or SLA policy equivalent for the customer's admin to configure post-migration.

SLA definitions in OTRS link response and solution times to queues and ticket types. We export SLA names, escalation thresholds, and calendar configurations as metadata tags on each ticket record (tagged otrs_sla__c, otrs_first_response_threshold__c, otrs_solution_threshold__c) so the destination can reconstruct urgency levels. SLA enforcement requires Zendesk Enterprise plan; we verify the customer's target plan during discovery.

OTRS Services define available offerings linked to SLAs and queues. We export service definitions and their SLA associations. Services with a catalog intent (requestable offerings) map to Zendesk Ticket Types; services with an SLA linkage map to the SLA metadata tags described above. The customer's use of the OTRS Service Catalog determines whether a Zendesk Guide or a simple Ticket Type configuration is the appropriate destination.

Attachments in OTRS are stored as binary blobs in the database linked to article records. We extract each blob with its original filename and MIME type and re-attach to the corresponding Zendesk comment record during import. Binary extraction requires direct database read access; the SOAP API does not expose attachment blobs efficiently. We coordinate with the customer's DBA to schedule the attachment export pass alongside the main ticket export.