Migrate from iSupport Software to Salesforce Service Cloud

iSupport Incidents map to Salesforce Case with the 10-digit alphanumeric ticket ID preserved as a custom external ID field isupport_ticket_id__c for audit continuity. Status, Priority, Category, Assignee (resolved via OwnerId lookup), and Requester (resolved via ContactId lookup) map to their Salesforce equivalents. If the customer uses Service Cloud Entitlement Management, we also map the iSupport incident's SLA tier to a Salesforce Entitlement during import. Cases are imported after Accounts and Contacts so that AccountId and ContactId references are satisfied at insert time.

iSupport Customers map to Salesforce Contact. The customer's contact details (email, phone, address) map to the standard Contact fields. We use email as the dedupe key. If the iSupport Customer record references a Company, we resolve the AccountId during import by joining on the iSupport company name against the Account name. The customer profile's custom fields map to custom Contact fields, with picklist values normalized against the destination allowed values list.

iSupport Companies map to Salesforce Account. The company name becomes Account Name. If the company domain is available, it maps to Account Website and serves as an additional dedupe signal. The company-to-customer linkage is preserved during migration by resolving the iSupport company_id on each Customer record to the corresponding Account record. Accounts are imported first, before Contacts, so that AccountId is available as a foreign key at Contact insert time.

iSupport Knowledge Entries map to Salesforce Knowledge articles with the article title, body content, and rich text formatting preserved. The iSupport category structure maps to Salesforce Data Category Groups (customizable during scoping). Article attachments migrate as Salesforce ContentVersion records linked via ContentDocumentLink to the article. We publish articles in Draft status during import so that the customer's admin can review and activate them in Salesforce Knowledge before going live.

iSupport Assets map to Salesforce Asset with serial number, purchase date, and status preserved. The iSupport asset-to-incident linkage (stored in the incident_asset_link junction table) maps to the Salesforce Case-Asset relationship via the AssetId field on Case. If the junction table is unavailable in the source export, we fall back to a text-based asset ID field stored on the incident record and resolve it during the Case import phase. Product2 lookup is created during scoping if the iSupport Asset references a product.

iSupport custom fields map to Salesforce custom fields on Case, Contact, and Account respectively. Picklist values are normalized during the extraction phase before transformation: we separate picklist definitions from record data, validate each value against the destination field's allowed values, and create new picklist values in Salesforce if the destination schema permits. Custom field naming conventions follow Salesforce __c suffix standards with API names matched to the iSupport field label for admin readability.

iSupport Surveys attach to incidents and capture post-resolution satisfaction data. Survey questions and answer schemas have no direct Salesforce equivalent unless the customer licenses Salesforce Survey (included with Health Cloud and available as an add-on). We discuss the survey strategy during scoping: either migrate post-resolution satisfaction scores as a custom Case field (simple, low maintenance) or rebuild the survey schema in Salesforce Surveys and map responses accordingly (preserves survey structure). The choice is documented before migration begins.

Change Records only exist in iSupport Service Desk Edition. During discovery, we run a feature-detection query against the source account's edition entitlements. If Change Records are present, we map them to a custom Salesforce object (Change_Request__c) with fields for change type, risk assessment, and approval status, because the standard Case object does not cover ITIL-aligned change workflows without customization. If the customer prefers to use Case for changes, we map Change Records to Case with a Record Type of Change.

The CMDB object is gated behind iSupport Service Desk Edition. If present, CMDB entries map to a custom ConfigurationItem__c object in Salesforce that tracks CI relationships and dependency maps. If the iSupport CMDB captures relationships between configuration items, we represent those as junction records on a custom ConfigurationItemRelationship__c object. If CMDB is not present (Incident Management edition), this object is omitted from the migration scope.

iSupport email routing rules use a positional ordering system evaluated by the Email Processing agent. Email rules, account mappings, and auto-reply configurations do not migrate as executable code. We deliver a written inventory of every iSupport email rule with its trigger conditions, routing targets, and priority order, along with a recommended Salesforce Email-to-Case configuration or Flow alternative. The customer's admin implements the replacement using our documentation.