Migrate from OTRS to Freshdesk

OTRS Tickets map to Freshdesk Tickets with Title, Status, Priority, Type, and Owner preserved. We extract from the MySQL ticket table using ticket_id as the primary key and join to the article table for thread history. The OTRS ticket_state_id maps to Freshdesk status values (2 = open, 3 = pending, 4 = closed) with a custom field otrs_original_state__c holding the OTRS state name for audit. CreatedAt and UpdatedAt timestamps transfer to Freshdesk created_at and updated_at.

OTRS Articles are the atomic communication unit attached to each Ticket: inbound emails, agent notes, and outbound emails each appear as separate article rows with a communication channel field (email-external, email-internal, phone, web). We extract all articles linked to each ticket_id and write them to Freshdesk as Conversations with type inferred from the OTRS article communication field. Inbound emails become Freshdesk notes (private) or replies (public); outbound emails become Freshdesk outbound_email conversations. The original sender address and content-type (plain text vs HTML) are preserved in custom conversation fields.

OTRS CustomerUser records map to Freshdesk Contacts. The OTRS customer_id becomes the Freshdesk external_id for deduplication. Customer email, first name, last name, phone, and address fields map directly. If OTRS stores companies separately (customer companies), we map those to Freshdesk Companies and link the Contact to the Company via the company_id lookup. We flag duplicate emails at migration time and let the customer's Freshdesk admin decide whether to merge or keep separate Contact records.

OTRS Dynamic Fields are stored as entity-attribute-value rows in separate dynamic_field tables joined to ticket_id. During scoping we enumerate all defined field names, types (Text, Date, Dropdown, Checkbox, Database, MultiSelect), and current values. We create matching Freshdesk Custom Fields at the Ticket level before migration. Dropdown Dynamic Fields map to Freshdesk Dropdown custom fields with the same option list; Checkbox maps to Checkbox; Date maps to Date Picker. Multi-select OTRS fields map to Freshdesk Multi-select. We validate that all OTRS field values fit within Freshdesk's character limits before writing.

Customer-facing Dynamic Fields (those with ObjectType = CustomerUser) map to Freshdesk Contact Custom Fields. We enumerate these separately from ticket-level Dynamic Fields during scoping because Freshdesk enforces separate field creation per object type. If the customer's OTRS instance uses customer company-level Dynamic Fields, those map to Freshdesk Company Custom Fields in the same pass.

OTRS Queues define ticket routing and agent access boundaries. We export queue names and their assignment rules (which groups and roles can access which queues) and map them to Freshdesk Groups. Each OTRS queue becomes a Freshdesk Group with the same name. If OTRS uses nested sub-queues (a queue under a parent queue), we flatten to Group names using a hyphen delimiter unless the customer's Freshdesk plan supports subgroup nesting. Agent-to-group membership is resolved by extracting the queue-user join table from the OTRS database.

OTRS Users and Agents are stored in the users table with separate permission tables linking to roles, groups, and queues. We extract user records (first name, last name, email, valid until date) and resolve agent status by checking the user's membership in any OTRS group. We map active OTRS agents to Freshdesk Agents with the email address as the lookup key. If a Freshdesk agent account does not yet exist for a given OTRS user, we flag it in the reconciliation queue for the customer's Freshdesk admin to provision before record migration begins.

Attachments in OTRS are stored as binary blobs in the article_attachment table linked to article IDs. We extract each blob with its original filename, MIME type, and content_size. During Freshdesk ingestion, each attachment re-attaches to the corresponding Conversation record using the Freshdesk Conversations API attachments endpoint. We preserve the original filename so agents can verify the attachment matches the source record. Maximum file size respects Freshdesk's 25 MB per attachment limit; we flag any oversized blobs during scoping.

OTRS Configuration Items use a class-based CMDB schema (GenericIT, Computer, Network, Software) with key-value pairs stored per CI. We export the CI class, all defined attributes, and the CI-Ticket linking table (cmdb_change_id or similar join). If the customer's Freshdesk plan supports Custom Objects (Pro tier and above), we create a Custom Object matching the OTRS CI class and map CI attributes to Custom Object fields. On Growth and lower tiers without Custom Objects, CIs migrate as Freshdesk Products with a custom field ci_class__c and CI attributes stored in the product description or a JSON custom field.

OTRS stores CI-to-Ticket relationships in a linking table (link_relation or similar depending on OTRS version). We export this table and reconstruct the relationship in Freshdesk by writing the OTRS CI ID into a custom Ticket field (e.g., linked_configuration_item__c) on each affected ticket. If the customer uses the Freshdesk IT Service Management (Freshservice) product alongside Freshdesk, we can map CI-to-Ticket links to Freshservice CIs instead, which requires a separate object mapping pass and is scoped as an add-on engagement.

OTRS SLA definitions link response and solution times to queues and ticket types. We export SLA names, first response time targets, and update time targets as metadata. On Freshdesk Growth (where SLA Policies are not available), we write these as ticket Custom Fields (sla_first_response_hours__c, sla_resolution_hours__c) so agents can see urgency context without a native SLA enforcement engine. On Pro and Enterprise, we configure Freshdesk SLA Policies with matching first-response and next-voice-response targets.

OTRS Process Management stores workflow definitions as XML with activity nodes, transition rules, and conditional branching. These XML workflows cannot be translated to Freshdesk Automations programmatically because the underlying logic models are structurally different. We export the workflow structure and action types for each active process and deliver a written inventory specifying which Freshdesk Automation rule or Freshdesk Omni Flow corresponds to each OTRS process step. The customer's admin rebuilds the automation in Freshdesk using the inventory as a blueprint. This is explicitly out of scope for standard migration pricing.