Migrate from Serviceaide ChangeGear to Salesforce Service Cloud

ChangeGear Incidents map directly to Salesforce Case. Status maps to Case Status, Priority maps to Case Priority, Category maps to a custom Case Type or custom field cg_original_category__c. The assigned Configuration Item reference becomes a lookup to the Salesforce Configuration Item record or a custom CI lookup field depending on the destination org's CMDB setup. Created Date and Closed Date migrate as Salesforce-native timestamps for SLA calculation accuracy.

Change records include CAB approval chains, risk scores, implementation timelines, and approval history. We migrate Change records as Salesforce Cases with a custom record type (Change Management) and custom fields for risk_score__c, cab_approval_status__c, and implementation_timeline__c. Approval history migrates as a custom related list or as Salesforce Approvals records if the customer has an approval management tool. Complex Change workflows with multiple stage gates do not transfer as Salesforce Flow; we document the approval chain as a written Change Management workflow inventory for the admin to rebuild.

Service Requests in ChangeGear follow a separate workflow from Incidents. We map them to Salesforce Case with a Service_Request record type, preserving request item details, fulfillment records, and approval steps as custom fields. If ChangeGear Service Requests have a parent-child relationship with Incidents, we model the link in Salesforce via the Case.parentid field or a custom lookup.

Problem records in ChangeGear link to their related Incidents via a known relationship type. Where the destination org does not use Salesforce's native Known Error capability, we create a custom problem_incident_relationship__c lookup field on Case and generate a mapping table during migration so the relationship is restored in the destination. If the org has Salesforce's Problem Management add-on, we map Problems to the native Problem object with the Incident link resolved via the ProblemIncident relationship.

ChangeGear Knowledge Base articles migrate to Salesforce Knowledge. We extract the full article body, summary, categories, and publication status. Rich text formatting differences between ChangeGear's editor and Salesforce's Lightning knowledge editor may require post-migration HTML cleanup on complex articles. We flag articles with broken hyperlinks or embedded media references for manual review before go-live.

Hardware and software asset records migrate with license counts, warranty status, serial number, and last-seen date. We handle both active and decommissioned asset flags. Any asset record missing a required Salesforce Account or Product lookup goes into a reconciliation queue for the customer to resolve before asset import completes. Decommissioned assets migrate with a status of 'Inventoried' or 'Retired' per the destination org's picklist values.

CIs form a relational graph in ChangeGear with dependencies, affected services, and linked Incidents. We preserve CI relationships explicitly by exporting the full CI graph, creating Salesforce Configuration Item records, and generating a CI relationship import file for the Salesforce CMDB relationship table. The CI type hierarchy in ChangeGear maps to the CI Class in Salesforce CMDB. Complex dependency trees require a separate CI relationship migration phase after the base CI records are loaded.

ChangeGear user records include role-based access assignments and group memberships. We migrate users with active or inactive status preserved. Group hierarchies used for ticket routing and approval chains map to Salesforce Queues and Role Hierarchies. Any ChangeGear group without a direct Salesforce Queue equivalent is documented as a written routing mapping for the admin to configure post-migration.

SLA definitions in ChangeGear include priority-to-SLA mappings and breach thresholds. We map these to Salesforce Entitlement Processes and Case Milestones. Business hours defined in ChangeGear's SLA calendar are extracted and applied to Salesforce Business Hours so that breach timers calculate correctly post-import. We validate a sample of SLA breach timestamps against a known Incident in ChangeGear before final cutover.

Task records under Incidents, Changes, or Service Requests migrate with assignees, due dates, and completion status. The parent-child relationship to the owning record (Case) is preserved via WhatId. Assignment migrates by resolving the ChangeGear assignee to the mapped Salesforce User ID.

File attachments linked to Incidents, Changes, or Knowledge Articles are migrated via URL reference extraction and direct upload to Salesforce Files (ContentDocument and ContentVersion). We flag any attachment exceeding Salesforce's 25 MB per file limit for customer decision on whether to host externally and link. ChangeGear attachments stored in a non-extractable format are documented in the attachment inventory for manual retrieval.

Custom fields on Incidents, Changes, Service Requests, and other objects require explicit field-level mapping. We extract the custom field schema from ChangeGear, compare it to the destination org's field inventory, create missing fields with equivalent data types, and apply a type-transformation function for fields with incompatible formats between systems. Picklist-dependent custom fields are validated against Salesforce picklist whitelists before import.