Migrate from Kayako to Zoho Desk

Kayako Conversations map 1:1 to Zoho Desk Tickets. The conversation status (open, pending, resolved, closed) maps to Zoho Desk Ticket Status values, and priority maps to Priority. Channel metadata (email, chat, phone, WhatsApp) migrates as-is into Zoho Desk's channel field. Assignee resolution uses email match against Zoho Desk Agents. We pull conversation threads including all public replies and internal notes as Ticket Comments, preserving the original timestamp on each comment. Conversations with no assignee are mapped to a Zoho Desk unassigned queue for manual routing post-migration.

Kayako Users (agents and admins with roles) map to Zoho Desk Agents. We resolve each Kayako User by email address against the destination Zoho Desk Agent list. If a matching Agent does not exist at migration time, we create the Agent record with the mapped role (Support Admin, Support Agent, or Agent). Inactive Kayako Users migrate as inactive Zoho Desk Agents so that historical assignment data remains intact without generating open notifications.

Kayako Organizations (company-level entities linking multiple Users and Conversations) map to Zoho Desk Accounts. Organization name becomes the Account name, domain becomes the Website field, and any Organization-level custom fields map to Account custom fields in Zoho Desk. The Organization-to-User linkage is preserved: after migrating Accounts, we attach Contacts to the correct Account via AccountId lookup so that the Zoho Desk multi-contact per Account model mirrors Kayako's organization structure.

Kayako custom fields require their API field key, not display name, for all API writes. During discovery we enumerate every custom field on Conversations, Users, and Organizations with its API field key, data type, and visibility. We then map each to the equivalent Zoho Desk custom field within the target department. Zoho Desk enforces a 230-field ceiling per department across all field types, so multi-department Zoho Desk destinations require coordination to avoid field-name collisions. We pre-create all target custom fields via the Zoho Desk API before the ticket migration phase begins.

Kayako KB articles migrate to Zoho Desk Help Center articles. Article title, content (HTML), status (published, draft), and category assignments carry over. A known limitation: Zoho Desk sets the article creation date to the date of migration rather than preserving Kayako's original created-at timestamp. We flag this explicitly in the migration report. KB article attachments (images, PDFs embedded in article content) migrate as file attachments to the article record where supported; standalone file attachments may require manual re-upload if they exceed Zoho Desk's attachment size limits.

Kayako KB categories migrate as Zoho Desk Help Center categories with hierarchical structure preserved. We map parent-child category relationships to Zoho Desk's section and category model. If the destination Zoho Desk account already has categories with conflicting names, we resolve via a name-mangling strategy and document the mapping for the customer's admin to finalize.

Kayako tags applied to Conversations migrate as Tag records in Zoho Desk linked to the migrated Ticket. Each unique Kayako tag string creates a Zoho Desk Tag record if it does not already exist. Tag-to-ticket linkage is preserved via the Zoho Desk Tag-Ticket association API.

Kayako SLA definitions (response time, resolution time, business hours, violation triggers) are configuration objects. We capture the full SLA definition metadata during discovery and map it to Zoho Desk SLA Plans. The mapping is configuration-based because SLA tiers and violation actions differ between platforms; we document the mapping decisions in the migration inventory and the customer's admin applies them in Zoho Desk's SLA configuration UI post-migration.

Conversation file attachments migrate to Zoho Desk Ticket attachments via the file upload API. Each attachment requires a separate API call per conversation. We export attachments as binary blobs from Kayako, validate file size against Zoho Desk limits (typically 20 MB per file), and write them to the migrated Ticket. Attachments exceeding the limit are flagged for manual re-upload. Inline images embedded in conversation message HTML are preserved as-is if under limit; otherwise we strip the inline reference and flag the attachment as missing.

Kayako automation rules (triggers, conditions, actions, SLAs tied to automations) are configuration objects that do not export cleanly via API. The rule logic, including conditional branching and CRM integration actions, is not portable in a structured format. We do not migrate automations. We deliver a written inventory of every active Kayako automation with its trigger type, conditions, actions, and recommended Zoho Desk equivalent (Blueprint for guided processes, Workflow for ticket updates, or Macro for agent-side templates). The customer's admin rebuilds these post-migration.

Saved reports, CSAT scores, and analytics metric configurations are computed aggregates, not raw data records. We migrate the underlying data (Tickets, survey responses) so that Zoho Desk reports can be rebuilt on top of the migrated dataset. CSAT survey responses migrate as Ticket Satisfaction Ratings where supported. We do not migrate the saved report layout, filter set, or visualization configuration; we document the complete list of Kayako reports with their filter criteria for the admin to recreate in Zoho Desk's report builder.

External integrations with Slack, WhatsApp, voice channels, and third-party tools are configuration objects with OAuth tokens and webhook URLs tied to the source Kayako instance. These cannot be migrated as live credentials. We document each active integration's trigger type, destination endpoint, and configuration parameters so that the customer's admin re-establishes them in Zoho Desk post-migration. Zoho Desk has native Slack and Zoho CRM integration; WhatsApp and voice channels require Zoho Desk's paid voice and messaging add-ons.