Migrate from Front to Gorgias

Front Conversations map to Gorgias Tickets on a one-to-one basis. The conversation subject becomes the ticket subject, conversation status (open, snoozed, archived) maps to Gorgias ticket status values, and channel attribution (email, chat, SMS, social) is preserved as a ticket channel field. All message segments within the Front conversation are flattened into the Gorgias ticket message thread in chronological order with author attribution preserved. The Front conversation ID is stored as an external_id field on the Gorgias ticket for audit trail.

Front Contacts map to Gorgias Customers using email as the dedupe key. Name, email address, phone number, company, language, timezone, and external identifiers (Facebook handle, Twitter handle, phone number across channels) migrate as standard and custom Customer fields. If a Front Contact has no email address, we use the contact handle as a fallback identifier and flag it for manual review in Gorgias.

Each Front message segment (a distinct reply or received message within a conversation) becomes a Gorgias Message record attached to the parent Ticket. We preserve the author (agent or customer), the timestamp, the channel source (email, chat, SMS), and the message body. Attachments within message segments migrate as Ticket Attachments linked to the parent Message. Internal notes in Front (visible to teammates only) migrate as internal Gorgias Notes on the ticket.

Front Inboxes (which define channel routing and teammate access) map to Gorgias Views, which are saved filter configurations. A single Front Inbox with multiple channels can generate multiple Gorgias Views (one per channel) if the customer's team structure separates channel handling. We create Views for each active Front Inbox and apply the inbox's teammate permissions as Gorgias User access to the corresponding View. Complex permission inheritance across nested Inboxes requires a pre-migration review of the access matrix.

Front Teammates export by email address and match to Gorgias Users by email. Name, email, and active/inactive status migrate. Front role names (Admin, Member, Guest) map to Gorgias User roles (Admin, Agent, Admin). If a Front Teammate has been deactivated but has assigned conversations, we reassign those conversations to the matched active Gorgias User or a default agent specified during scoping.

Front Channels (email, chat, SMS, social including Facebook and Instagram) map directly to Gorgias channel types. Channel attribution is preserved at the ticket level so agents can filter or route by channel source in Gorgias. Starter-plan Front accounts that used only one channel will have fewer channel types to map; we confirm the full channel history during discovery to avoid missing historical channel data.

Front Tags (applied at conversation level) map to Gorgias Tags as flat string labels. Tag hierarchy and tag-group organization in Front do not carry over as structural relationships in Gorgias; all tags flatten to a single namespace. If the customer's tagging taxonomy relies on hierarchical tag groups (for example, Region > Team > Priority), we recommend a post-migration tagging strategy review to determine whether Gorgias's label system or a custom field taxonomy better serves the use case.

Front custom fields on Conversations (text, number, date, dropdown, boolean) map to Gorgias Ticket custom fields. We create the corresponding custom field in Gorgias with the matching data type before migration. Dropdown fields in Front map to Gorgias dropdown (select) fields with the same option values. Boolean fields migrate directly. If a Front dropdown has an option value not defined in Gorgias, we flag it for pre-migration option creation. Truncation may occur if Gorgias has a character limit lower than Front's field definition.

Front Contact custom properties (company, priority, arrival date, and other structured data) map to Gorgias Customer custom fields using the same type-matching logic as ticket custom fields. We compare the Front field definition against Gorgias's supported custom field types (string, number, date, boolean, select) and surface any incompatible mappings before migration. Contact handles from social channels (Twitter, Facebook) that have no email equivalent migrate as external_id fields.

Front Companies linked to Contacts map to Gorgias Customer organization records. The company name, domain, and custom company fields migrate. In Gorgias, the organization sits on the Customer record; there is no separate Company object, so company-level metadata becomes fields on the primary Customer record associated with that organization.

Front Analytics CSV exports (Messages export, Full events export) contain timestamps in the requesting user's timezone, which may shift reported times if the requesting admin account is in a different timezone than the agents who created conversations. We document the timezone of the export requestor during discovery and apply corrections during import validation. Custom report configurations in Front (saved report views, dashboard layouts) do not migrate; we recommend rebuilding key reports in Gorgias's reporting module post-migration.

Internal notes attached to Front Conversations migrate as Gorgias internal Notes on the corresponding Ticket. Internal notes differ from customer-visible Messages in that they are private to agents and do not trigger customer notifications. We preserve the note text, author, and timestamp. If the note references other Front records (linked conversations, external URLs), we include the reference text but acknowledge that cross-record linking requires manual recreation in Gorgias.

Front Automation Rules (event-condition-action triggers) do not export structurally and cannot be imported into Gorgias as automation code. We document every active Rule during discovery with its trigger conditions, conditions, delay steps, and actions, producing a written specification for the customer's admin to rebuild in Gorgias's rule system. The rebuild effort is scoped separately from the data migration.

Front Workflows are multi-step process automations distinct from simple Rules. They contain branching conditions, time delays, and multi-action sequences that have no structural equivalent in Gorgias. We export Workflow definitions as written documentation (JSON export where available, screen-by-screen description otherwise) and deliver a handoff spec so the customer's admin or a Gorgias implementation partner rebuilds the workflow logic post-migration. Workflow rebuild is out of scope for the standard data migration engagement.