Migrate from ThinkOwl to Gorgias

ThinkOwl Cases are the central object wrapping a customer request across email, chat, voice, WhatsApp, and social channels. We map Cases to Gorgias Tickets using the source Case ID preserved as an external_id for reconciliation. The Case subject becomes the Ticket subject; Case status (New, In Progress, Resolved, Closed) maps to Gorgias Ticket status values which we configure before import. ThinkOwl's multi-channel message thread migrates as a flat chronological message list on the Gorgias Ticket.

ThinkOwl embeds customer data in Cases via the embed=customer parameter. We extract Contact records with name, email, phone, company association, and cf-prefixed custom contact properties before importing them as Gorgias Customers. Email serves as the dedupe key. Any custom contact fields from ThinkOwl map to Gorgias Customer custom fields, with the cf code recorded in the mapping table alongside the display label.

ThinkOwl Agent records include name, email, role, and team assignment. We extract all agents and match them to Gorgias Agents by email address. Agents without a corresponding Gorgias account are flagged for the customer to provision before the production migration phase begins. Role and team assignments are noted for post-migration routing rebuild in Gorgias Macros and Rules.

ThinkOwl Teams define agent grouping and case routing rules. We preserve team names and membership during extraction. In Gorgias, Teams are configured as Groups that control ticket routing. Routing rule logic (which team receives which case type) is documented in the workflow specification delivered to the customer for rebuild in Gorgias Rules, since routing logic is platform-specific and cannot be migrated as code.

ThinkOwl Time Entries attach to individual Cases, recording which agent logged time and for what duration. Gorgias does not have a native time-tracking child object equivalent to ThinkOwl's Time Entry schema. We migrate time entry data as internal notes on the parent Gorgias Ticket, formatted with agent name, duration, and date so the context is preserved. If the customer's workflow requires billable time, they configure a time-tracking integration post-migration.

ThinkOwl maintains a separate Drafts object for unsent replies. Migrating Drafts as open Tickets in Gorgias creates noise and risks auto-escalation. We import draft content as internal Ticket notes with an [ORIGINAL_DRAFT] prefix, preserving the work-in-progress text for agent review without creating duplicate active tickets. The customer's admin decides which drafts to promote to real tickets post-migration.

Tags applied to ThinkOwl Cases are exported as flat label strings. We migrate tags as-is to Gorgias Tags. No semantic translation is applied — tag names must match exactly. We generate a tag inventory during discovery so the customer can audit the tag taxonomy before and after migration and consolidate or rename as needed during the rebuild phase.

ThinkOwl uses cf-prefixed system identifiers (cf101000, cf101001) for custom fields on Cases and Contacts. We extract both the system code and the admin display label during field inventory and create a mapping table. In Gorgias, custom fields use admin-defined labels and optional API names. We map by label match first, fall back to type-match where labels differ, and flag any ThinkOwl custom fields with no Gorgias equivalent for the customer to configure pre-import.

ThinkOwl's Business Hours API defines support operating windows used for SLA calculations. We export business-hours configurations as structured records and map them to Gorgias Business Hours. Both platforms support timezone and schedule definition, but SLA rule logic is platform-specific and must be rebuilt in Gorgias SLA Management post-migration. We deliver a written Business Hours and SLA configuration guide alongside the migration.

ThinkOwl stores files via its Fileee module and associates them with Cases. We export attachments and re-associate them by filename reference during import into Gorgias Tickets. File size limits and MIME-type restrictions vary between platforms — we audit the file inventory during discovery and flag any files that exceed Gorgias limits for manual handoff. Inline images embedded in message bodies migrate with the message.

ThinkOwl Modules define structured conversation flows with elements, steps, and conditional logic in JSON. We export module definitions for review and deliver them as a documentation package. Gorgias's Macros and Rules serve a similar automation function but use a different configuration paradigm. We do not migrate Modules as live Macros — the specification document enables the customer's admin to rebuild conversation templates as Gorgias Macros post-migration.

ThinkOwl's no-code business process builder uses a proprietary JSON schema for task elements, service tasks, and conditional branches with no documented export endpoint. We do not migrate workflow definitions as code. During discovery we document the current workflow logic — routing rules, escalation paths, SLA triggers, and team assignments — and deliver a written workflow specification so the customer can rebuild in Gorgias Macros and Rules. This is one of the primary scope items that increases migration timeline for teams with complex routing.