Migrate from Request Tracker to Zendesk

RT Tickets map to Zendesk Tickets as the primary record. We preserve Subject, Status, Priority, Queue (mapped to Zendesk Group), Owner (mapped to Agent), Requestor (mapped to End User), Created date, and LastUpdated date. RT's transaction log threads into Zendesk as comments and replies in chronological order using the Comments API endpoint. Priority mapping uses RT's numeric Priority 0-100 scaled to Zendesk's Urgency and Priority fields.

RT Queues define organizational silos for ticket routing. Each RT Queue maps to a Zendesk Group (for agent assignment and queue visibility) plus a Ticket Form (for field layout and required-field configuration). Per-queue custom lifecycle statuses map to Zendesk custom Ticket Status values defined at the form level. If an RT deployment uses fewer queues than the Zendesk plan supports, we consolidate; if it uses more, we recommend a Group structure with nested subgroups.

RT Privileged users (staff with login access) map to Zendesk Agents. Name, email, phone, and organization fields migrate. RT role assignments (Queue-admin, Superuser) map to Zendesk roles (Agent, Admin) where the mapping is straightforward; unusual RT permission combinations that have no Zendesk equivalent are documented for admin reassignment. We resolve agents by email match and hold any unmatched users in a reconciliation queue for the customer's Zendesk admin to provision before record import.

RT Unprivileged users (requestors with no staff login) map to Zendesk End Users. Name and email migrate; Unprivileged users do not have passwords or login credentials in RT, so they are provisioned as end-users with pending invitation status in Zendesk. Organizations from RT's User organizational field map to Zendesk Organizations attached to the end-user record.

RT Custom Fields of types Select-Box, Freeform text, Date, IP Address, and others map to Zendesk Ticket Fields with equivalent types. Select-Box becomes a Dropdown field; multi-value selects map to Zendesk Tag fields if the customer elects tag-based routing. We pre-create Zendesk Ticket Field configurations before migration so that incoming ticket data satisfies field requirements. Queue-specific CFs are scoped to the corresponding Zendesk Ticket Form.

RT Transaction records represent every ticket action: status changes, replies, comments, field updates, and escalations. We export the full transaction log ordered by Created date, classify each by type (Correspond/Replied vs Comment/Internal note), and thread them as Zendesk Comments linked to the parent Ticket. Internal notes from RT map to Zendesk internal comments visible only to agents. Transaction timestamps preserve as comment timestamps for audit continuity.

RT stores file attachments as base64-encoded blobs in the Attachments database table linked to Transactions by ID. We run targeted SQL exports per ticket's attachment IDs, decode the base64 blob, reconstruct the original filename and MIME type, and upload the file to Zendesk via the Attachments API, linking it to the corresponding comment on the destination ticket. Files without original filenames (RT attachment IDs only) receive a generated filename based on the attachment ID for traceability.

RT Articles in named classes (General, FAQ, etc.) map to Zendesk Guide Articles within corresponding Sections and Categories. Article Name becomes Article Title; Synopsis becomes Article Summary; Content migrates as Article Body with HTML preserved. RT Article Custom Fields map to Zendesk Article Field configurations if available on the Guide plan. Note that Zendesk Guide hierarchy (Categories > Sections > Articles) requires Enterprise plan for the full five-level depth; lower plans support two-level hierarchy.

RT Templates define email and notification text used by Scrips, with token placeholders and conditional logic. We export Template names and content as structured text, preserving token syntax. These migrate to Zendesk Macros (automated text templates) with the RT token syntax mapped to Zendesk placeholder syntax ({{ticket.id}} becomes {{ticket.id}}, etc.). Conditional logic requires manual reconstruction in Zendesk Macro conditions.

RT Group membership organizes users for queue-level or ticket-level permission grants (AdminCc, Cc, OwnerDelegated). GroupMembers do not export in a single flat file from RT's tab-delimited export. We reconstruct Group membership by querying the GroupMembers table directly (or from RT's REST API if available) and map it to Zendesk Group membership. User-to-group assignments become Zendesk Group User assignments for agents.

RT native Estimated-minutes and Worked-minutes on tickets map to Zendesk Time Tracking if enabled on the Zendesk plan. RT-Extension-TimeTracking structured time-entry records (User, Ticket, Time Worked, Note) map to Zendesk Ticket Time Entries with agent attribution and description preserved.

RT Assets (via RT-Extension-Assets, a separate product) catalog configuration items (servers, software licenses, hardware). Asset records export via RT REST API or database query and map to Zendesk Custom Objects if the customer uses Zendesk's IT Asset Management or to a generic Custom Object schema. Asset-to-Ticket linkage migrates as a custom object relationship field on the destination ticket.