Migrate from CA Service Desk Manager to Zoho Desk

CA SDM Requests map directly to Zoho Desk Tickets. The CA SDM ref_num, description, priority, status, category, and created_date fields map to their Zoho Desk equivalents. Custom attributes defined in .maj files migrate to Zoho Desk custom fields. The CA SDM request_type distinction (standard request vs. incident) is preserved as a custom field or mapped to Zoho Desk's Ticket Type if the customer configures a matching type in their layout. Request assignment to analyst groups migrates to Zoho Desk agent assignment with team lookup resolution.

CA SDM Incidents are a distinct request type in its ITIL-aligned object model. We separate Incidents from standard Requests during export using the request_type attribute and preserve incident-specific fields (impact, urgency, resolved_date, resolution_code) as Zoho Desk custom fields. Incidents retain their linkage to related Problems via the related_prob fields during migration. Zoho Desk does not have a native Incident object type; we use a custom field incident_flag__c set to true for migrated Incident records.

Change Requests in CA SDM track IT change orders with separate fields for change_id, category, risk_level, approval_status, and implementation_schedule. Zoho Desk does not have a native Change Management object type. We map Change Records to Tickets with a custom field change_flag__c and preserve risk_level, approval_status, and implementation_schedule as custom fields. Change attachments and linked incidents migrate as ticket attachments and related ticket references. The multi-level approval chain in CA SDM cannot be replicated in Zoho Desk; we document the approval structure for the customer's admin to rebuild using Zoho Desk's approval workflows.

Problem records in CA SDM track root-cause analysis separate from individual incidents. We export problem_id, related_incident list, root_cause_description, and known_error_flag. Problem-to-incident linkages migrate as related ticket references in Zoho Desk. The known_error_flag maps to a custom field known_error__c on the ticket. Problem records have no native equivalent in Zoho Desk's object model; we use a custom field problem_flag__c to distinguish them from standard tickets.

CA SDM Knowledge Articles (km_record objects) migrate to Zoho Desk Articles with title, summary, full_text, author, approval_status, and publication_date preserved. Article-to-request linkage references (how CA SDM links articles to tickets via knowledge links) migrate as ticket custom fields holding the article ID. Article categories in CA SDM map to Zoho Desk Sections and Sub-sections. Public-facing article publication requires the customer to configure their Zoho Desk Help Center separately after migration.

CA SDM Contacts (end-users and support staff) map to Zoho Desk Contacts. We export userid, last_name, first_name, email, phone, organization, and user_type to distinguish requesters from analysts. The analyst flag maps to the isAgent field in Zoho Desk. Contact records without email addresses are flagged for manual review because Zoho Desk requires an email for agent provisioning but allows blank email for end-user contacts.

CA SDM Organization records (the corporate entities contacts belong to) map to Zoho Desk Accounts. We export org_name, org_uuid, description, and primary_contact references. Organizations are exported before Contacts so that the Account lookup is resolved at Contact import time. Multi-site CA SDM deployments with separate organization records for each site map to separate Zoho Desk Account records, which the customer then assigns to departments in Zoho Desk's department hierarchy.

Support groups in CA SDM (grp objects with group_id, member list, and lead) map to Zoho Desk Teams. We export group memberships and analyst-to-group assignments as a lookup table so that destination group memberships resolve correctly. CA SDM's multi-tier assignment logic (analyst assigned to group, group assigned to request) flattens into Zoho Desk's agent-to-team assignment model. The group lead in CA SDM becomes the Team Lead in Zoho Desk.

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 that depends on the customer providing their .maj file definitions. Zoho Desk has a standard Asset module in Professional and higher tiers; we map CI data to that module where available or to custom fields on the related Ticket.

SLA definitions in CA SDM are stored in policy configuration files, not as exportable data records via the REST API. We reconstruct SLA assignments by reading the request-level sla_pl field (the SLA assigned to each request) and preserving it as a custom field original_sla__c in Zoho Desk. The SLA policy rules (escalation thresholds, business-hour calendars, penalty clauses) are not exported by the REST API; customers who need full SLA policy recreation must provide the policy file exports or use CA SDM's Report Designer to extract SLA data as records. Zoho Desk SLA policies are rebuilt in the SLA Configuration section by the customer's admin.

CA SDM attachments are doclink entries pointing to files on the CA SDM server filesystem or an external document repository. The REST API returns the file path or URL but not the binary content. We handle this in a secondary pass: first identifying all attachment references during the export phase, then resolving each filesystem path while the CA SDM server remains accessible, copying files to a staging location, and pushing them to Zoho Desk via the document management API. The customer must keep the CA SDM server filesystem accessible throughout the migration window; decommissioning it prematurely leaves attachments as broken references.

Post-resolution survey responses in CA SDM linked to requests migrate as custom fields on the Zoho Desk Ticket. Survey scores, responses, and timestamps map to custom fields survey_score__c, survey_response__c, and survey_date__c. Zoho Desk does not have a native survey module; survey data cannot be displayed in a separate object without a third-party integration or custom development. We merge survey data into the ticket record for completeness.

Custom objects defined by administrators in /site/mods/majic require the customer to provide the .maj file schema definition before we can generate the field mapping. There is no REST endpoint in CA SDM that lists custom object schemas. Without the .maj file, custom object migration is deferred. We flag this requirement at the scoping call and do not begin migration until the schema definition is in hand. Custom objects in Zoho Desk are configured in the Customization section by the customer's admin; we provide the complete schema map derived from the .maj file so the admin can provision the correct field types before we begin data migration.