Migrate from ThinkOwl to HubSpot Service Hub

ThinkOwl Cases map to HubSpot Tickets. The Case ID becomes the external_id on the Ticket for reconciliation. Case status (New, Open, Waiting, Resolved, Closed) maps to HubSpot Ticket status (OPEN, CLOSED, PENDING). Subject maps to Ticket subject. The embedded customer reference resolves to a HubSpot Contact lookup, which must exist before Case migration begins. Open Cases migrate first; resolved Cases migrate second to preserve agent workload history without inflating active ticket counts on day one.

ThinkOwl Contacts map to HubSpot Contacts. We extract name, email, phone, company association, and all contact-level custom properties. The HubSpot Contact must be created before the parent Case migrates so that the Ticket contact_lookup is satisfied at insert time. ThinkOwl contact cf-prefixed properties map to typed HubSpot Contact properties (text, number, date, dropdown) during the field inventory phase.

ThinkOwl company associations on Contacts map to HubSpot Companies. The company domain from ThinkOwl becomes the Company Website field and serves as a dedupe key. If ThinkOwl stores a billing or shipping address on the company record, we migrate it to HubSpot Company address fields. Companies are created before Contact import so that the Company-Contact association is satisfied at Contact insert.

Each message in a ThinkOwl Case conversation thread migrates as a HubSpot Conversation event on the Ticket. Inbound customer messages map to conversation_events of type customer, agent replies map to type agent, and system-generated events (status changes, assignment) map to type activity_note. Timestamp ordering is preserved. Attachments referenced in conversation entries migrate as file attachments linked to the parent Ticket.

ThinkOwl time entries (agent, duration, description) migrate as internal notes on the HubSpot Ticket with a [TIME_ENTRY] prefix and structured body (Agent: X | Duration: Y mins | Description: Z). This preserves the time-tracking audit trail without requiring HubSpot's paid Time Tracking feature, which is only available on Enterprise. The customer can optionally enable HubSpot's native time tracking post-migration and re-enter tracked hours if required for billing.

ThinkOwl Draft records are unsent agent replies stored in a separate Drafts object. Migrating Drafts as open Cases in HubSpot creates duplicate active tickets and potential auto-escalation. We import draft content as internal notes on the parent Ticket with a [ORIGINAL_DRAFT] prefix, preserving the work-in-progress text for agent review without creating duplicate tickets. The agent reviews and either sends as a new reply or discards.

ThinkOwl Agent records (name, email, role, team assignment) map to HubSpot User records. We match by email against the HubSpot destination portal's User table. Any ThinkOwl Agent without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision. HubSpot User must exist before Ticket migration because OwnerId is a required reference on Ticket records.

ThinkOwl Teams group agents and define case routing rules. We map ThinkOwl team structures to HubSpot Teams. Routing rule logic (which team receives which case type) is not migratable as automation; we document the current routing configuration in the workflow inventory deliverable so the admin can rebuild it in HubSpot's ticket assignment automation.

ThinkOwl Tags applied to Cases migrate as HubSpot Tags on the Ticket. Tags are flat label strings with no semantic translation applied. If the customer has used Tags as a de facto category system (e.g., product line, issue type), we recommend converting these to a HubSpot custom property during migration rather than relying on Tags, which have limited filtering capability in HubSpot's reporting engine.

ThinkOwl Business Hours define support operating windows used for SLA calculations. We export the Business Hours configuration (timezone, days, start/end times) and deliver it as a structured configuration record. HubSpot's Business Hours feature is available on Professional and Enterprise tiers. The customer's admin configures Business Hours in HubSpot Settings post-migration based on the exported specification. SLA triggers cannot migrate as automation; they are documented for rebuild in HubSpot's SLA automation.

ThinkOwl assigns custom fields a cf-prefixed system identifier (e.g., cf101000, cf101001) regardless of the admin label. We extract both the display label and the system code during field inventory and create a mapping table. We match by label first, fall back to code matching, and verify the HubSpot field type (text, number, date, dropdown, checkbox) is compatible. If a destination field already exists with a different name, we reconcile by label. Custom fields on Cases become custom properties on Tickets; custom fields on Contacts become custom properties on Contacts.

ThinkOwl stores files via its Fileee module and associates them with Cases. We export attachments and re-associate them by filename reference during HubSpot import. File size limits in HubSpot (10 MB per file on Professional, 25 MB on Enterprise) are verified against ThinkOwl's exported file sizes. Any files exceeding HubSpot's limit are flagged for the customer to host externally and link via URL reference.

ThinkOwl Modules define structured conversation flows in the Conversations module using a JSON-based schema with elements, steps, and conditional logic. HubSpot Service Hub does not have a native conversation flow builder of equivalent function. We export module definitions as structured JSON for the customer's admin to review. Replacement options include HubSpot's visual workflow builder for routing logic, third-party chatbot integrations (Drift, Intercom) connected via HubSpot's integration API, or rebuilding flow logic in HubSpot's Conversations API.

ThinkOwl SLA policies define first response and resolution time targets tied to plan tier or case priority. HubSpot SLA features are available on Professional and Enterprise tiers. We export SLA configurations (name, target type, time window, business hours reference) as structured records. The customer configures SLA policies in HubSpot post-migration using the exported specification. SLA automation (auto-escalation on breach) is not migratable as code and is included in the workflow rebuild inventory.

ThinkOwl Service Plans define support entitlements (SLA tier, included channels, escalation path) attached to customer accounts. HubSpot Service Hub does not have a native Service Plan object. We migrate the plan name as a Contact or Company custom property, and if the customer has multiple plan tiers with different routing or SLA rules, we recommend mapping them to HubSpot Ticket Pipelines or Record Types so that plan-level rules are enforced through ticket assignment and SLA configuration.