Migrate from OTRS to Zoho Desk

OTRS Tickets map directly to Zoho Desk Tickets. We extract Title, State, Priority, Queue, Owner, CustomerID, and created_at from the OTRS ticket table and map to Ticket Subject, Status, Priority, Department, Agent, Contact, and Created Time in Zoho Desk. OTRS ticket lock state maps to Zoho Desk Locked status. All linked article history (email, note, external reply) is extracted in a single pass with the ticket and re-imported as thread entries. Dynamic Fields on each ticket are enumerated during scoping and mapped to Zoho Desk custom fields per ticket.

OTRS Articles (email, note, internal/external reply) map to Zoho Desk thread entries. We preserve article direction (Incoming, Outgoing, Internal note) using the Zoho Desk Comment type and author mapping. Article content-type (plain text, HTML, multipart) is handled so HTML articles render correctly in Zoho Desk's thread view. Article sender information maps to the Zoho Desk agent or contact author field. Each ticket's full article chain is sequenced by OTRS article creation time so the conversation reads in chronological order.

OTRS Customer user records (customer login accounts with contact details) map to Zoho Desk Contacts. We extract CustomerID, first name, last name, email, phone, and address fields from the customer user table and map them to the corresponding Zoho Desk Contact fields. OTRS customer companies (organizational units linked to customer users) map to Zoho Desk Accounts, and individual customer users are linked to their parent Account via AccountExtId on the Contact record.

OTRS Dynamic Fields are stored as EAV rows in separate tables (dynamic_field, dynamic_field_value) with field type metadata in the dynamic_field table. During scoping we enumerate every defined Dynamic Field by name, type (Text, Date, Dropdown, Checkbox, Multiselect, DateTime), and the object it attaches to (Ticket, Article, Customer). We map each to an equivalent Zoho Desk custom field on the appropriate module, applying type conversion where field types differ. Dropdown Dynamic Fields map to Zoho Desk Picklist fields with the source values as picklist options.

OTRS Configuration Items (CMDB entries with class-based schemas) have no direct Zoho Desk equivalent. We export CI data from the configitem table and the CI-to-Ticket linking table, then map CIs with class type matching standard product data (hardware, software licenses, contracts) to Zoho Desk Products. Complex or custom CI classes that do not map cleanly to Products are exported as a Zoho Desk Custom Object with fields built to match the CI class schema, and the CI-to-Ticket relationship is preserved as a lookup custom field on the ticket.

OTRS Queues define ticket routing, access boundaries, and SLA assignment. We export queue names and assignment rules and map them to Zoho Desk Departments, which are the primary organizational unit for ticket ownership and visibility in Zoho Desk. Queue-based SLA configurations migrate as metadata tags on each ticket and as a reference document for rebuilding SLA rules in Zoho Desk Blueprint. Queue-to-agent assignments map to Department membership for each agent in Zoho Desk.

OTRS Agents (support staff with login credentials) map to Zoho Desk Agents. We extract agent records from the users table with their role, group, and queue assignments and map to Zoho Desk Agent records with department membership and role assignment. Agent email addresses are used as the dedupe key. Any OTRS agent without a matching Zoho Desk user account goes to a reconciliation queue for the customer's admin to provision before ticket import runs.

OTRS SLA definitions link response and solution time targets to queues and ticket types. We export SLA names, response thresholds, and escalation thresholds and store them as custom fields on each migrated ticket (sla_name, first_response_target, resolution_target) so that Zoho Desk SLA rules can be rebuilt against the same data. SLA rules themselves (workflow triggers, escalation actions) are documented as a written handoff for the customer's admin to rebuild in Zoho Desk Blueprint.

OTRS stores attachments as binary blobs linked to articles in the database. We extract each attachment with its filename, MIME type, and parent article ID and re-attach it to the corresponding thread entry in Zoho Desk. The OTRS article-to-attachment relationship is resolved at migration time so attachments land in the correct thread without duplication. Note that Zoho Desk's native Zwitch tool does not migrate KB attachments; our direct extraction approach does not have this limitation.

OTRS Process Management stores workflow definitions as XML with activity nodes and conditional transition rules. These are proprietary to OTRS and cannot be imported into Zoho Desk Blueprint as code. We export the workflow structure, each activity, and all transition rules and deliver them as a written inventory document with diagrams showing the workflow state machine. The customer's Zoho Desk admin uses this document to rebuild equivalent Blueprint flows post-migration.

OTRS Services define available offerings linked to SLAs and queues. We export service names, descriptions, and service-to-SLA associations and map them to Zoho Desk Products (or a custom services module if the customer's service catalog is complex). Service availability rules are documented separately for admin rebuild in Zoho Desk.

OTRS stores report definitions and rendered output in the database. These are proprietary to OTRS and cannot be directly imported into Zoho Desk reporting. We flag the gap and advise the customer to treat report rebuilding as a post-migration task using Zoho Desk's built-in analytics. We export a list of OTRS report names and their filters as a reference for manual rebuild.