Migrate from Kayako to Gorgias

Kayako Conversations map 1:1 to Gorgias Tickets. The Conversation status (open, pending, resolved, closed) maps to Gorgias Ticket status values. The assignee (User) resolves to a Gorgias Agent by email match. Channel metadata (email, chat, WhatsApp, voice) maps to Gorgias channel. We preserve the full message thread including internal notes as Ticket comments, with public/private visibility flags set appropriately. If the Kayako instance is using Kayako Classic, the conversation schema uses a different primary key format that we normalize before writing to Gorgias.

Kayako Users (agents and admins with roles and team assignments) map to Gorgias Agents. We resolve by email match. If a Kayako User is inactive, we create the Gorgias Agent as inactive so that ticket attribution is preserved but the agent account is not live. Agent role mapping (admin vs agent) is documented during scoping and applied as Gorgias permission settings.

Kayako Organizations (company-level records linking multiple Users and Conversations) map to Gorgias Customers. In Kayako, an Organization has multiple linked Users and multiple Conversations; in Gorgias, the primary Customer record holds the company-level data and additional linked users appear as Customer users under the same parent. We compute the primary Customer from the Organization record and create linked Customer users for the associated Kayako Users, preserving the Organization-to-User linkage for context.

Kayako custom fields exist on Conversations, Users, and Organizations. Each has a system-generated API field key distinct from the display name, and API writes that use the display name silently fail. We discover all custom field keys during scoping via the Kayako API, then create equivalent custom fields in Gorgias (which uses display-name keys with data types boolean, number, or text per the Gorgias developer API). We validate the data type mapping between platforms before writing any field values. Custom fields created after initial setup are re-verified before migration runs.

Kayako KB Articles migrate to Gorgias Help Center articles with article content, author, status (published, draft), and timestamps preserved. Article attachments may require separate file handling and re-upload. The Gorgias Help Center uses a single-level category hierarchy; Kayako Articles with deep nested category paths are flattened to the nearest parent category with a note in the article body describing the original path.

Kayako hierarchical KB Categories migrate to Gorgias Help Center categories. Kayako supports multi-level category nesting (Category > Section > Article); Gorgias uses a single category level. We map the top-level Kayako category to a Gorgias category and preserve the section name as a prefix in the article title or as a tag. Naming conflicts (if the destination already has categories with the same name) are resolved by appending a numeric suffix.

Kayako Tags are string labels applied to Conversations. Gorgias uses string Tags on Tickets. We migrate Tags as plain string values, mapping directly without transformation. If Tags are used for categorization that might map to Gorgias Tags or to a multi-select custom property, the customer chooses the strategy during scoping.

Kayako Conversation attachments (files in messages) migrate to Gorgias Ticket attachments. The Kayako API requires separate per-conversation calls to retrieve attachments and may have size restrictions. We export attachments to temporary cloud storage, then attach them to the corresponding Gorgias Ticket message. Large file attachments may require the customer to re-upload or configure a cloud storage integration at the destination.

Kayako SLA definitions (response time, resolution time, business hours) are configuration objects. We capture SLA metadata during discovery and deliver a written mapping document to the customer, which maps Kayako SLA tiers to Gorgias SLA policies. Each platform defines SLA tiers differently and there is no direct export mechanism; the customer's admin applies the mapping in Gorgias settings post-migration.

Kayako Teams (groupings of Users for routing) map to Gorgias Teams. We preserve the team name and the list of agents assigned to each team. Team-based routing rules that exist in Kayako are documented and delivered as a routing configuration plan for the customer to apply in Gorgias.

Kayako Notes attached to Conversations or Users migrate to Gorgias private Notes on the corresponding Ticket or Customer. Note authorship and timestamps are preserved.

Kayako Automations (trigger-based rules with conditions and multi-step actions) do not export as portable code. We do not migrate Automations as functional records. We deliver a written inventory of every active Kayako Automation with its trigger event, conditions, actions, and a recommended Gorgias Macro equivalent, so the customer's admin can rebuild them. The inventory includes the automation name, type (trigger, condition, action), and any delay or escalation logic.