Migrate from ITSM 365 to Salesforce Service Cloud

ITSM 365 Incidents map to Salesforce Case with Record Type set to Incident. The source priority field (P1-P4 or equivalent) maps to Case Priority, and the incident description, affected CI, and assignment group transfer to custom fields on Case. Original incident number is preserved in a custom field itsm_incident_id__c for traceability. SLA breach flags transfer to Case custom fields for post-migration reporting.

Service Requests map to Salesforce Case with Record Type set to Service Request. Request type, requester, and fulfillment details map to custom fields on Case. The Standard tier request categories become Case Origin or custom picklist fields. Standard tier approval requirements on requests are noted in the inventory document for rebuild as Salesforce Approval Processes or Flow-based approvals.

ITSM 365 Changes map to Salesforce Case with Record Type set to Change, or to a custom Change__c object if the customer's Salesforce edition lacks the native Change object. Risk classification (standard, normal, emergency) from ITSM 365 maps to a custom risk field, and the change calendar and approval status transfer as custom fields. Emergency change flagging maps to a Salesforce custom field that triggers expedited routing rules post-migration.

ITSM 365 Problems (root-cause investigations) map to a Salesforce Case created as the Problem record, with related Incidents linked via the Case ParentId field. Problem status, root cause description, and known error workarounds transfer to custom fields on the parent Case. We create a custom relationship to Incident Cases using a lookup field so that the Problem-Incident relationship is preserved in Salesforce reporting.

ITSM 365 CIs (servers, software, network devices, applications) map to Salesforce Asset by default for hardware and software items. Complex CI relationship maps (CI-to-CI dependencies) may require a custom object with self-lookup fields to preserve dependency topology. We assess CI volume and relationship complexity during discovery and recommend Asset versus custom object on a per-organization basis. CI class from ITSM 365 (hardware, software, document, location) maps to Asset Type or a custom picklist.

ITSM 365 SLA assignments and priority tiers do not have a direct Salesforce equivalent — Salesforce uses Entitlement Processes and Milestones linked to Case via the Entitlement field. We map ITSM 365 SLA tier names (Gold, Silver, Bronze or P1-P4 tier names) to Salesforce Entitlement records with corresponding Milestone time triggers. The original SLA tier is preserved in a custom field itsm_sla_tier__c on Case for audit continuity. Entitlement Processes must be configured in Salesforce before Case migration begins.

ITSM 365 agents and IT staff map to Salesforce User records. We resolve by email address match against the destination Salesforce org. Any ITSM 365 user without a matching Salesforce User is placed in a reconciliation queue for the customer's admin to provision before Case import begins. Assignment group members from ITSM 365 transfer to Salesforce Queues, which we provision during the schema design phase.

ITSM 365 file attachments on Incidents, Service Requests, Changes, and Problems migrate as Salesforce ContentDocument records linked via ContentDocumentLink to the parent Case. We extract attachments via the ITSM 365 export API, upload to Salesforce ContentWorkspace or Files, and link by Case ID resolution.

ITSM 365 Standard tier custom properties on Incident, Request, Change, and Problem objects require field-level mapping to Salesforce custom fields. We identify every custom property during discovery, map to the equivalent Salesforce field type (text, picklist, number, date, checkbox), create the custom fields in the destination org via metadata API, and include them in the field-level migration mapping. Custom properties on Lite tier are limited, reducing the mapping scope significantly.

ITSM 365 approval chains are not migrated as Salesforce automations. We inventory every active approval chain during discovery — including approval steps, approver roles, escalation rules, and SLA-based escalation timers — and deliver a written handoff document describing each chain's trigger, steps, and recommended Salesforce Approval Process or Flow equivalent. The customer's Salesforce admin rebuilds approval chains post-migration. This is explicitly outside our standard migration scope.

ITSM 365 Standard tier workflow automation (auto-assignment rules, SLA escalation triggers, notification templates, field update rules) is not migrated as Salesforce Flow. We document every active workflow rule with its trigger object, conditions, and actions, and map each to a Salesforce Flow type (record-triggered, scheduled, or screen flow). The inventory document is delivered with the migration data package. Workflow rebuild is outside our standard scope.