Migrate from Support.com Cloud to HubSpot Service Hub

Support.com Cloud Customer records map to HubSpot Contacts. We extract the primary contact name, email address, phone number, and any linked device identifiers. Device identifiers that cannot map to a native HubSpot field become a custom Contact property (e.g., device_id__c) stored on the Contact record. Customer status (active/inactive) maps to the HubSpot Contact property hubspot_owner_id context; inactive customers are migrated as Contacts without an assigned owner to avoid orphaning.

Support.com Cloud Tickets map to HubSpot Tickets. We transfer ticket subject, description, status, priority, category, created date, updated date, and assigned agent. The Support.com Cloud ticket owner resolves to a HubSpot User by email match; unresolved owners are placed in a reconciliation queue. Custom ticket fields (per-instance schema) are discovered during scoping and mapped to HubSpot custom ticket properties of matching type (text, number, date, dropdown). Ticket status values from Support.com Cloud are normalized to HubSpot Ticket statuses (Open, Pending, Solved, Closed) during the transform phase.

Support.com Cloud Agent profiles (name, email, role, team assignment) map to HubSpot Users. We resolve each agent by email address as the dedupe key. Role-based access controls in Support.com Cloud (admin, agent, supervisor) do not map 1:1 to HubSpot roles; we assign the closest HubSpot role (Super Admin, Agent, or Sales) and flag any gaps in the role mapping inventory for the customer to review. Agents without a destination HubSpot User are held in the queue for admin provisioning before ticket import begins.

Support.com Cloud instances that use a separate Company object for B2B accounts map to HubSpot Companies. Not all Support.com Cloud deployments have this object enabled; we confirm its presence during discovery. We transfer company name, domain, address, and any linked custom fields. HubSpot Companies are created before Customer import so that the Company-to-Contact association is satisfied at the moment of Contact insert.

Support.com Cloud Macros (canned response templates and workflow actions) are exported as content and recreated in HubSpot as Snippets. Macro trigger logic does not map to HubSpot's automation model; we document the trigger condition (e.g., ticket category equals X) and the recommended HubSpot Workflow equivalent. The Snippet content itself migrates as rich text.

Ticket attachments migrate to HubSpot Files linked to the parent Ticket record. We normalize UTF-8 filenames before upload to handle special characters in Support.com Cloud's legacy file storage. Files exceeding HubSpot's 250 MB per-file limit are flagged separately for the customer to handle manually. Attachment metadata (upload timestamp, uploader) transfers as file properties.

Support.com Cloud Tags applied to tickets for categorization export as HubSpot Ticket Labels. Tag naming conventions may conflict with existing HubSpot labels; we prefix migrated tags with the source system name (e.g., scom_tagname) during the initial migration and remove the prefix in a post-migration cleanup step if the customer chooses.

Support.com Cloud per-instance custom ticket fields have no public schema. We enumerate each active custom field on Tickets during discovery by logging into the customer instance and recording field name, type, and options list. Each discovered field is then created as a HubSpot custom ticket property of the matching type (single-line text, multi-line text, number, date, single-checkbox, dropdown) before ticket migration begins. This discovery step adds one to two days to the project timeline.

Support.com Cloud per-instance custom fields on Customer records follow the same discovery and enumeration process as ticket custom fields. We create matching HubSpot custom Contact properties before Customer-to-Contact migration. If a Support.com Cloud custom field stores device identifiers or technical metadata, we link it to the Contact record and flag it as a candidate for HubSpot's device management integrations if the customer adopts them post-migration.

Support.com Cloud ticket status change timestamps are preserved by creating HubSpot Ticket engagements (as internal notes) that record each status transition with the original timestamp and the agent who made the change. This preserves the full audit trail of how a ticket moved through resolution without relying on HubSpot's native SLA object which is only available in Enterprise.

Support.com Cloud Customer records may include linked device information (device model, serial number, OS version) that is not a native HubSpot object. We transfer device identifiers as custom Contact properties (device_model__c, device_serial__c, os_version__c) and link the most recent device notes as HubSpot Contact notes. If the customer maintains an active device management use case, we recommend HubSpot's asset management integrations as a post-migration upgrade path.

Support.com Cloud ticket conversation threads (agent and customer replies) migrate to HubSpot Ticket conversations. Each message in the thread becomes a Conversation message entry linked to the parent Ticket. The original message timestamp, sender (agent or customer), and content transfer directly. Customer email addresses in the thread are matched to HubSpot Contacts where possible; anonymous messages retain the original sender email as a property.