Migrate from CA Service Desk Manager to Zendesk

CA SDM Requests map directly to Zendesk Tickets. We map ref_num to the ticket ID field, description to the subject and description body, priority to Zendesk Priority (urgent/high/normal/low), and status to Zendesk Status (new/open/pending/on-hold/solved/closed). Custom request attributes defined in .maj files migrate as Zendesk custom fields. CA SDM's request category maps to a Zendesk custom field or tag depending on the customer's preference for reporting.

CA SDM Incidents are a distinct ITIL-aligned object type separate from Requests. Zendesk does not have a native Incident object. We merge Incidents into the Zendesk Ticket model, using the CA SDM incident_type attribute to populate a custom incident_type__c field and a Zendesk tag (e.g., itil_incident) for filtering. The customer chooses during scoping whether to maintain the Incident distinction as a tag-based filter or consolidate fully into standard ticket types.

CA SDM Change Requests track IT change orders with risk_level, approval_status, and implementation_schedule. Zendesk has no native change management object. We offer two options: (1) merge Changes into Tickets with a custom change_type__c field and a risk_level custom field; (2) create a Zendesk custom object (Change_Request) with the relevant fields and a lookup relationship to the parent Ticket. Option 2 requires Zendesk Suite Enterprise or an active custom objects entitlement.

CA SDM Problem records track root-cause analysis separate from individual Incidents, with a related_incident list and known_error_flag. We map Problems to Zendesk either as Tickets with a custom problem__c flag and linked via a tag or custom field to related Incident tickets, or as a Zendesk custom object with a lookup relationship field. The linked_incident references are preserved as Zendesk tags or via the Intercom-to-Zendesk-equivalent comment linking pattern.

CA SDM Knowledge articles (km_record objects) migrate to Zendesk Help Center articles. We map title, summary, full_text, author, approval_status, and publication_date to Zendesk's Article fields. Article-to-request linkage references (caused_by, resolution_for) migrate as Zendesk article tags. Article categories in CA SDM map to Zendesk Section hierarchy. The Zendesk Help Center must be enabled on the destination account before article migration begins.

CA SDM Contacts map to Zendesk Users (end-users or requesters). We map userid, last_name, first_name, email, phone, and organization. The user_type attribute (requester vs analyst) determines whether the record is created as a Zendesk End User or an Agent. Agent contacts with elevated permissions require separate provisioning in Zendesk Admin before migration; we resolve agent roles from CA SDM's analyst group memberships.

CA SDM Organization records map to Zendesk Organizations. We map org_name, org_uuid, description, and primary_contact. Organizations are exported before Contacts so that the Organization lookup is satisfied at Contact insert time. If CA SDM's org_name is blank, we use a placeholder Organization and flag it for the customer's admin to merge post-migration.

CA SDM's CI (Configuration Item) records integrate from CA CMDB. If the destination is Zendesk Suite Enterprise, we map Assets to Zendesk's native Asset object. For lower tiers, we create a Zendesk custom object (Asset) with lookup relationship to the related User or Organization. Fields including ci_name, ci_type, serial_number, assignment, and location migrate as custom fields.

CA SDM SLA definitions live in policy files, not as exportable data records. The REST API surfaces which SLA is assigned to a given request but not the full SLA rule definitions. We preserve request-level SLA assignments as a custom field (sla_name__c) on the Zendesk Ticket, populated from the CA SDM request-level sla_pl field. Full SLA policy recreation (escalation thresholds, business-hour calendars, penalty clauses) requires manual configuration in Zendesk Admin or a separate documentation deliverable from our team.

CA SDM custom objects defined in /site/mods/majic files require schema extraction before migration. There is no self-documenting REST endpoint. Zendesk's new custom objects use a relational database model (table-and-column) rather than CA SDM's document-oriented model. Nested or hierarchical data in CA SDM custom objects must be remodeled into multiple separate Zendesk custom objects with lookup relationships. Zendesk's new custom objects require a name field—we identify a suitable attribute from the legacy object or generate a normalized value. Legacy custom object relationships (graph edge records) map to Zendesk lookup relationship fields.

CA SDM attachments are doclink entries referencing server filesystem paths or a document repository. We do not extract binary file content from the REST API. During pre-migration, we identify all attachment references and copy files from the CA SDM server filesystem (or document repository) to a staging location. After ticket and article migration, we upload files to Zendesk via the Zendesk Attachments API and link them to the correct ticket or article record. The CA SDM server filesystem must remain accessible throughout the entire migration window.

CA SDM post-resolution survey responses are linked to requests. Zendesk has a native Satisfaction Rating object but it is tied to the agent and not the ticket in all plan tiers. We migrate survey scores, responses, and timestamps as custom fields on the Zendesk Ticket (survey_score__c, survey_response__c, survey_timestamp__c) to preserve the complete audit trail regardless of the destination account's satisfaction configuration.