Migrate from Request Tracker to Gorgias

RT Tickets map directly to Gorgias Tickets. We extract Subject, Status, Priority, Requestor email, Owner email, Queue name, Created date, Resolved date, and the full transaction log (replies, comments, field changes, status transitions) from RT's Transactions table. The RT Status values (new, open, stalled, resolved, rejected, deleted) map to Gorgias Status values (open, pending, solved, spam) using a status-mapping table defined during scoping. RT Priority (0-9) maps to Gorgias Priority (low, medium, high, urgent) with the threshold values configurable per the customer's priority scale. External ID on the Gorgias Ticket is set to the RT ticket ID for cross-system reference.

RT's Privileged users (staff with login access) and Unprivileged users (requestors) both map to Gorgias Customers. We extract Name, Email, Phone, Organization, and disabled status from RT's Users table. Inactive or disabled RT users are imported as inactive Gorgias customers. If the customer's RT instance uses a separate requestor table, we reconcile against the Users table to avoid duplicate customer records when a requestor also appears as a Privileged user. External ID is set to the RT user ID for lookup resolution.

RT Queues define organizational silos and ticket routing; each queue has its own name, description, SLA configuration, and access control model. RT queues map to Gorgias Teams. If a single RT queue contains multiple ticket categories that the customer wants siloed in Gorgias (for example, an IT queue that handles both hardware and software requests), we split them into separate Gorgias Teams based on RT Custom Field values, tag patterns, or subject-line keywords defined during scoping. This split requires the customer to confirm the routing logic before migration runs.

RT Custom Fields of type Select-Box, Freeform text, Date, IP Address, and Number map to Gorgias Custom Fields of equivalent type (string, boolean, date, number, select, multi-select). RT's global vs queue-specific scoping maps to Gorgias's global vs per-ticket-field scoping. Multi-select Custom Fields in RT (values stored as a pipe-delimited string in the RT database) map to Gorgias multi-select custom fields. Date Custom Fields in RT (stored as Unix epoch) convert to ISO 8601 strings in Gorgias. We pre-create all Custom Field definitions in the Gorgias admin panel before ticket import begins, because Gorgias Custom Fields must exist before they can be populated during ticket creation.

Custom Field values attached to RT Tickets are resolved via the RT TicketsCustomFieldValues table and inserted into Gorgias Tickets at import time using the Gorgias Tickets API with the custom_field_definitions referenced by their external_id (RT CF ID). Select-box values are mapped by label match; freeform text migrates as-is; date values are epoch-to-ISO converted; IP Address values migrate as string. If a Custom Field option value in RT does not exist in the destination Gorgias Custom Field definition, we create it dynamically during migration to prevent silent data loss.

Every RT ticket action—reply, comment, status change, field update—creates a Transaction record. Replies (which are visible to the requestor) map to Gorgias public Comments; Comments (internal notes) map to Gorgias private Notes. We export the full transaction log ordered by Created date and thread them back into the destination ticket in chronological order, preserving the agent-requestor conversation flow that Gorgias displays in its conversation timeline. The RT transaction author (Creator) maps to the Gorgias Comment author via the User-to-Customer email lookup.

RT attachments are stored as base64-encoded binary blobs in the Attachments table, linked to Transactions by ID. There is no filesystem path. We run a targeted SQL export per ticket's attachment IDs, decode the base64 blob, reconstruct the original filename and MIME type from RT's ContentType and Filename columns, and attach the resulting file to the corresponding Gorgias ticket conversation thread using the Gorgias REST API multipart upload. Attachments without a filename (RT-generated inline content) are named using the transaction ID for traceability. We flag any blob that exceeds 50 MB as a separate large-file ingestion requiring dedicated handling.

RT Articles live in classes (e.g., General) with Name, Summary, Content, and Custom Fields. We export Article data as structured JSON using RT::Extension::Import::CSV with the --article-class flag. Articles map to Gorgias Help Center Articles within a Folder. The RT Article Synopsis maps to the Gorgias Article Title; RT Article Content (which may contain embedded commas and HTML) maps to the Gorgias Article body. Custom Fields on Articles map using the same lookup resolution as ticket Custom Fields. RT Article classes map to Gorgias Folders or Top-level Categories depending on the customer's desired knowledge-base structure.

RT Templates define email and notification text used by Scrips, with token placeholders and conditional logic. We export Template names and content as text data. Templates that represent canned response patterns (without conditional Scrip logic) migrate to Gorgias Macros. Templates that depend on Scrip conditional branching are documented in the rebuild handoff with a note that the branching logic requires rebuilding as a Gorgias Rule. Template token placeholders (e.g., {$Ticket->Subject}) are preserved as plain text in the Macro body; the customer reviews and replaces tokens with Gorgias's liquid-style variable syntax during the post-migration rebuild pass.

RT Group memberships do not export in a single flat file—they are stored in the GroupMembers table with a compound key of GroupId and MemberId. We reconstruct group membership by querying GroupMembers joined to Users, producing a per-user list of group names and roles. RT AdminCc and Cc role assignments on tickets are preserved as Gorgias Ticket Team assignments and CC assignments on the ticket. If a Gorgias Team has no members mapped from an RT Group, we flag it for the customer's admin to populate post-migration.

RT stores Estimated-minutes and Worked-minutes natively on each ticket, and RT-Extension-TimeTracking adds structured time-entry records with User, Ticket, Time Worked, and Note. We export both native RT time fields and TimeTracking extension entries. Native Estimated and Worked minutes migrate to Gorgias Time Logs attached to the relevant ticket, with the original RT timestamp preserved as the log date. RT time-entry notes migrate as the Gorgias Time Log description.

RT Assets catalogs configuration items (servers, software licenses, hardware) linked to Contacts. If the destination Gorgias account uses the Integrations module to connect to a CMDB or ERP system, we map RT Asset external IDs into a Gorgias Custom Field on the linked Customer record for cross-referencing. We do not migrate RT Assets as standalone Gorgias records because Gorgias does not have a native CMDB or Asset Inventory object; the asset linkage is preserved as a reference string or external ID stored on the associated Customer record.

RT Scrips are server-side Perl automation rules triggered by ticket lifecycle events at the queue level. They are code artifacts tied to a specific RT instance's codebase and cannot be meaningfully migrated to Gorgias. We export the full list of Scrips (name, description, stage, condition, action) to a written Scrip Inventory document that the customer's admin uses to rebuild equivalent Rules and Macros in Gorgias. Scrips that use RT::Logger, RT::Extension::SLA, or other community extensions are flagged with the specific extension dependency so the admin knows which Gorgias Rules may require third-party app integrations.