Migrate from Request Tracker to HubSpot Service Hub

RT Tickets map directly to HubSpot Tickets. We map Subject to hs_ticket_subject, Status to hs_ticket_status, Priority to hs_ticket_priority, and Created to hs_ticket_createdate. RT's custom lifecycle statuses map to HubSpot Pipeline stage values, and each RT Queue becomes a HubSpot Pipeline. The RT ticket ID is preserved in a custom property rt_original_id__c for audit reconciliation.

Each RT Queue maps to a HubSpot Service Hub Pipeline. RT's per-queue custom lifecycle stages (e.g., new, open, stalled, resolved, rejected, or any custom statuses the RT admin defined) map to HubSpot Pipeline stage values. Queue-level SLA configurations and access controls require manual recreation in HubSpot because RT permissions are not exposed in a structured export format.

RT distinguishes Privileged (staff) and Unprivileged (requestor) users. Privileged RT users with login access map to HubSpot Contacts that also serve as agents; Unprivileged RT users map to HubSpot Contacts as requesters. RT name, email, organization, and phone fields map to HubSpot contact properties. Role assignment (AdminCc, Cc, OwnerDelegated) requires reconstruction in HubSpot's sharing and team model post-migration.

RT unlimited Custom Fields of type Select-Box, Freeform text, Date, IP Address, and others map to HubSpot custom ticket properties. We pre-create the equivalent HubSpot properties before ticket migration begins, matching field type where possible (RT Select-Box maps to HubSpot single-select or multi-select; RT Date maps to HubSpot date picker). Queue-scoped RT Custom Fields are mapped to the relevant HubSpot Pipeline so that only tickets in the matching Pipeline expose those properties.

Every RT ticket action — reply, comment, status change, field update — creates a Transaction record ordered by Created date. We export the full transaction log and thread it back into HubSpot as conversation messages: RT reply content becomes a HubSpot customer reply; RT comment content becomes a HubSpot internal note (hs_internal_is_private = true). The chronological order is preserved by setting hs_timestamp to the original RT Created value.

RT stores file attachments as base64-encoded blobs in the Attachments 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's metadata, and attach the resulting file to the HubSpot ticket conversation thread. This extraction step is the highest-risk part of RT migration because blob size and the number of attachment records directly drive extraction timeline.

RT Articles in classes (e.g., General) export via RT::Extension::Import::CSV using the --article-class flag and are mapped to HubSpot knowledge base articles. Article Name maps to hs_article_title, Synopsis to a hubspot internal summary field, and Content to the article body. RT article Custom Fields require pre-creation as HubSpot article custom properties before import. We flag that RT article classes do not map to HubSpot article categories — categories must be manually organized post-import.

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 by querying the GroupMembers table and building a membership list per group. Groups map to HubSpot Teams, and group members map to HubSpot user team membership. RT's RTx::QueueMover-style queue transfer logic does not have a HubSpot equivalent and must be documented for the admin to implement manually.

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 data and preserve the placeholder syntax so notification wording survives as reference documentation. RT Templates cannot be imported into HubSpot because HubSpot email templates use a different token syntax (e.g., {{contact.firstname}} vs RT's [% Ticket.FirstQueue %]). We deliver the full template content as a written reference document for the admin to rebuild in HubSpot's email template editor.

RT stores Estimated-minutes and Worked-minutes natively on each ticket. RT-Extension-TimeTracking adds structured time-entry records with User, Ticket, Time Worked, and Note. We export native ticket time fields to HubSpot custom number properties (rt_estimated_minutes__c, rt_worked_minutes__c). Structured time-entry records from the TimeTracking extension are exported as a separate object and either mapped to HubSpot custom object records or provided as a CSV for manual import depending on the customer's HubSpot tier.

RT Scrips are server-side Perl automation rules triggered by ticket lifecycle events. They are tied to a specific RT instance's codebase and cannot be migrated to a non-RT destination. We deliver a written inventory of every active Scrip including its description, queue scope, template dependency, and condition logic. The inventory document includes recommended HubSpot Workflow equivalents (trigger type, conditions, actions) so the customer's admin has a rebuild guide rather than a blank slate.

RT Assets (from RTx::AssetTracker or the standalone RT Assets extension) catalog configuration items. Asset records export via REST API or database query and map to a HubSpot custom object with equivalent fields. We pre-create the custom object schema in HubSpot including lookup relationships to Contact or Company if applicable before importing asset records.