Migrate your CA Service Desk Manager data

Requests is the primary ticket object in CA SDM. We export all standard fields (ref_num, description, priority, status, category) plus custom attributes. The REST API returns structured JSON; we map each request to the destination ticket object preserving timestamps and assignee assignment.

Incidents are a distinct request type in CA SDM's ITIL-aligned object model. We separate Incidents from standard Requests during export using the request_type attribute and preserve incident-specific fields like impact, urgency, and resolution_code.

Change Requests are a separate object type tracking IT change orders. We export change_id, category, risk_level, approval_status, and implementation_schedule. Change attachments and linked incidents are exported as related records.

Problem records track root-cause analysis separate from individual incidents. We export the problem_id, related_incident list, root_cause_description, and known_error_flag. Problem-to-incident linkage is preserved as a foreign-key relationship in the export.

Knowledge articles in CA SDM are stored as km_record objects. We export title, summary, full_text, author, approval_status, and publication_date. Article-to-request linkage references are preserved so the destination can rebuild cross-references.

Contacts represent end-users and support staff. We export userid, last_name, first_name, email, phone, organization, and the user_type attribute that distinguishes requesters from analysts. Role assignments are preserved as a custom property on export.

Organization records in CA SDM represent the corporate entities contacts belong to. We export org_name, org_uuid, description, and primary_contact references. Organizations are exported as a separate object so they can be pre-loaded in the destination before contacts.

CA SDM integrates with CA CMDB for asset data. Asset exports include ci_name, ci_type, serial_number, assignment, and location. Custom CI attributes defined in .mod files require field-level mapping work during migration since not all CMDB fields map directly to ITSM-standard asset schemas in modern platforms.

SLA records define service level targets but are not standalone exported objects in CA SDM's REST API. We reconstruct SLA assignments by reading the request-level sla_pl and priority mapping. Full SLA definition migration requires reading the policy files separately from the data export.

Custom objects defined by administrators in /site/mods/majic require manual schema extraction from the .maj file before migration. There is no self-documented REST endpoint for discovering custom object structures. We require the customer to provide the custom object definitions file before we can include them in the migration scope.

Attachments are stored as doclinks pointing to files on the CA SDM server filesystem or a document repository. We export the attachment reference (file path, URL, or content ID) but not the binary file itself in standard REST exports. We flag this gap and handle binary attachment migration as a separate step using the document repository API.

CA SDM stores post-resolution survey responses linked to requests. We export survey scores, responses, and timestamps. Many modern ITSM platforms do not have a native survey object, so we merge survey data as custom fields on the target request record.

Support groups in CA SDM are defined as grp objects with group_id, member list, and lead. We export group memberships and preserve the analyst-to-group assignments as a lookup table so destination groups can be pre-created before assigning analysts.

Request offerings and service catalog items in CA SDM are defined as web form templates or process DiR templates. These are not easily extracted via the standard REST API. We map catalog items to the closest equivalent in the destination (service catalog, request type, or form) but cannot guarantee full catalog fidelity.