Migrate from SupportSystem to Salesforce Service Cloud

SupportSystem Tickets map directly to Salesforce Cases. We extract Ticket ID, status, priority, creation date, assigned agent, help topic, department, and custom field values from CSV exports. CaseNumber on Salesforce is auto-generated; we preserve the original SupportSystem Ticket ID in a custom field ss_original_ticket_id__c for reference and audit. Case Origin maps from the SupportSystem channel field (email, portal, phone) to Salesforce Case Origin picklist values.

SupportSystem Agents map to Salesforce User records. We extract agent name and email from CSV ticket header exports and match by email against the destination Salesforce org's User table. Agents without a matching Salesforce User enter a reconciliation queue for the customer's admin to provision before record import. Active agents receive active Salesforce Users; inactive or archived agents receive inactive Users to preserve assignment history without licensing implications.

SupportSystem End Users who create tickets via the Client Portal map to Salesforce Contact records. User name, email, and organization membership export via CSV from Advanced Search filtered by User Information. We map User email as the Contact Email field and resolve the AccountId lookup by matching the User's Organization name against the Account object (pre-created from Organization records in a separate pass).

SupportSystem Organizations map to Salesforce Account records. We extract Organization name, domain, and address from CSV exports filtered by Organization Information in Advanced Search. Organization name becomes Account Name; domain maps to Account Website. Account is created before Contact import so that AccountId lookup is satisfied at Contact insert time.

SupportSystem Custom Fields per ticket map to Salesforce custom fields on the Case object. We pre-create every Salesforce custom field before migration with a matching API name (ss_ticket_custom_field_name__c), correct field type (text, picklist, checkbox, date, number), and required/optional setting. Custom field values export from SupportSystem only if the Export Picker has been configured to include them — we verify field presence in the sample CSV during scoping and request a re-export with updated picker settings if any expected fields are absent.

SupportSystem Custom Forms collect structured intake data at ticket creation. Form field data is included in ticket exports when the Export Picker is configured to include form fields. We extract form field values per ticket and map them to corresponding Salesforce custom fields on Case. If the destination uses Field Sets for form layout grouping, we document the field-to-field-set assignment for the customer's admin to configure post-migration.

SupportSystem Help Topics drive ticket routing and can trigger specific Custom Forms. We preserve Help Topic assignment as a custom field on Case (ss_help_topic__c) and evaluate whether to map high-volume Help Topics to Salesforce Case Record Types during scoping. If the customer has fewer than ten distinct Help Topics driving significantly different case processes, Record Type mapping provides cleaner agent experiences. For simple routing without process differences, the custom field approach preserves routing logic without requiring Record Type configuration.

SupportSystem Departments are used for ticket routing and agent assignment. Department data appears in ticket header exports. We map Department to either a Salesforce Queue (if the customer uses Omni-Channel or Case Assignment Rules) or to a custom picklist field on Case (ss_department__c) based on the destination routing strategy defined during scoping. The customer's admin configures Omni-Channel work items or Assignment Rule criteria post-migration.

Stock and custom email templates per department exist in SupportSystem as configuration data rather than transactional records. We export template content (subject, body HTML, department association) as structured text and map them to Salesforce Email Templates. Template-to-department mapping translates to Salesforce Folder structure (one Folder per Department). The customer's admin associates templates with Salesforce Support Settings and email automations post-migration.

SupportSystem Knowledge Base articles export as article content and metadata. We extract article title, body (HTML), category, internal notes, and publication status. These map to Salesforce Knowledge Article records with corresponding Article Type fields. Category mapping translates to Salesforce data categories. Draft/published status from SupportSystem maps to Knowledge Article publish status. Routing logic built into Help Topics for article suggestions does not migrate; we document the current routing configuration for the customer's admin to rebuild in Salesforce using Case Article Assignment or Einstein Next Best Action.

Tags applied to SupportSystem tickets appear in ticket metadata exports as comma-separated strings. We extract tag values per ticket and map them to a Salesforce custom field on Case (ss_tags__c) configured as a multi-select picklist. We collect the full tag vocabulary during scoping and whitelisted values are pre-populated in the picklist definition. If the tag vocabulary exceeds Salesforce's picklist limit, we recommend a junction object or topic-based tagging approach.

SupportSystem Dashboard exports provide a historical overview of ticket metadata filtered by date, department, help topic, or agent. This CSV serves as a secondary validation source for cross-checking migration completeness. We use dashboard export counts to validate that the sum of exported ticket records matches the case count loaded into Salesforce. Actual Salesforce Reports and Dashboards are rebuilt by the customer's admin post-migration using the migrated case data.