Migrate from Thena to Gorgias

Thena Request records map directly to Gorgias Ticket. We map Subject to Ticket subject, Description to the initial message body, Source (email, chat, Slack, etc.) to the channel field, and Urgency/Sentiment (if populated) to Gorgias Tags. Status mapping requires sub-status resolution: Thena sub-statuses under Open map to Gorgias Open, sub-statuses under In progress and On hold map to Gorgias Pending, and Closed sub-statuses map to Gorgias Solved or Closed depending on resolution type. We preserve the original Thena status in a custom field then_tag__c for audit and reporting continuity.

Thena Conversation records nested under Requests map to Gorgias Message records attached to the corresponding Ticket. We reconstruct the message thread using GET /rest/v2/requests/{id}/conversations, preserving the order, timestamp, author type (agent or customer), and message body. Internal notes on Thena map to Gorgias internal Message records with the same visibility flag. The Thena reply count field is used to validate that the message count in Gorgias matches the source after migration.

Thena Account records map to Gorgias Customer. HubSpot CRM customers may already have a customer record; we check for duplicate by email domain before inserting. The Account name becomes Customer name, and account-level custom fields map to Customer-level custom fields in Gorgias. Account-to-contact relationships in Thena (if contacts are linked to accounts) map to Gorgias Customer with associated user contacts.

Thena Users (agents and admins) map to Gorgias Agents. We resolve by email match against the Gorgias agent list. Each Thena User role (agent, admin) maps to the corresponding Gorgias agent permission level. Any Thena User referenced on a Request as assignee but not found in the destination agent list goes to a reconciliation queue for the customer's admin to provision before ticket import begins.

Thena Custom Fields (text, dropdown, boolean, number, date) retrieve via GET /rest/v2/custom-fields and map directly to Gorgias Custom Fields created on the Customer or Ticket object depending on field scope. Dropdown fields with option sets in Thena require pre-creation of matching option values in Gorgias before data import. We validate field type compatibility during scoping and flag any unsupported field types (such as relational or nested object fields) for customer review.

Thena sub-statuses are custom-configured per workspace under main statuses (Open, In progress, On hold, Closed). We extract the full sub-status tree during discovery and map each to a Gorgias status value or a tag with a specific naming convention. For workspaces with more than 10 sub-statuses, we recommend tag-based mapping to avoid overloading the Gorgias status dropdown. The mapping table is delivered as part of the migration scope document.

Thena AI-detected sentiment (positive, neutral, negative, mixed) migrates as a Gorgias Tag with a prefix such as ai:sentiment:positive. These fields are generated by Thena's inference pipeline and may be null on older historical tickets; we flag records with null sentiment values during export validation and document the coverage gap. AI-detected urgency (low, medium, high) migrates similarly as tags with an ai:urgency prefix.

Thena Form definitions and submission data migrate into the destination. Form field schemas are mapped to corresponding Customer or Ticket custom fields depending on form purpose. Form submission metadata (submission timestamp, form name) is preserved in a JSON custom field on the linked ticket or customer record. Forms with conditional logic are documented but not reconstructed; the customer rebuilds them in Gorgias if required.

Thena Forms with predefined response templates map to Gorgias Macros. Macro name carries from the Form name, and the template body migrates as the Macro text. Macros are scoped to the ticket object and are available to agents in the reply composer. We document which Forms were used primarily as response templates versus data capture forms during scoping to distinguish this mapping from the customer data mapping.

Thena Workflows are built from Triggers, Conditions, and Actions and do not migrate as code to Gorgias Rules. We export the full workflow configuration as a structured summary document covering trigger type (e.g., request created, status changed), all condition branches, and all resulting actions (status change, assignee change, Slack notification, custom field change). This document serves as the specification for the customer's admin to rebuild automations in Gorgias Rules post-migration.

File attachments on Thena Requests and Conversations download during export and re-upload to Gorgias as Ticket Attachments. We preserve the original filename, content type, and file size. Attachments exceeding 25 MB are flagged for the customer to host externally and link via URL, as Gorgias has a 25 MB attachment limit per message.

Thena Tags on Requests migrate as Gorgias Tags on the corresponding Ticket. Tags are preserved verbatim without transformation. Tags used for AI routing or SLA tracking in Thena are documented separately in the workflow inventory so the customer can implement equivalent Rules in Gorgias. Tag-based reporting continuity is maintained by preserving the exact tag string values.