Migrate from Experia to Gorgias

Experia Tickets map to Gorgias Tickets as the primary migration object. We map subject, body, status, priority, and channel. Experia's undocumented status model requires a discovery audit to enumerate all active statuses; we map each to either Gorgias Open or Closed (with a pending tag for any Experia status equivalent to waiting-for-customer). Conversation threads migrate as ticket messages in chronological order. Ticket ID from Experia maps to external_id on the Gorgias ticket for reconciliation. Attachment handling requires case-by-case validation based on file size and Gorgias's upload API limits.

Experia Customers map to Gorgias Customers with a direct mapping of contact fields: name, email, phone, language, and timezone. We map Experia's customer notes as Gorgias Customer notes. The Experia customer-type property maps to a Gorgias custom text field customer_type__c if present. Any Experia custom properties on the Customer object are inventoried during discovery and mapped to Gorgias custom fields via the external_id field on the Gorgias CustomField object for foreign-system tracking.

Experia Companies associate multiple customers with a single account. In Gorgias, the equivalent is a Customer record with a company_type flag set via a custom field. We create one Gorgias Customer per Experia Company, then link Experia customer records to it via the parent_customer_id on the Gorgias Customer object. Multi-contact deduplication logic is confirmed with the customer during scoping because the deduplication strategy (by email domain, by explicit company association) depends on how the Experia company data was maintained.

Experia Agent records map to Gorgias User accounts. We resolve agents by email match. Role assignments and group memberships from Experia map to Gorgias User permissions and team assignments. Any Experia agent without a matching Gorgias User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Experia Team structures map to Gorgias Teams for routing and workload distribution. We preserve team names, agent assignments per team, and any routing rule logic that is expressed as team-based ticket assignment in Experia. Routing rules themselves (automated assignment logic) do not migrate; we document the current routing behavior as a written note for the admin to rebuild in Gorgias Rules.

Experia message threads attached to tickets migrate as messages within the corresponding Gorgias Ticket. Each message preserves the sender type (customer, agent, bot), timestamp, body content, and any inline images as separate file references. Message ordering is preserved by setting the message timestamp on insert. This object has high row-count risk for high-volume support teams; we chunk the migration in batches of 500 messages and verify thread integrity after each batch.

Experia custom ticket fields are inventoried during discovery (manual admin panel review required since there is no documented API). Each custom field's data type is mapped to the equivalent Gorgias CustomField type: string maps to text, boolean maps to boolean, date maps to date, number maps to decimal. The Gorgias CustomField external_id field carries the original Experia field name for audit. Fields with picklist-style options are mapped to Gorgias multiselect or select fields depending on single versus multi-select behavior.

Files attached to Experia tickets are migrated as Gorgias files attached to the corresponding ticket. We perform size and format checks before upload; files exceeding Gorgias's upload limits require alternative delivery (file storage link, shared drive) rather than direct attachment migration. The migration report flags any attachments that could not be ported and documents the alternative delivery method used.

Experia tags migrate to Gorgias Tags with the tag taxonomy inventoried during discovery. We preserve tag names and ticket associations. If the Experia tag taxonomy is extensive (more than 200 distinct tags), we discuss tag consolidation strategy with the customer before migration to avoid tag sprawl in Gorgias.

Experia's integrated chatbot and automated inquiry handling rules do not migrate. The chatbot logic is Experia-specific and has no Gorgias equivalent that accepts automated import. We deliver a written inventory of the current chatbot rules (trigger conditions, response logic, escalation paths) as a document for the customer's admin to rebuild using Gorgias's Rules and Macros builder or the Gorgias AI Agent configuration. This is outside data migration scope.

Experia automation rules do not migrate. Rules that assign tickets, send notifications, update statuses, or trigger escalations are Experia-specific and cannot be ported to Gorgias's Rules engine without manual rebuild. We deliver a written inventory of every active Experia rule with its trigger, conditions, actions, and a recommended Gorgias Rules equivalent, and the customer's admin rebuilds them post-migration. Active rules should be disabled in the destination before migration begins per Gorgias migration documentation.

Experia reports and dashboards do not migrate. We deliver a written inventory of current Experia reports (report names, metrics, filters, schedules) for the customer's admin to rebuild in Gorgias's analytics module or in an external BI tool connected via the Gorgias API. Gorgias includes revenue statistics and satisfaction survey reporting in its Pro and Advanced tiers.