Migrate from CA Service Desk Manager to HubSpot Service Hub

CA SDM Requests map to HubSpot Tickets assigned to a 'Request' pipeline. We map ref_num to ticket ID, description to subject, priority to priority, category to ticket property, and status to pipeline stage. Request-specific attributes like request_type and affected_service migrate as custom ticket properties. The original CA SDM ticket ID is preserved in hs_original_ref_num__c for audit trail.

CA SDM Incidents are a distinct request_type from standard Requests in the ITIL-aligned object model. We separate Incidents during export using the request_type attribute and route them to a dedicated Incident pipeline in HubSpot with a hs_incident_indicator__c flag. Related_incident links (CA SDM's incident-to-incident relationships) are preserved as HubSpot association records or ticket-to-ticket custom properties.

CA SDM Change Requests carry change_id, risk_level, approval_status, and implementation_schedule that have no native HubSpot equivalent. We route them to a dedicated Change pipeline with custom fields: risk_level (low/medium/high/critical), approval_status, implementation_date, and rollback_plan. If the customer needs the full multi-level approval chain from CA SDM, we document it as a HubSpot Workflow rebuild requirement since the native approval engine is limited to single-approver flows.

CA SDM Problem records track root-cause analysis separate from incidents, with fields including problem_id, related_incident list, root_cause_description, and known_error_flag. We map Problem records to a dedicated ticket pipeline with a hs_problem_record__c custom property. The related_incident list migrates as a multi-line text property or association. Customers using CA SDM's Known Error Database (KEdb) functionality should plan to migrate those records separately as HubSpot knowledge base articles.

CA SDM Contacts map to HubSpot Contacts. We extract userid, last_name, first_name, email, phone, organization, and user_type (distinguishing requesters from analysts). Role assignments and analyst permissions are mapped to HubSpot Teams and User roles post-migration. CA SDM Contacts without email addresses are flagged for the customer's admin to resolve or merge with existing Contact records.

CA SDM Organization records map to HubSpot Companies. We export org_name, org_uuid, description, and primary_contact references. The organization-contact linkage is preserved by setting the HubSpot Contact's associated company to the migrated Company record. Multi-site CA SDM deployments (organization-level data segregation) map to HubSpot Company records with a custom site_id property.

CA SDM Knowledge Articles migrate to HubSpot Knowledge Base Articles via the HubSpot CMS Knowledge Base API. We export title, summary, full_text, author, approval_status, and publication_date. Article-to-request linkage references (km_open_modify and km_close_notify fields) are preserved as custom properties on the article or as a lookup table for the customer to re-link post-migration. Draft status from CA SDM maps to HubSpot Draft status.

CA SDM assets (ci_name, ci_type, serial_number, assignment, location) migrate as HubSpot Custom Objects if Service Hub Professional or Enterprise is selected, or as custom properties on the related Company or Contact record on Starter. Asset-to-contact linkage is preserved through the custom object association API. Custom CI attributes defined in CA SDM .mod files require the customer to provide schema files before field-level mapping can proceed.

CA SDM SLA definitions are stored in policy configuration files rather than as exportable data records. We reconstruct SLA assignments by reading request-level sla_pl and priority mapping during export, then set the HubSpot SLA on the ticket via the SLA object API (available on Professional and Enterprise tiers). Full SLA policy definitions (escalation thresholds, business-hour calendars) require the customer to manually configure HubSpot Conditional SLAs using the original policy files, which we document in the SLA rebuild inventory.

CA SDM doclink entries store file-path references to the server filesystem or external document repositories, not embedded binary data. We identify all attachment references during export, perform a secondary file-copy pass to a migration staging location while the CA SDM server remains online, then push files to HubSpot via the HubSpot Files API. Files that cannot be located during the staging phase are written to a reconciliation report with the original doclink URL preserved as a text property on the associated ticket.

CA SDM support groups (grp objects with group_id, member list, and lead) map to HubSpot Teams. We export group memberships and analyst-to-group assignments as a lookup table during scoping, then create HubSpot Teams and assign agents during the post-migration configuration phase. CA SDM's multi-level group hierarchies (nested groups) map to HubSpot team structure with a custom property tracking the parent group relationship.

CA SDM post-resolution survey responses linked to tickets have no native equivalent in HubSpot Service Hub. We export survey scores, response text, and timestamps as custom properties on the associated ticket (hs_survey_score__c, hs_survey_response__c). If the customer uses HubSpot's native NPS or CES survey feature post-migration, existing survey responses are stored as historical records rather than active survey objects.