Migrate your Kayako data

Conversations are Kayako's primary ticket object. Standard fields include status, priority, assignee, channel, timestamps, and message threads. We migrate Conversations 1:1 using the Conversations API endpoint, preserving thread order and internal/external message flags.

Agents and admins with assigned roles and permissions. User records include name, email, status, and team assignment. We map Users directly to the destination system, handling active/inactive status filtering based on migration scope.

Organization records link multiple Users and Conversations under a single company entity. Contains standard fields like name, domain, and custom properties. We preserve the organization-to-user linkage during migration.

Custom fields exist on Conversations, Users, and Organizations. Each custom field has a unique API field key required for API writes. We discover all custom field keys during scoping and map them to destination properties, handling type differences (dropdown vs. text vs. date) at migration time.

KB articles contain article content, category assignments, status, and view counts. Articles are migratable via the API, but article attachments may require separate handling. We export articles and their metadata, flagging any content that exceeds character limits at the destination.

Articles are organized into hierarchical categories. We preserve the category structure and reparent articles at the destination, handling naming conflicts if the destination already has categories with the same names.

Tags are applied to Conversations for labeling and filtering. We migrate tags as label strings, mapping them to the destination's tagging model (whether that is tags, labels, or a multi-select property).

Conversations can contain file attachments in messages. The API supports file upload and retrieval, but attachment export requires separate API calls per conversation and may have size restrictions. We handle attachments in a secondary pass after primary data migration, with customer sign-off on storage implications.

Automation rules (triggers, conditions, actions) are configuration objects that do not export cleanly via API. The rule logic is not portable between platforms in a structured way. We document automation configurations for manual rebuild at the destination and do not attempt to migrate rule definitions automatically.

Saved reports, CSAT scores, and analytics metrics are computed aggregates, not raw data records. We migrate the underlying data (Conversations, survey responses) so reports can be rebuilt, but the saved report definitions themselves are not migratable.

External integrations with Slack, WhatsApp, voice channels, and third-party tools are configuration objects with OAuth tokens and webhook URLs tied to the source instance. These must be reconfigured manually at the destination with fresh authentication.

SLA definitions (response time, resolution time, business hours) are configuration objects. We capture SLA metadata and map it to the destination's SLA model, as each platform defines SLA tiers differently. Some manual adjustment is expected post-migration.