Migrate from CA Service Desk Manager to Gorgias

CA SDM Requests map directly to Gorgias Tickets. The ref_num becomes the ticket ID; description, priority (priority keyword), status, and category transfer as standard fields. The original request_type is preserved as a tag (e.g., 'incident-type', 'standard-request') so the customer can filter by the original CA SDM request type in Gorgias. Custom attributes on the Request object map to Gorgias custom ticket fields.

CA SDM Incidents are a distinct request type in the ITIL model but collapse into a single ticket in Gorgias. We separate Incidents from standard Requests during export using the request_type attribute, then create the ticket in Gorgias with an 'incident' tag and preserve incident-specific fields (incident_id, impact, urgency) as custom ticket fields. The incident-to-change linkage is recorded as a related ticket tag or note for manual cross-reference in Gorgias.

CA SDM Change Requests track IT change orders with risk_level, approval_status, and implementation_schedule. Gorgias does not have a native change management object. We migrate Change Request records as archived tickets with a 'change-request' tag and a custom field change_risk_level__c. The customer's admin decides whether to use Gorgias tags and categories to replicate a lightweight change log or whether to maintain change records in a separate ITSM tool. The migration does not replicate the multi-level approval chain.

CA SDM Problem records track root-cause analysis separate from individual incidents, with a related_incident list and known_error_flag. Gorgias has no native problem management object. We migrate Problem records as archived tickets with a 'problem-record' tag and store the root_cause_description as the ticket body. The incident-to-problem linkage is preserved by creating a related ticket tag in Gorgias that references the original CA SDM problem_id, allowing agents to manually cross-reference known errors against current tickets.

CA SDM Knowledge Articles (km_record objects) migrate to Gorgias Articles. We export title, summary, full_text, author, approval_status, and publication_date. Article-to-request linkage references are preserved as a tag on the migrated article so the customer knows which CA SDM tickets referenced which articles. Articles are imported via Gorgias's Article API or CSV import, and the customer validates that the HTML formatting transfers correctly for their knowledge base template.

CA SDM Contacts (end-users and analysts) map to Gorgias Customers. We export userid, last_name, first_name, email, phone, organization, and the user_type attribute. The email address is the dedupe key during import. user_type distinguishes requesters from analysts: requesters become Customers; analyst contacts with active agent assignments in CA SDM become Gorgias Agents. Role assignments (analyst, manager, administrator) are preserved as custom fields and mapped to Gorgias permission groups during user provisioning.

CA SDM Organization records map to the organization field on Gorgias Customers. We export org_name, org_uuid, and description. If the organization has no contacts in the migration scope, we still create the Organization record as a standalone customer with no ticket history to preserve the data. Multiple contacts belonging to the same CA SDM Organization share the same organization field value in Gorgias.

CA SDM Support Groups (grp objects with group_id, member list, and lead) map to Gorgias Teams. We export group memberships and preserve analyst-to-group assignments as a lookup table. The group lead becomes the Team admin in Gorgias. If the customer uses nested groups or multi-tier team hierarchies in CA SDM, we collapse them into a flat Team structure in Gorgias and document the original hierarchy for the admin to reconstruct in Gorgias Rules.

CA SDM integrates with CA CMDB for asset data; asset records (ci_name, ci_type, serial_number, assignment, location) do not have a native equivalent in Gorgias. We map asset data to custom Customer attributes (e.g., asset_serial_number__c, asset_location__c) as a flat key-value structure. If the customer needs full asset management capability, we recommend pairing Gorgias with a dedicated CMDB tool and document the recommended integration path. Custom CI attributes defined in .mod files require the customer to provide schema definitions before migration.

CA SDM attachments are doclink entries pointing to server filesystem paths or an external document repository. The REST API returns the reference (file path, URL, or content ID) but not the binary content. We handle this by identifying attachment references during export, then performing a secondary pass to copy files from the CA SDM server filesystem to a staging location, then push them to Gorgias via the document API. The server filesystem must remain accessible throughout the entire migration window; if it is decommissioned before attachment copy completes, those files become inaccessible.

SLA targets and priority mappings in CA SDM are stored in configuration policy files, not as data records. The REST API surfaces which SLA is assigned to a request (via sla_pl) but not the full SLA rule definition (escalation thresholds, business-hour calendars, penalty clauses). We preserve the request-level SLA assignment as a custom field (sla_name__c) on the migrated Gorgias ticket. The customer must rebuild SLA policy definitions in Gorgias's SLA rules UI using the policy file documentation we extract during scoping. Full SLA policy replication is out of standard scope.

CA SDM stores post-resolution survey responses linked to requests. We export survey scores, responses, and timestamps. Gorgias has a native Satisfaction Survey feature but the survey responses themselves are linked to tickets rather than stored as standalone records. We merge survey data into the migrated ticket as a custom field (csat_score__c, csat_response__c, survey_timestamp__c) so the historical score is preserved even if there is no standalone survey object in Gorgias.

CA SDM custom objects defined in /site/mods/majic require manual schema extraction from the .maj file before migration. There is no self-documenting REST endpoint for discovering custom object schemas. We require the customer to provide their .maj file definitions during scoping, at which point we generate the correct field mapping and pre-create the corresponding custom object in Gorgias. Custom object migration cannot begin until schema files are in hand. If the customer cannot provide .maj files, we defer custom object migration and document what was skipped.