Migrate from CommBox to HubSpot Service Hub

CommBox Conversations (the primary object spanning WhatsApp, email, voice, social, and chat) map to HubSpot Service Hub Tickets. Each CommBox message within a conversation thread maps to a Ticket Communication record in HubSpot. The original channel source (whatsapp, email, voice, social, chat) is preserved as a custom ticket property channel_source__c so agents can see the channel origin without leaving the ticket view. CommBox conversation status (open, pending, resolved, closed) maps to HubSpot Ticket pipeline stage values that we configure during schema setup.

CommBox Customer records (end-user profiles linked to conversations) map directly to HubSpot CRM Contacts. We extract name, email, phone, and any custom properties stored on the customer profile card. Customer identity is preserved through email deduplication at migration time. CommBox may store customer data against a generic contact record without a company association; we flag any orphaned contacts for the customer to attach to a HubSpot Company record post-migration.

CommBox custom fields are tenant-defined key-value pairs attached to customer profiles. HubSpot Service Hub separates custom properties across Contact, Company, and Ticket objects. During discovery we extract every custom field definition from CommBox, then map each to the appropriate HubSpot object and property type (text, number, date, dropdown, checkbox). Fields without a HubSpot equivalent are flagged in the mapping spec for the customer to resolve before migration runs. There is no universal mapping — one organization's CRM_ID custom field may map to HubSpot's contact property while another team's VIP tier maps to a company property.

CommBox agent profiles (name, email, team assignment, role) map to HubSpot CRM Users. We resolve agents by email match against the destination HubSpot portal. Any CommBox agent without a matching HubSpot User is placed in a reconciliation queue for the customer admin to provision before record import resumes, because OwnerId on tickets requires a valid HubSpot User reference.

CommBox Teams group agents for routing and SLA management. We export team structure and map to HubSpot User Groups, which control inbox assignment and shared email routing in HubSpot Service Hub. CommBox's team-based SLA timers transfer as structured metadata but require manual reconfiguration in HubSpot's SLA policies post-migration, since HubSpot's SLA setup is scoped per ticket pipeline and business hours rather than team membership.

CommBox tags applied to conversations export as tag labels and conversation associations. We map tag sets to HubSpot ticket multi-select picklist properties or label-based ticket properties depending on the customer's tag usage. HubSpot does not have a native tag taxonomy; the customer chooses whether to consolidate tags into a single multi-select field or split by tag category during scoping.

File attachments embedded in CommBox conversations are extracted via the CommBox media API and re-associated with the parent HubSpot Ticket as File attachments. We handle both inline media and document attachments, extracting them individually and linking each to the correct ticket record. Large media files (voice recordings, video clips) may require the customer to configure HubSpot file storage limits based on their plan tier.

CommBox knowledge base articles (title, body content, categories, publish status) export as structured data. HubSpot Knowledge Base uses a specific article format with sections, internal notes, article settings, and a different publish workflow. We transfer article content and category structure, but the customer admin formats articles for HubSpot's Knowledge Base editor and republishes them. Media embeds within article bodies may require post-migration adjustment to HubSpot's file hosting approach.

CommBox SLA configurations define response and resolution timers per channel or team. We export SLA definitions as structured metadata including timer values, business hours references, and channel-specific thresholds. HubSpot's SLA policies are scoped per ticket pipeline and use business hours definitions that the customer configures post-migration. The migration delivers the SLA data as a configuration-ready document; we do not create SLA policies in HubSpot automatically because SLA behavior depends on business-hour calendars that must be defined in the destination environment.

CommBox channels (WhatsApp, email, voice, social, chat) are source identifiers attached to each conversation message. HubSpot Service Hub has native support for chat, email, Facebook, and Instagram, but WhatsApp, voice, and other social channels are not native inbox types. We normalize channel identifiers from CommBox and store them as a custom ticket property so the migration preserves the omnichannel picture in HubSpot's ticket view regardless of whether the channel is natively supported in HubSpot's inbox.

CommBox's automation scripts (AutoX, IntentX, AssignX, TransformX) are proprietary platform-native workflow constructs that cannot be exported as standard data. We document every script during discovery with a numbered inventory: trigger type, conditions, actions, and routing logic with annotated screenshots. The output is a Workflow Rebuild Guide mapped to HubSpot Workflows so the customer's admin recreates the logic post-migration. This is documented process work, not data migration — the scripts themselves do not transfer.

CommBox AssignX routing rules assign conversations to agents or teams based on conditions. There is no documented export endpoint for routing rules. We capture screenshots and configuration details of all active routing rules during discovery and deliver them as a Routing Rules Inventory document. The customer rebuilds routing logic in HubSpot's Inbox Rules and Workflows tools post-migration. This is a manual-rebuild task, not an automated data transfer.