Migrate from Ticksy to HubSpot Service Hub

Ticksy Private Tickets (visible only to the submitting customer and agents) map directly to HubSpot Tickets. The ticket status, priority, assignee, and creation timestamp migrate. Ticksy's private flag has no native HubSpot equivalent, so we create a custom single-checkbox ticket property called is_public_community_ticket__c, set it to false for Private Tickets, and document this as a post-migration portal permission filter for the customer's admin to apply if community visibility needs to be enforced at the portal level.

Ticksy Public Tickets (community-visible threads) map to HubSpot Tickets with is_public_community_ticket__c set to true. HubSpot's portal permissions can then be configured to show or hide tickets based on this property value. If the customer uses HubSpot's customer portal, we document the required portal permission rule as part of the post-migration handoff.

Ticksy KB articles (title, body, category, publish state, slug, and optional tags) map to HubSpot Help Desk articles. We use HubSpot's pre-built KB importer (documented at knowledge.hubspot.com/knowledge-base/import-knowledge-base-articles) for the bulk article load, which handles article body HTML and publish state natively. Slug mapping requires manual recording because Ticksy and HubSpot use different URL structures. We deliver a redirect map (old KB slug -> new HubSpot article URL) as a CSV artifact for the customer's admin to configure in HubSpot's URL redirects settings.

Ticksy KB categories and subcategories map to HubSpot article folders within the Help Desk knowledge base. Category names normalize to HubSpot folder names, with any exceeding HubSpot's 100-character folder name limit truncated and flagged for manual renaming.

Ticksy text-type custom fields map to HubSpot single-line text properties on Contact (if the field applies to the customer) or Ticket (if the field applies to the ticket). We preserve the field label as the HubSpot property label and normalize the internal name to HubSpot's lowercase-with-hyphens format. Required field flags migrate as HubSpot required property settings, but any HubSpot-required field that would be empty for migrated records is set to optional during migration and flagged for the admin to backfill post-cutover.

Ticksy multiline text fields map to HubSpot multi-line text properties (HubSpot's rich-text or plain-text variant depending on whether the source contained formatting). Multiline content over 2,000 characters is flagged for review because HubSpot property character limits vary by property type.

Ticksy dropdown fields map to HubSpot single-select picklists for single-choice fields and multi-select picklists for multi-choice fields. We extract the dropdown option list definitions separately from ticket records (Ticksy stores list definitions independently), reconstruct them as HubSpot picklist options, and map each ticket record's selected value to the corresponding HubSpot option label. Unrecognized or inactive options are flagged for the customer to clean or map to a default value.

Ticksy agent accounts (name, email, role) map to HubSpot Users. We match by email address. Ticksy role flags (admin vs agent) migrate as a custom user property called ticksy_original_role__c so the customer's HubSpot admin can assign appropriate HubSpot permissions based on the legacy role. Any Ticksy agent without a matching HubSpot User email is held in a reconciliation queue for the admin to provision before record import begins.

Ticksy email piping routes inbound emails to tickets based on defined routing rules and inbound addresses. This configuration is extracted as a structured document noting each routing rule's condition, target inbox, and priority. We do not configure HubSpot inbox routing during migration — this is a manual rebuild task. We deliver the routing document as a written artifact so the customer's admin can configure HubSpot shared inbox rules in Settings > Inboxes after migration.

Each Ticksy ticket's chronological reply thread — including agent and customer messages, author name, timestamp, and privacy setting — migrates as a HubSpot conversation thread entry. Author email resolves to the HubSpot Contact or User record by email match. Customer-side messages from non-agent email addresses create HubSpot Contact records if they do not already exist. Thread ordering is preserved by the migration timestamp applied at insert time.

File attachments on Ticksy tickets are extracted as binary assets and re-attached to the destination HubSpot ticket record. Large file types (over 25 MB per HubSpot's single-file limit) or unsupported formats are flagged for the customer to host externally and link via URL. We document any attachment that exceeds HubSpot's size limit with its original file name and size for the admin to handle post-migration.

Ticksy ticket labels and tags normalize to HubSpot ticket tags. Tags exceeding HubSpot's 50-character limit per tag are truncated and flagged for the admin to rename post-migration. Tags used as a proxy for product categorization (common in Ticksy multi-product setups) are flagged for the admin to consider mapping to HubSpot ticket properties or pipelines instead.

Ticksy's multi-product support (Professional and Business tiers) stores product records linked to tickets for routing and reporting. We extract product names as HubSpot Product records and link them to tickets via a custom ticket property product_name__c if no native product-ticket association exists in the customer's HubSpot tier. If the customer is on a HubSpot tier that supports product associations on tickets, we configure the association during setup.