Migrate your ThinkOwl data

Cases are the central object in ThinkOwl, wrapping a customer request across email, chat, voice, WhatsApp, and social channels. We migrate Cases with full conversation history, internal notes, status, priority, owner assignment, and SLA timestamps intact. The caseId maps reliably across exports.

Contacts are referenced from within Cases via an embed=customer parameter. We extract Contact records with name, email, phone, company association, and custom contact properties. Linked contact data is migrated independently to prevent orphaned references in target systems.

ThinkOwl uses a cf-prefixed naming convention (cf101000, cf101001, etc.) for custom fields on Cases and Contacts. We map these to destination field names during import scoping and flag any fields with extraction-AI dependencies, since those may carry AI-parsed values that require re-validation.

Time tracking is attached to individual Cases and records which user logged time and for what duration. We migrate time entries as structured child objects of the parent Case. The destination system must support time-entry child objects or we flatten them into custom duration fields.

ThinkOwl stores files via its Fileee module and associates them with cases. We export attachments and re-associate them by filename reference during import. File size limits and MIME-type restrictions are checked against destination platform constraints before migration.

ThinkOwl's no-code workflow builder uses task elements (Service tasks, Call web service steps) with proprietary JSON schemas that are not exportable in portable form. We do not migrate automations; instead we document the workflow logic during discovery so it can be rebuilt in the destination platform.

Drafts are a separate object type in the Case API, used for unsent replies. We migrate draft content as internal notes on the parent Case to preserve the work-in-progress context without creating duplicate open cases in the destination.

ThinkOwl's Business Hours API defines support operating windows used for SLA calculations. We migrate business-hours configurations as structured records. The destination system's SLA engine must be able to ingest or recreate these windows.

Agent records include name, email, role, and team assignment. We map agent identities between ThinkOwl and the destination, handling the case that not all agents will have corresponding user records in the target system. Orphaned agent assignments are flagged for manual resolution.

Teams group agents and define routing rules in ThinkOwl. We preserve team structures and map them to equivalent group or queue objects in the destination. Routing rule logic (which team receives which case type) is documented for re-implementation.

Tags applied to Cases are exported as flat label strings. We migrate tags as-is and map them to the destination's tagging or labeling schema. No semantic translation is applied; tag names must match exactly for filtering to remain valid.

Modules define structured conversation flows in ThinkOwl Conversations. These are JSON-based objects with elements, steps, and conditional logic. We export the module definitions for review, but the structured flow must be recreated in the destination chatbot or IVR platform.