Migrate from Request Manager to Gorgias

Request Manager tickets map to Gorgias tickets with subject as ticket subject, description as initial message body, priority as priority level, and status mapped to a Gorgias ticket status. The Request Manager ticket ID is stored as an external_id field in Gorgias for reconciliation. Created_at and updated_at timestamps migrate to Gorgias' created_at and updated_at.

Request Manager requester records map to Gorgias Customer objects. We preserve name, email address, department, and any contact details as Customer fields. If the requester submitted multiple tickets, the Customer record in Gorgias accumulates a conversation history across all linked tickets. Phone, language, and timezone migrate where present in the source schema.

Request Manager approval chain records do not have a direct Gorgias equivalent because Gorgias has no approval workflow feature. We preserve the approval chain as a structured internal note on the ticket: each approval step (approver name, step order, status, timestamp) is added as an internal message in Gorgias so the audit trail is visible to agents without being shown to customers. We flag this mapping in discovery so the customer decides whether approval chain visibility belongs in the ticket record or a separate admin-maintained log.

Request Manager comments and internal notes map to Gorgias messages. We preserve author, timestamp, and body. The visibility flag (private vs public) maps to Gorgias' internal message designation. Public comments appear in the customer-facing thread; internal notes appear only to agents. Author resolution uses email matching against the Gorgias agent roster.

File attachments on Request Manager tickets are extracted with filename, MIME type, and binary content. Upload to Gorgias is handled via the Gorgias API attachment endpoint. Large files are chunked and uploaded with retry logic. We preserve the attachment-to-ticket relationship by linking each uploaded attachment to the corresponding Gorgias ticket by ID.

Request Manager custom fields vary by organization and are extracted during the schema discovery phase. We map each custom field to a Gorgias custom field of matching type (string, number, boolean, date). The destination custom field is created via the Gorgias API before migration begins. Boolean and multi-select custom fields require type validation against Gorgias' supported managed types. This is per-customer work; no two Request Manager migrations have identical custom field maps.

Request Manager status values (Draft, Submitted, Under Review, Approved, Rejected, Closed) map to Gorgias ticket statuses. The mapping is confirmed during scoping because status semantics differ: a Request Manager 'Approved' ticket is resolved, but a Gorgias 'Resolved' ticket may reopen. We map each source status to the closest Gorgias status and document any semantic gaps in the migration scope document.

Request Manager priority values (Low, Medium, High, Critical) migrate to Gorgias priority levels or ticket tags depending on the customer's preference. Priority level migration is straightforward because both platforms use a categorical priority field. We preserve the original priority value as a tag if the destination Gorgias plan does not expose a priority field beyond the default.

Request Manager department assignments on tickets or requester profiles map to Gorgias Teams. We extract the department list during schema discovery, create corresponding Teams in Gorgias via the API, and link each ticket to the matching team. Teams with no matching Gorgias team are held in a reconciliation queue for the customer's admin to resolve before migration resumes.

Request Manager approvers and administrators who are assigned as ticket owners map to Gorgias agents. We resolve by email match against the Gorgias agent roster. Any Request Manager owner without a matching Gorgias agent is placed in a reconciliation queue. The customer provisions missing agents in Gorgias before the migration phase continues.

Request Manager approval history events (status transitions, escalation triggers, timestamps) do not map to a standard Gorgias object. We serialize the approval event log as a structured internal message on the ticket: each event appears as a JSON-formatted internal note visible to agents. This preserves the audit trail without requiring a custom object on the Gorgias side.

Request Manager ticket labels or tags migrate to Gorgias tags. Tags are preserved as-is where the label schema is simple. If Request Manager tags encode complex metadata (e.g., department plus priority plus approval step), we may split them into multiple Gorgias tags or store the composite value in a custom field, depending on what the customer specifies during scoping.