Migrate from Request Tracker to Intercom

RT Tickets map directly to Intercom Conversations. The RT Subject becomes the conversation title, RT Status (new, open, resolved, rejected, etc.) maps to Intercom's open, closed, and snoozed states, and RT Priority maps to a custom conversation priority attribute. RT's Queue field becomes an Intercom Team assignment; if RT has multiple queues, we create multiple Intercom Teams during provisioning. We preserve RT ticket creation and last-updated timestamps as Created_at and Updated_at on the Intercom conversation. Every RT Transaction (reply, comment, status change) becomes an Intercom Conversation Part in chronological order.

RT Queues define organizational silos and ticket routing. Each RT Queue maps to an Intercom Team. We export Queue names, descriptions, and SLA configurations (if RT-Extension-SLA is present) and create corresponding Teams in Intercom during workspace provisioning. RT's per-queue access control lists (who can reply, who can own tickets) do not have a direct Intercom equivalent; we document the ACL structure in the handoff deliverable for the customer to recreate using Intercom's Team and teammate permission settings. Queue-specific custom fields require additional custom attribute creation per queue in Intercom.

RT Privileged users (staff with login access) map to Intercom Users with admin or agent roles. We extract Name, email, phone, and disabled status from the RT Users table. Matching is by email address. Any RT Privileged user without a matching Intercom User is placed in a reconciliation queue for the customer to provision before record import. Role assignment (superuser, staff, or requestor-only in RT) maps to Intercom's admin vs agent vs teammate access levels.

RT Unprivileged users (requestors who submit tickets but do not have staff login) map to Intercom Contacts. RT stores Name, email, organization, and phone for each requestor. We export all distinct requestor addresses from the Tickets table, deduplicate by email, and create Intercom Contacts before importing any Conversations. Requestors without an email address require special handling; we flag these as an exception item during scoping.

RT supports unlimited Custom Fields of types Select-Box, Freeform text, Date, IP Address, and others, scoped globally or to specific queues. We export CF definitions and values and create equivalent custom attributes in Intercom. Global CFs become Intercom custom attributes on the Contact or conversation data object depending on whether the CF applies to users or tickets. Queue-specific CFs require per-queue Team attribute configuration in Intercom. Select-Box CFs with enumerated values map to Intercom dropdown or multiple-choice custom attributes. We document any CF that has no clean Intercom type equivalent as a flag item for scoping review.

RT Articles live in named classes (e.g., General) with Name, Summary, Content, and Custom Fields. We export Articles as structured JSON using RT::Extension::Import::CSV with the --article-class flag and map them to Intercom Help Center Articles. RT Article classes become Intercom Collections, and the Article Name and Summary map to Article title and summary. Content with embedded commas triggers CSV parsing errors; we pre-process with quoting-aware sanitization before import. RT Article custom fields map to Intercom Article attributes.

RT Groups organize users for queue-level or ticket-level permission grants (AdminCc, Cc, OwnerDelegated). Group membership does not export in a single flat file—we reconstruct it from the GroupMembers table. Intercom Teams function differently from RT Groups; Intercom Teams define inbox assignment and agent permissions rather than granular ACL grants. We map RT Groups to Intercom Teams where possible, and document the mapping in the handoff deliverable. Any RT Group that does not map cleanly to an Intercom Team is flagged for manual review.

Every RT ticket action—reply, comment, status change, field update—creates a Transaction record. We export the full transaction log ordered by Created date and replay it as Intercom Conversation Parts. RT reply actions become Intercom part_type=comment from the contact; RT comment actions become internal notes (part_type=note in Intercom); RT status changes and field updates become conversation metadata updates. Attachment references in Transactions are resolved by querying the Attachments table and re-attaching to the corresponding Conversation Part.

RT stores file attachments as base64-encoded blobs inside the Attachments database table linked to Transactions by ID. There is no file system path for RT attachments. We run a targeted SQL export per ticket's attachment IDs, decode the base64 blob, reconstruct the original filename and MIME type, and attach the resulting file to the corresponding Intercom Conversation Part. Large attachment blobs (over 10 MB per file) may require chunked extraction and upload due to RT database query timeouts and Intercom's attachment size limits.

RT stores Estimated-minutes and Worked-minutes natively on each ticket. If RT-Extension-TimeTracking is installed, it adds structured time-entry records with User, Ticket, Time Worked, and Note. We export both native time values and TimeTracking extension entries and map them to custom numeric attributes on the Intercom conversation (rt_time_estimated_minutes, rt_time_worked_minutes). Intercom does not have a native time-tracking object, so these values appear as conversation metadata rather than a native timesheet feature.

RT Templates define email and notification text used by Scrips. We export Template names and content as text data, preserving token placeholders and conditional logic. Intercom has no direct equivalent to RT's server-side Templates, but Intercom Macros serve a similar notification-and-reply purpose. We deliver Template content mapped to suggested Macro actions as part of the handoff inventory, noting that the customer will need to recreate the templates as Macros manually since Intercom's macro model uses a different action schema. Scrip logic (Perl code) does not migrate and is inventoried separately for the admin's rebuild scope.