Migrate from Request Tracker to Freshdesk

RT Tickets map directly to Freshdesk Tickets. We extract Subject, Status, Priority, Requestor email, Owner (resolved to Freshdesk agent by email), Queue name, Created date, LastUpdated, and all Custom Field values. Transaction history (replies, comments, status changes, field updates) threads into Freshdesk conversation entries ordered by RT Created date. RT's open/resolved/new/stalled/custom statuses map to Freshdesk ticket statuses, which the customer configures before migration.

RT Queues define organizational silos and ticket routing. Each RT Queue maps to a Freshdesk Group. We preserve the queue name as the group name and queue description as the group description. RT's per-queue SLA and lifecycle configuration does not have a direct Freshdesk equivalent—SLA policies in Freshdesk are org-level, not queue-level—so we flag queue-specific SLA values for mapping to Freshdesk SLA Policies with a note that the customer reconciles SLA scope post-migration.

RT Privileged users (staff with login access) map to Freshdesk Agents. We extract Name, Email, Phone, and disabled status from the RT Users table. Active RT Privileged users become Freshdesk Agents; inactive users become inactive Freshdesk agents with their tickets reassigned to an active agent during migration. Role mapping (Super User, Requestor, Commenter) in RT translates to Freshdesk agent permission levels that we set during provisioning.

RT Unprivileged users (requestors without login) map to Freshdesk Contacts. Email, Name, Phone, and Organization fields transfer directly. RT's User-custom fields attached to requestors become Freshdesk Contact custom fields, pre-created in Freshdesk before migration. If an RT requestor also appears as a Privileged user (rare), we deduplicate by email and create one Contact record with agent status.

RT Custom Fields (Select-Box, Freeform text, Date, IP Address, and others) map to Freshdesk Custom Fields of equivalent type. We pre-create Freshdesk custom fields before migration with matching names and types. RT's global vs queue-specific scoping maps to Freshdesk's ticket-level custom fields; queue-specific RT CFs become ticket-level Freshdesk CFs accessible in the relevant group context. This is configuration, not data migration, and must be completed before ticket import begins.

RT Articles in named Classes (e.g., General) export as structured JSON via RT::Extension::Import::CSV using the --article-class flag. We extract Name, Summary, Content (with embedded comma handling), and Custom Field values. Freshdesk Knowledge Base Articles require manual recreation of the folder and category structure (RT Article Classes map to Freshdesk Categories). Article content migrates as article body text; RT Synopsis becomes the Freshdesk article Summary. Large RT Articles with complex HTML content may require manual formatting review post-migration.

RT stores attachments as base64-encoded blobs in the Attachments database table linked to Transactions by ID. We run a targeted SQL export per ticket's attachment IDs, decode the base64 blob, reconstruct the original filename and MIME type from RT metadata, then re-attach the decoded file to the destination Freshdesk ticket's conversation thread via the Freshdesk Attachments API. Attachment filename and size are preserved; original RT attachment IDs are logged in a migration audit table for reconciliation.

RT Groups (AdminCc, Cc, OwnerDelegated) organize users for queue-level or ticket-level permission grants. RT GroupMembers table exports group membership as a separate dataset that we reconstruct post-migration. Freshdesk uses Teams to organize agents, but ticket-level CC and AdminCc roles do not map natively—these migrate as Freshdesk ticket-level collaborator email addresses or as Notes in the conversation thread for audit trail. Group name and membership list are preserved in the migration audit output.

Every RT ticket action (reply, comment, status change, field update) creates a Transaction record ordered by Created date. We export the full transaction log per ticket and thread it back into Freshdesk as conversation entries: RT reply-type transactions become Freshdesk reply entries visible to the customer; RT comment-type transactions become Freshdesk internal notes. Status change and field update transactions are captured as note entries with the original RT transaction type labeled. Original RT Created timestamps are preserved on all conversation entries.

RT Templates define email and notification text with token placeholders and conditional logic used by Scrips. Templates are text artifacts tied to RT's Perl automation engine and have no direct Freshdesk equivalent. We export Template names and full content as a structured document and deliver it to the customer's admin for recreation as Freshdesk Mailbox Templates or Scenario Automations. This is documentation, not automated migration.