Migrate from Request Tracker to Zoho Desk

RT Tickets map to Zoho Desk Tickets as the primary migration object. We extract ticket data from RT's tab-delimited spreadsheet export, pre-process it to handle delimiter collisions (RT does not quote fields consistently when content contains commas or newlines), then map Subject, Status, Priority, Requestor, Owner, Queue, Created, and LastUpdated fields to Zoho Desk equivalents. RT's custom lifecycle statuses map to Zoho Desk status values (Open, Pending, On Hold, Resolved, Closed) with a custom field rt_original_status__c preserving the source value for audit. Parent queue assignment resolves to the corresponding Zoho Desk Department.

RT Privileged users (staff with login access) map to Zoho Desk Agents. We export name, email, phone, organization, and disabled status from the RT Users table filtered by UserBoolean1 = 1 (Privileged flag), then map them to Zoho Desk Agent records. Role assignment in Zoho Desk (Agent, Supervisor, Admin) is configured based on RT group membership. Any RT Privileged user without a matching Zoho Desk Agent is placed in a reconciliation queue for the customer's admin to provision before ticket import begins.

RT Unprivileged users (requestors without login access) map to Zoho Desk Contacts. We export from the RT Users table where UserBoolean1 = 0, preserving name, email, phone, and organization. RT does not distinguish between customer contacts and external requestors at the user level, so we map all Unprivileged users to Zoho Desk Contacts. Email becomes the dedupe key during import. RT's Disabled field maps to the Active flag in Zoho Desk (disabled RT users become inactive Contacts).

RT Queues map to Zoho Desk Departments. Each RT Queue carries a Name, Description, SLAs, Lifecycle config, and access control list. We export queue names and their associated permission models, then create Zoho Desk Departments with the corresponding names. RT queue-level SLA configurations map to Zoho Desk SLA policies attached to the Department. The RT queue's Default Reply Address maps to the Zoho Desk department's support email address for email ticketing.

RT Custom Fields of type Select-Box, Freeform text, Date, IP Address, and others map to Zoho Desk Custom Fields with equivalent types (single-line for text, multi-line for freeform, date picker for Date, numeric for IP Address where applicable). RT's queue-scoped CFs map to Department-scoped custom fields in Zoho Desk. We pre-create the Zoho Desk custom field schema before ticket import so that CF values are populated at insert time. Global RT CFs map to Zoho Desk fields available across all departments.

RT Transactions (every status change, reply, comment, field update, and system action on a ticket) map to Zoho Desk Ticket Threads and Comments. We export the full transaction log ordered by Created date, classify each as an inbound message (from requestor), outbound reply (from agent), or internal comment (from agent marked private), and thread them into the destination Zoho Desk Ticket conversation in chronological order. RT's Transaction content and subject fields map to Zoho Desk Thread Content and Thread Type.

RT stores 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 blob, reconstruct the original filename and MIME type, then attach the resulting file to the corresponding Zoho Desk Ticket Thread. Zoho Desk supports attachments up to 50 MB per file; we chunk large RT blob extractions accordingly. Note that Zoho Desk's native Zwitch migration tool explicitly excludes attachments from KB articles, but our migration pipeline includes them for Tickets and Threads.

RT Articles in classes (e.g., General) with Name, Summary, Content, and Custom Fields map to Zoho Desk Knowledge Base Articles. We export Article data as structured JSON or cleaned CSV, handling embedded commas and newlines that commonly break RT::Extension::Import::CSV re-imports. RT Article Synopsis maps to Zoho Desk Article Summary; RT Article Content maps to Article Details. Custom fields on RT Articles map to Zoho Desk Article custom fields. We document which RT Article classes exist so the customer can map them to Zoho Desk Category structure.

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 and map to Zoho Desk Teams. Multiple RT groups may map to a single Zoho Desk Team if the customer's group structure is redundant. RT's AdminCc role on a ticket maps to Zoho Desk's Ticket CC field; Cc maps to the same field with separate entries.

RT Templates define email and notification text used by Scrips. We export Template names and content as text data, preserving token placeholders (such as {$Ticket->Subject}) and conditional logic so notification wording survives the move. Zoho Desk's Email Templates use Zoho's own placeholder syntax ({$ticket.subject}); we do not translate the token syntax during migration. We deliver the RT Template content as a reference document for the customer's admin to re-create in Zoho Desk's Template editor.

RT stores Estimated-minutes and Worked-minutes natively on each ticket, and the RT-Extension-TimeTracking extension adds structured time-entry records with User, Ticket, Time Worked, and Note. We export both native time fields and structured time-entry records and map them to Zoho Desk Time Entries linked to the migrated Ticket. Time Entry fields (Agent, Date, Duration, Note) map directly; we preserve the original timestamps for audit ordering.

RT Assets (a separate RT extension product that catalogs configuration items such as servers, software licenses, and hardware) export via the REST API or database query and map to Zoho Desk Products. Asset Name becomes Product Name; Asset Type maps to Product Category; and any custom fields on the RT Asset record map to Zoho Desk Product custom fields. If the customer uses RT Assets to track customer-facing products for support routing, we configure the Zoho Desk Product-to-Ticket linking during the department configuration phase.

RT Scrips are server-side Perl automation rules triggered by ticket lifecycle events and cannot be meaningfully migrated to non-RT platforms. We do not migrate Scrips as executable code. We deliver a written inventory of every active RT Scrip and Template with its name, description, queue scope, template references, and recommended Zoho Desk Blueprint equivalent so the customer's admin can rebuild the automation logic in Zoho's visual workflow builder.