Migrate from Serviceaide ChangeGear to Zendesk

ChangeGear Incidents map 1:1 to Zendesk Tickets. We extract Incident status (New, In Progress, On Hold, Resolved, Closed), priority (Critical, High, Medium, Low), category, assignee, and all timestamps including first_response and resolution_time. We add a custom field cg_incident_id__c and a tag changeGear-incident so migrated records are identifiable post-migration. Related Configuration Item references from ChangeGear migrate as a text field or custom field holding the CI identifier; Zendesk does not have a native CI model so the relationship is preserved as data rather than a linked object.

ChangeGear Service Requests map to Zendesk Tickets with the request_type field set to service_request. Service Request fulfillment records and approval steps become ticket comments or custom fields documenting the fulfillment path. Unlike Incidents, Service Requests in ChangeGear often have a defined catalog item; we map catalog item name to a custom field so the customer can rebuild request templates in Zendesk Forms post-migration.

Change records (CAB approvals, risk assessments, implementation timelines) have no direct Zendesk object. We do not force Changes into the ticket model. Instead, we export Change records to a structured JSON artifact including Change ID, type (Standard, Normal, Emergency), risk score, approval chain status, and implementation schedule. The customer uses this as a compliance audit record or imports it into a dedicated CMDB. Zendesk Enterprise Plus supports Data Center locations for data residency but does not offer a change management module.

Problem records in ChangeGear link to related Incidents via a known relationship type. Zendesk does not have a Problem object. We export Problems with their linked Incident IDs as a JSON artifact and deliver a mapping table so the customer can maintain the relationship in an external system or rebuild it via a Zendesk custom object if they add Service Cloud. Problem resolution notes and known-error workarounds migrate as tagged comments on the linked Tickets.

ChangeGear Knowledge Articles migrate to Zendesk Help Center articles. We extract full article body (with HTML or markdown formatting preserved), title, category, author, publication status (Draft, Published, Archived), and attachment references. Zendesk's Help Center article permissions (public, authenticated, restricted) are mapped from ChangeGear's visibility settings. We download-and-reupload attachments linked to articles; article images are migrated as direct URL references or re-uploaded to Zendesk's media library.

Hardware and software asset records in ChangeGear (including license counts, warranty status, last-seen dates, and decommission flags) have no native Zendesk equivalent. We export assets to a structured CSV/JSON artifact organized by asset type, location, and assignment. The customer can import this into a dedicated CMDB, a Zendesk Marketplace asset management app, or maintain it as a reference document. Active decommission flags are preserved in the export for audit compliance.

CIs in ChangeGear form a relational graph with dependency links, affected services, and linked Incidents. Zendesk does not have a CI model. We export CI records as a structured artifact including CI name, type, location, serial number, linked parent CI, child CIs, and affected services. We deliver a CI relationship matrix so the customer can import into a dedicated CMDB or maintain the dependency map outside Zendesk. If the customer has Zendesk Explore or a Marketplace CMDB app, we map the export fields to the destination's expected schema.

ChangeGear Users migrate to Zendesk Users. We map ChangeGear agent users to Zendesk agents and admins, preserving role-based access flags (which become Zendesk Agent or Admin roles). End users from ChangeGear (submitter accounts) map to Zendesk end-users. We resolve by email address as the dedupe key. Group memberships from ChangeGear map to Zendesk Groups, which are used for ticket routing and assignment. Any ChangeGear user with a role in the CAB (Change Advisory Board) is tagged in Zendesk for admin visibility but Zendesk does not enforce CAB segregation.

ChangeGear Groups migrate to Zendesk Groups. Group hierarchies in ChangeGear flatten into Zendesk Group names; Zendesk Groups do not have a hierarchical structure. We preserve the top-level group name and flag sub-group relationships in a supplementary mapping document for the customer to consolidate or recreate in Zendesk Views.

ChangeGear SLA definitions (priority-to-SLA mappings, response and resolution breach thresholds, business-hours calendar) map to Zendesk SLA Policies. We extract the active SLA calendar from ChangeGear, validate it against Zendesk's business-hours schedule configuration, and flag any mismatch in breach times before the migration. SLA conditions based on ChangeGear-specific fields (Change Type, CI Category) become conditions in Zendesk's SLA Policy builder or are noted for manual configuration post-migration.

ChangeGear Tasks under Incidents or Service Requests migrate as internal notes on the parent Zendesk Ticket with a task-migrated tag. The task assignee, due date, and completion status are documented in the note body. If the customer uses the Zendesk Tasks add-on (available on Suite Enterprise and above), we map tasks to Zendesk Tasks objects instead. Task subtasks in ChangeGear flatten into a single task note with hierarchy documented in the comment.

File attachments linked to Incidents, Service Requests, or Knowledge Articles migrate via download-and-upload to Zendesk's media library. We preserve the original filename, MIME type, and attachment order within the ticket comment. Attachments exceeding Zendesk's 50 MB per-file limit are flagged for the customer to host externally and link via URL. All migrated attachments receive the original upload timestamp to preserve audit ordering.