Migrate from Request Tracker to Salesforce Service Cloud

RT Tickets map to Salesforce Case records as the primary migration unit. Subject, Status, Priority, and OwnerId map directly. RT's Requestor maps to Contact via email lookup on the destination org's Contact table. RT's Created date and LastUpdated date map to Case.CreatedDate and Case.LastModifiedDate. Each RT ticket's linked Queue becomes the destination Case Record Type, which we pre-configure during the schema design phase so that cases land in the correct routing context from the first import.

RT Queues function as organizational silos with independent names, SLA configs, and access controls. Each RT Queue maps to a Salesforce Case Record Type. The customer's Salesforce admin pre-creates Record Types in Service Cloud matching the RT Queue names, and we map RT Queue identifiers to RecordTypeId during import. If the customer runs fewer than five queues, a simpler single-Record-Type approach using a Queue custom field is viable; we make this recommendation during scoping based on queue count and routing complexity.

RT creates a Transaction record for every ticket action: status change, reply, comment, field update, and correspondence. These merge into Salesforce's activity model: RT replies from requestors map to Case.EmailMessages (inbound), RT replies from staff map to Case.EmailMessages (outbound), RT comments map to Task records with IsTask=false and IsVisibleInSelfService=false, and RT status changes map to Task records as milestone entries. We order all transactions by Created date and assign them sequential sequence numbers to preserve the chronological thread in the Case's Activity timeline.

RT stores file attachments as base64-encoded blobs in the Attachments database table linked to Transactions by ID, not as filesystem paths. We run a targeted SQL export per ticket's attachment IDs, decode the blob, reconstruct the original filename and MIME type, then upload the resulting file to Salesforce as a ContentVersion record. We link each ContentVersion to the parent Case via ContentDocumentLink. Attachments over 25 MB require Salesforce's resumable upload API because the standard Bulk API has a 10 MB chunk ceiling per file.

RT Privileged users (staff agents) map to Salesforce User records. We match by email address as the dedupe key. If the destination Salesforce org does not yet have User records provisioned for every RT agent, we hold the User mapping in a reconciliation queue and the customer's Salesforce admin provisions the missing Users before we resume the record import phase.

RT Unprivileged users (requestors) map to Salesforce Contact records. RT's Name, email, phone, and organization fields map directly. RT's Disabled flag maps to Contact.Active__c or a custom flag. If the customer's RT instance uses Organization to group requestors, we create an Account record per Organization and link the Contact to it, replicating the organizational grouping RT uses.

RT unlimited Custom Fields map to Salesforce custom fields on the Case object. Field types translate as follows: RT Select-Box maps to Salesforce Picklist with the same values; RT Freeform text maps to Text or Text Area; RT Date maps to Date; RT IP Address maps to Text (validated). Queue-scoped RT custom fields map to Record-Type-scoped Salesforce fields. We pre-create the destination field schema before any data import and validate the picklist value set against Salesforce's allowed character constraints.

RT Articles live in named classes with Name, Summary, Content, and Custom Fields. We export Article data as structured JSON and map each Article to a Salesforce Knowledge ArticleVersion. The RT Article class maps to a Salesforce Article Type; RT Content maps to the Article's Summary and Body rich-text fields. Salesforce Knowledge must be enabled by an admin with System Administrator rights before migration begins. We flag this pre-requisite at scoping.

RT stores Estimated-minutes and Worked-minutes natively on each Ticket. RT-Extension-TimeTracking adds structured time-entry records (User, Ticket, Time Worked, Note). Estimated-minutes maps to a custom field Estimated_Duration__c on Case. Worked-minutes maps to a custom field Actual_Duration__c on Case. If the customer uses RT's structured time-entry extension at scale, we create a Time_Entry__c custom object with User, Case__c, Duration__c, and Note__c fields to preserve the granular entry records.

RT Groups organize users for queue-level and ticket-level permission grants (AdminCc, Cc, OwnerDelegated). Group membership does not export in a flat file; we reconstruct it from the GroupMembers table using a targeted SQL query. Groups map to Salesforce Groups (public groups for queue access) and PermissionSetAssignment records for scoped access grants. We deliver a Group mapping table as part of the migration workbook.

RT Scrips are server-side Perl code artifacts triggered by ticket lifecycle events. They cannot be meaningfully migrated to Salesforce because Salesforce Flow uses a declarative and configuration-based model rather than Perl execution. We export Scrip names, associated queues, and trigger conditions as a written inventory document with recommended Salesforce Flow equivalents for each. The customer's admin or a Salesforce partner rebuilds them post-migration.

RT Templates define email notification text with token placeholders used by Scrips. We export Template names and content as structured text, preserving placeholder tokens and conditional logic for notification wording. In Salesforce, these become EmailTemplate records (with folder assignment matching the original queue structure). The customer's admin updates token syntax from RT's [Field] format to Salesforce's {!Case.Field} merge field format during the rebuild phase.