Migrate from Vision Service Desk to Salesforce Service Cloud

Vision Service Desk Tickets map directly to Salesforce Cases. The ticket priority (low, medium, high, urgent) maps to Case Priority, ticket status maps to Case Status, and ticket type maps to Case Type or a custom picklist. Threaded conversation history migrates as Salesforce EmailMessage records (for email-style replies) and Task records (for internal notes), preserving the chronological thread order by setting CreatedDate to the original Vision timestamp. Parent ticket relationships (linked tickets) map to Case parent Case using the standard Salesforce self-lookup.

Vision Service Desk Clients (portal end-users) map to Salesforce Contacts. Client custom fields require explicit extraction from Vision's API (not returned in default list responses) and map to Contact custom fields. Client portal preferences do not migrate; we document the preference set for the customer's admin to configure in Salesforce Experience Cloud or Service Cloud portal settings post-migration.

Vision Service Desk Company records map to Salesforce Account. The company tree structure (parent-child groupings) does not have a direct Salesforce equivalent; we flatten the hierarchy and add a custom field vhd_parent_company__c storing the parent company name as a text reference for the customer's admin to convert to a proper Account hierarchy post-migration. Company-specific custom fields migrate to Account custom fields.

Vision Service Desk Staff records map to Salesforce Users. Staff hierarchy (Super-Admin, Team Manager, Agent roles) maps to Salesforce Profile and Role assignments that we document for the customer's admin to configure before migration. Vision Staff CSV import requires a specific column order we reverse-engineered; we apply a pre-flight column transform to prevent import rejection. Staff without a matching Salesforce User go to a reconciliation queue.

Vision Service Desk KB articles migrate to Salesforce Knowledge Articles. Article content (body, summary, URL name) migrates directly. Category assignments from Vision map to Salesforce Data Category Groups and Data Categories, which require pre-configuration in the destination org before migration. Article-to-topic associations migrate as Salesforce TopicAssignment records. Custom article fields require value mapping to Salesforce article custom fields of equivalent type.

Vision's hierarchical KB category tree maps to Salesforce Data Category Groups (one per Vision category root) and Data Categories (nested per Vision subcategory). We extract the full category tree during scoping and pre-configure the Data Category Group structure in the Salesforce destination sandbox before any article migration begins, so that article-to-category assignments resolve at import time rather than requiring a second pass.

Vision Service Desk SLA plans (calendar-based response and resolution targets) map to Salesforce Entitlement records linked to Contact or Account, with Entitlement Processes defining the milestone timelines. We migrate SLA plan definitions as configuration documentation and advise the customer to reassign SLA tiers to destination entitlement processes during the Service Cloud setup phase. SLA milestones (First Response, Resolution) do not carry over as active rules; the customer's admin rebuilds these in Salesforce Setup > Entitlement Processes.

Vision Service Desk custom ticket fields are not returned in default API list responses and require explicit field-specific API calls or direct database reads. We build a custom field manifest during discovery listing every custom field definition (name, type, options) and include those fields explicitly in extraction queries. Each custom field type (drop-down, multi-select, date, text, number) maps to the nearest Salesforce field type; multi-select picklist in Vision maps to multi-select picklist in Salesforce. Custom field values migrate as supplementary Case custom field data.

Vision Service Desk ticket classification tags and labels migrate to Salesforce Case Tags or to a custom picklist field on Case, depending on whether the customer wants tag-based filtering within Salesforce's native tag model or a dedicated custom field. We document the full tag taxonomy during scoping and confirm the strategy with the customer before migration, as tag count affects field type selection (multi-select picklist has a 500-value limit in Salesforce).

Vision Service Desk Problem Management records (linked to related incidents) have no direct Salesforce standard equivalent. We migrate Problem records as Cases with a custom record type 'Problem' and a custom field vhd_problem_id__c storing the original Vision Problem ID for audit. The incident associations migrate as Case comment entries or linked Case relationships. Problem-to-incident linkage is documented separately for the customer's admin to evaluate Salesforce's native Problem Management (Unlimited+ tier) or a custom linked-object model.

Vision Service Desk Change Management records with approval workflows and schedules do not map to any Salesforce standard object at most tiers. We migrate Change records as a custom object Change_Request__c with fields for change type, priority, schedule, approval status, and approval chain history. Approval chain reconstruction in Salesforce depends on the destination org's workflow model (Flow Approvals or a custom approval custom object) and is documented as a configuration item for the customer's admin to finalize post-migration.

Vision Service Desk asset records and Configuration Management Database entries map to Salesforce Asset objects linked to Product2 and Account. CI relationships (linked CI items) migrate as Asset relationship records or as custom lookup fields on Asset. CMDB mapping depends heavily on the destination org's asset scoping; we migrate asset records with their current status, location, and linked contact information, and document CI relationship topology for the customer's admin to evaluate whether a full CMDB rebuild in Service Cloud or a third-party ITSM integration is appropriate.