Migrate from OpenText Service Manager to Salesforce Service Cloud

OpenText Service Manager Incidents map directly to Salesforce Case records. The Service Manager Incident priority (Critical, High, Medium, Low) maps to Salesforce Case Priority, and the Incident status (New, Assigned, In Progress, Resolved, Closed) maps to Case Status. Resolution notes and root-cause fields migrate to custom Case fields. We preserve the original Incident ID in a custom field sm_incident_id__c for cross-system audit trails. The Case Origin field is set from the Service Manager source_channel or contact_method field. Incidents are migrated before any related Problems or Changes to satisfy lookup dependencies.

Service Manager Requests (service catalog submissions) map to Salesforce Case with a Record Type of Service Request. The request category, subcategory, and fulfillment workflow identifier are preserved in custom fields for the customer's admin to use in routing rules or Flow reconstruction. Request attachments migrate as ContentDocumentLink records attached to the Case.

OpenText Service Manager Problem records do not have a native Salesforce standard object equivalent. We pre-create a Problem__c custom object with fields mapped from the Service Manager Problem schema: Problem_ID__c (external key), Title__c, Description__c, Root_Cause__c (rich text), Known_Error_Flag__c (checkbox), Related_Incident_IDs__c (text), and Status__c (picklist matching Service Manager Problem lifecycle). Problem records are linked to their related Incident Cases via a custom lookup field Problem__c on Case.

Service Manager Change records (ITIL Change Management) map to a Change__c custom object. Fields include Change_ID__c (external key), Change_Type__c (Standard, Normal, Emergency picklist), Risk_Rating__c (Low, Medium, High, Critical), CAB_Approval_Status__c, Implementation_Plan__c (rich text), Rollback_Plan__c (rich text), and Scheduled_Start__c / Scheduled_End__c datetime fields. Relationships to affected CI records migrate as Change_CIs__c (text or multi-select). Salesforce's FSM (Field Service Management) add-on includes a native Change Request object; if the customer licenses FSM, we map Changes to the native fsc__FieldServiceIncident__c or recommend a separate FSM Change Advisory Board engagement.

Service Manager Knowledge Articles (structured HTML/RTF with title, body, author, publish date, and category) map to Salesforce Knowledge articles via the KnowledgeArticleVersion object. We export articles in structured format and import via the Salesforce Knowledge API. The article type (How-to, Troubleshooting, Policy) maps to Salesforce Article Type, and publish status maps to the Knowledge workflow state (Draft, Published, Archived). Article attachments migrate as ContentDocument records linked to the article.

Service Manager CIs (servers, software, network devices, applications) and their relationship records map to Salesforce Asset for tracked products and Location for physical and virtual sites. CI type (Hardware, Software, Document, Application) determines whether Asset or Location is the primary record. CI relationships (depends-on, relates-to, affects) are preserved as AssetRelationship records. We resolve CI-to-Incident links by matching the Service Manager CI Identifier against the imported Asset Name or custom sm_ci_id__c field on Asset.

Service Manager user and contact records (name, email, department, phone, role, group membership) are extracted during discovery. Internal agents map to Salesforce User records by email match. End-user contacts who do not have Salesforce User licenses map to Contact records linked to an Account (typically the customer's Account). We preserve the Service Manager user ID in sm_user_id__c for reconciliation and group memberships in a custom field group_names__c for the admin to reference when rebuilding queue assignments.

Service Manager SLA rules (response time, resolution time, business hours, escalation contacts) are scoped to priority and category. Salesforce models SLA compliance via Entitlements (which define the SLA template) and Milestones (which track individual time-bound steps). We document the full SLA definition — including priority-to-entitlement mapping, business hours calendar, and milestone breach actions — as a written specification for the customer's Salesforce admin to rebuild as Entitlements and entitlement processes in Setup. SLA breach flags from Service Manager are preserved as custom fields for post-migration reporting.

File attachments on Incidents, Requests, Problems, Changes, and Knowledge Articles are exported as binary blobs with their association metadata (parent record type and ID, file name, MIME type, size). We re-import them into Salesforce as ContentVersion (file body) records linked to the migrated parent record via ContentDocumentLink. The original file name and description are preserved in ContentVersion fields. Attachments are processed in a separate pass after all ticket records are confirmed in Salesforce to avoid orphaned file references.

Both platforms support custom fields on ticket records. We extract the full Service Manager custom field schema — field name, data type, picklist values, display order — during discovery. Destination custom fields are pre-created in Salesforce (Case, Problem__c, Change__c) with matching API names before any data import begins. Custom field values are transformed and inserted in the same migration pass as their parent records.