Migrate from Service to Gorgias

The primary case record from your Service platform maps to a Gorgias Ticket. We preserve the original subject line as the Ticket subject, the created-at timestamp as a custom datetime field (since Gorgias sets Created at migration time), and the current status. Source channel metadata (email, chat, phone, social) maps to Gorgias's channel field on each message.

Each message in your Service platform's conversation thread becomes a Gorgias Message record. We set the Message.type to 'email', 'chat', 'note', or 'call' based on the source channel. Public replies from agents and customers populate as standard messages; internal analyst notes map to Messages with privacy=true in Gorgias. The original message timestamp and author are preserved on each record.

Customer records from your Service platform map to Gorgias Customer objects. We match on email address as the primary key. First name, last name, phone, and external_id transfer directly. Company name maps to the Customer's company field. Any CRM-linked order data that your Service platform stores must be recreated via Gorgias's Shopify or commerce integrations post-migration.

Gorgias requires custom fields to be pre-created via the API before data can be written to them. We read every custom field definition from your Service platform during discovery, create matching fields in Gorgias (with the same type: string, boolean, date, number, select, or multi-select), then map field values during the data migration pass. Picklist values on the source are recreated as options in Gorgias's select custom field.

File attachments on Service cases download from source storage and re-upload to Gorgias's file hosting. We preserve the original filename, MIME type, and attach each file to the corresponding Ticket or Message in Gorgias. Inline images embedded in rich-text case descriptions are extracted, downloaded, and re-hosted separately to maintain display fidelity.

Agents from your Service platform are matched to Gorgias Users by email address. Active agents are created as Gorgias Users with the 'agent' role; admins map to the 'admin' role. We flag any source agent with no email match and surface them before migration so you can either invite them to Gorgias first or reassign their open tickets to a fallback owner.

Support team or group names from your Service platform map to Gorgias Teams. We preserve the team name and membership during migration. If a team name conflicts with a pre-existing Gorgias team, we suffix the name with a qualifier from the source system and surface the conflict in the migration plan for your admin to confirm.

Service platform macros do not transfer as data records. We export all macro definitions as JSON (name, body, variable placeholders, and conditions) so your Gorgias admin can rebuild them as Gorgias Macros. The export includes the same variable syntax where we can detect it, reducing rebuild time. Macros are not migrated automatically because the variable substitution syntax differs between platforms.

Workflow rules, trigger conditions, and escalation logic are configuration, not data. We export all rule definitions as a structured JSON file including trigger events, conditions, and actions. Your Gorgias admin can use this as a reference spec when building Gorgias Rules. Any rules tied to custom fields require those fields to be created in Gorgias first (see custom field mapping above).

Gorgias has no native CSAT field on tickets. Satisfaction survey responses from your Service platform are stored as a custom number or select field on the Ticket after migration. The built-in Gorgias Satisfaction Survey feature must be enabled and configured separately post-migration for ongoing collection.

Ticket tags from your Service platform migrate to Gorgias Tags on the matching Ticket. We preserve the tag name exactly. Tags that contain special characters are normalized to Gorgias's tag format (lowercase, hyphenated). Duplicate tag names are deduplicated during import.

Gorgias does not preserve the original source ticket ID natively. We store the original Service ticket ID or case number in a custom field (Source_Ticket_ID__c) on each migrated Ticket. This enables delta-run de-duplication and allows your team to cross-reference the original record during the transition period.