Migrate from CA Service Desk Manager to Salesforce Service Cloud

Standard Requests in CA SDM map to Salesforce Case with Record Type set to Request. We map ref_num to Case CaseNumber, description to Description, priority to Priority, category to a custom field sdm_category__c, and request_type to the Record Type selector. The requester's Contact record is linked via ContactId on Case. Custom request attributes defined in CA SDM .mod files require field-level mapping against the pre-created Salesforce custom fields; we handle this mapping in the scoping phase after receiving the .maj file definitions.

Incidents in CA SDM are a distinct request type with ITIL-aligned lifecycle states (New, Assigned, In Progress, Resolved, Closed). We separate Incidents from standard Requests using the request_type attribute during export, then set the Salesforce Case Record Type to Incident and map CA SDM's incident_id to a custom field sdm_incident_id__c for traceability. Incident-specific fields like related_problem_reference and resolution_code transfer to custom fields on the Case record.

Change Requests in CA SDM are a separate object tracking IT change orders with fields including change_id, risk_level, approval_status, implementation_schedule, and category. Salesforce Service Cloud has no native Change Request object, so we map Change to a Case Record Type named Change Request with custom fields for risk_level__c, approval_status__c, implementation_date__c, and category__c. The change authorization chain is preserved as a custom field with the approval workflow documented for rebuild in Salesforce Flow Approvals.

Problem records in CA SDM track root-cause analysis separate from individual incidents, with related_incident_list, root_cause_description, and known_error_flag. We map Problem to a Salesforce Case Record Type named Problem, preserving the problem_id as sdm_problem_id__c, the root_cause_description as a custom Description field, and the known_error_flag as a custom known_error__c checkbox. The incident linkage migrates as a custom text field holding the comma-separated list of related incident reference numbers; customers needing full Many-to-Many Case linking configure a custom junction object post-migration.

CA SDM Contacts (representing both end-user requesters and internal analysts) map directly to Salesforce Contact. We extract userid, last_name, first_name, email, phone, and organization. The CA SDM user_type attribute (Requester vs Analyst) maps to a custom field sdm_user_type__c, which determines whether the Contact is used as a Case Contact or a Queue member. Organization references resolve via the Organization mapping before Contact import to satisfy lookup dependencies.

CA SDM Organization records (representing the corporate entities that Contacts belong to) map to Salesforce Account. We export org_name, org_uuid, description, and primary_contact references. The Account is created first in the migration sequence so that the Contact lookup is satisfied at the moment of Contact insert. Parent Account hierarchy from CA SDM org_contact relationships maps to Salesforce Account hierarchy where applicable.

CA SDM Support Groups (grp objects with group_id, member list, and group lead) map to a combination of Salesforce Queues (for Case assignment routing) and Salesforce Groups (for Collaboration Group access and data visibility). We extract the member list and group lead from CA SDM grp records during export and reconstruct them as GroupMember records in Salesforce. Queue-based routing rules in Salesforce replace the multi-tier assignment logic that CA SDM groups support natively.

CA SDM Knowledge Articles (km_record objects) map to Salesforce Knowledge Article records when the destination org has Knowledge enabled. We export title, summary, full_text, author, approval_status, and publication_date. Article-to-request linkage references from CA SDM migrate as a custom Related_Requests__c field on the Salesforce Knowledge Article. HTML content from CA SDM KM records is restructured to match Salesforce Knowledge's article data model; articles with embedded images require a separate binary migration pass for image files stored in the CA SDM document repository.

CA SDM asset records (ci_name, ci_type, serial_number, assignment, location) map to Salesforce Asset. Custom CI attributes defined in CA SDM .mod files require field-level mapping; we pre-create the matching custom fields in Salesforce before the Asset import phase. CA SDM's integration with CA CMDB means that some asset records may have deep CI relationship trees (CI-to-CI dependencies) that map to the Salesforce Asset hierarchical relationship field or a custom junction object depending on the complexity of the relationship model.

CA SDM SLA definitions live in policy configuration files, not as REST-exportable records. We reconstruct the request-level SLA assignment (sla_pl and priority mapping) as custom fields on the Salesforce Case: sdm_sla_name__c, sdm_priority_code__c, and sdm_first_response_target__c. The SLA policy engine itself (escalation thresholds, business-hour calendars, penalty clauses) is not migratable as automation. We deliver a written inventory of each CA SDM policy file location and the SLA parameters it contains, along with a recommended Salesforce Entitlements and Milestones configuration plan for the customer's admin to implement post-migration.

CA SDM attachments are doclink entries referencing server filesystem paths or an external document repository, not embedded binary data. We identify attachment references during the export phase and perform a secondary pass to copy each file to a Salesforce-connected app storage location, then insert the binary as a ContentVersion record with the appropriate ContentDocumentLink to the parent Case. The CA SDM server filesystem must remain accessible during the entire migration window; if the original storage location is decommissioned before attachment copy completes, those files become inaccessible. We enforce a rule that the attachment resolution phase completes before CA SDM shutdown.

CA SDM stores post-resolution survey responses linked to Requests. We export survey scores, responses, and timestamps. Salesforce Service Cloud does not have a native survey response object, so we merge survey data into custom fields on the Case: sdm_survey_score__c, sdm_survey_response__c, and sdm_survey_date__c. If the customer implements a post-migration survey tool (Salesforce Surveys, Medallia, or Qualtrics), we document the custom field names so that the survey integration can write back to the correct Case fields.