Migrate your Kapture CX data

Tickets are the core object in Kapture CX. Every ticket has a unique ID, source channel, status, priority, assignee, queue, and folder. We migrate tickets 1:1 and preserve custom ticket field values as property mappings in the destination. Thread history including internal notes is migrated as conversation entries.

Contacts map directly to Kapture CX's Customer 360 profile object. Name, email, phone, company, and custom properties migrate cleanly. We deduplicate against the destination using email as the primary key and flag duplicate candidates for customer review.

Kapture CX supports organization-level records linked to contacts. Company name, industry, and address fields map to the destination's account object. Where the destination uses a flat contact model without a separate company object, we flatten company fields into contact custom properties.

Agent records include name, email, role, and team membership. Role names (Admin, Supervisor, Agent) do not always map directly to destination role schemas, so we map permissions at the feature level rather than by name. Team-to-group mapping is preserved separately.

Kapture CX Teams group agents and route tickets. Team structure migrates as a group or queue in the destination. Where the destination does not support a team object, we create a group and attach it to each agent record during migration.

Articles are organized into Categories and support rich text, attachments, and internal/external visibility flags. We export articles as structured records and reassign them to matching destination categories. AI-enabled knowledge bases (Gen-AI Knowledge Base tier) require flagging because auto-suggest configuration does not export.

Canned responses are tied to folders and can be scoped to specific queues or global. We migrate the response body, shortcut trigger, and folder assignment. Language and token-variable handling requires destination-side template review post-migration.

SLA Policies define First Response Time and Resolution Time targets per priority level or queue. We map these to the destination's SLA configuration. Where the destination uses calendar-based SLA windows, we convert Kapture's business-hour definitions accordingly.

Auto-Trigger, Contextual SOP, and automation rules are Kapture-specific constructs. We export trigger conditions and action definitions as structured JSON for review. The destination may require reimplementation of trigger logic rather than direct migration due to differing rule engines.

Every channel message (email, chat, WhatsApp, social, voice transcript) is stored as a conversation entry under a ticket. We preserve the full thread including internal notes and public replies. Attachments are linked by reference and migrated as binary records where supported.

File attachments are stored against tickets and knowledge base articles. We migrate inline images and file attachments up to the destination size limit. Files exceeding the limit are flagged and can be migrated to a separate storage bucket with a link left in the conversation.

Tags are flat labels applied to tickets. We migrate tag names 1:1. Where the destination uses a separate label or category system, we map tag names to the closest available field or create a custom tag property at migration time.

Folders and Queues define ticket organization and routing hierarchy. We preserve the folder-tree structure and map queue assignment rules. Queues that reference agent teams require both objects to be migrated first to maintain referential integrity.

Reports and Analytics dashboards are configuration artifacts built on Kapture CX's internal metrics engine. These do not export as data; they must be rebuilt in the destination. We provide a report-config audit list identifying which metrics each dashboard tracks so teams can prioritize rebuild effort.

Kapture CX allows custom fields on tickets including dropdowns, checkboxes, date fields, and numeric fields. We export field metadata and data values, then create matching custom fields in the destination schema before importing records. Field type compatibility is checked during the mapping phase.