Migrate from Support.com Cloud to Salesforce Service Cloud

Support.com Cloud Tickets map to Salesforce Case. The Support.com ticket status (open, pending, resolved, closed) maps to Salesforce Case Status values we configure in the destination org. Priority maps to Case Priority. The Support.com category field maps to a Case Record Type so that different product lines or customer segments get scoped Page Layouts. The original Support.com ticket ID is preserved in a custom field legacy_ticket_id__c for cross-reference. Any custom ticket fields discovered during the discovery phase map to custom Case fields of equivalent type.

Support.com Cloud Customers with a linked Company record map to Salesforce Contact (linked to Account). Customers without a Company link map to Salesforce Contact with AccountId set to null, or we create a placeholder Account named 'Unknown Account' during migration. The Support.com customer name, email, phone, and address fields map directly to Contact fields. Device identifiers stored on the Customer record map to custom Contact fields or to the Asset object if the destination org uses Asset tracking.

Support.com Cloud Company records (used in B2B instances) map to Salesforce Account. The Company name becomes Account Name, and any domain or industry fields map to Account Website and Industry. Not all Support.com Cloud instances have the Company object enabled; we confirm this during discovery and adjust the mapping scope accordingly. Account is created before Contact import so that the AccountId lookup is satisfied at the moment of Contact insert.

Support.com Cloud Agents map to Salesforce User records. We resolve by email match during migration. The Support.com Agent role (admin, agent, supervisor) maps to a Salesforce Profile and Role assignment, and team membership maps to Salesforce Queue membership. Any Agent without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before Case ownership migration proceeds. Agent historical case assignments (ownership) migrate via Case OwnerId resolved through the User mapping.

Support.com Cloud Macros represent canned response templates and automated actions. We export macro content and trigger logic from the source instance, then document each macro as a recommended Salesforce Flow equivalent or Assignment Rule replacement. Macros do not migrate as executable code because Salesforce Flow uses a different trigger model and action library. The written macro inventory document is delivered to the customer's admin for post-migration rebuild in Flow Builder or the Rule Builder.

Ticket attachments are extracted from Support.com Cloud's legacy file store in batches, normalized to UTF-8 filenames (handling special characters and non-standard encoding), and loaded into Salesforce as ContentVersion records linked to the migrated Case via ContentDocumentLink. Attachments exceeding Salesforce's 25MB per file limit are flagged separately for manual customer handling. The original attachment timestamp is preserved in ContentVersion's VersionData field metadata.

Support.com Cloud Tags applied to tickets migrate to Salesforce Topics (with TopicAssignment records) for cross-object categorization, or to a custom multi-select picklist field on Case if the customer prefers a simpler model. Tag naming conventions may conflict with existing Salesforce Topics; we prefix with a legacy_ namespace during import and the customer renames post-migration if desired.

Support.com Cloud supports custom fields on Tickets and Customers, but the schema is per-instance with no public field registry. During discovery we log into the customer instance and enumerate every active custom field name, type, and picklist option. We pre-create matching Salesforce custom fields on Case (and Contact if applicable) before migration begins, using type mapping (text to Text, number to Number, picklist to Picklist, date to Date). This discovery step adds one to two days to the project timeline.

Support.com Cloud ticket categories (product line, issue type, or department segmentation) map to Salesforce Case Record Types. Each Record Type gets its own Page Layout, Business Hours reference, and optionally its own Assignment Rule so that cases route to the correct queue based on category at migration time. If the destination org already has Record Types configured, we map the Support.com category to the nearest existing Record Type.

Support.com Cloud ticket status change timestamps migrate to Salesforce CaseHistory for audit tracking. Any internal or customer-facing comments attached to ticket status changes migrate as EmailMessage records linked to the Case so that the full conversation thread is visible in the Case's Activity timeline. Status history preserves the original timestamp and the agent who made the change.

Device records linked to Support.com Cloud Customer accounts (model, serial number, OS version) map to Salesforce Asset linked to the Account or Contact. Asset Name comes from the device description; Asset Serial Number maps from the Support.com device identifier. If the destination org does not use Asset tracking, device fields migrate as custom Contact or Account fields.

Support.com Cloud SLA configurations (priority-to-response-time mappings) do not migrate as executable Entitlements. We export the SLA definition table (priority level, first response target hours, resolution target hours, business hours) and document it as an Entitlements and Business Hours configuration plan for the customer's Salesforce admin. Entitlements are then configured in the destination org before the migration closes, ensuring new cases born in Salesforce receive SLA tracking from day one.