Migrate from OpenText Service Manager to Gorgias

OpenText Service Manager Incidents map to Gorgias Tickets. The Incident title becomes the Ticket subject, the description and resolution fields concatenate into the Ticket body, and priority from Service Manager maps to the Gorgias priority or tag field. We preserve the original Service Manager Incident ID in a custom field sm_incident_id__c on the Gorgias Ticket for audit traceability. Incidents are extracted first so their IDs are available for parent-link resolution on related records.

Service Requests in OpenText Service Manager map to Gorgias Tickets. The request category and subcategory from Service Manager become a custom field on the Gorgias Ticket (request_category__c), and the fulfillment notes become ticket comments. Request attachments migrate with their file associations intact. Service requests linked to Knowledge Articles carry the article reference in a custom field so agents can see the source content.

OpenText Change records (with approval stages, risk ratings, implementation plans, and CAB signoff) do not have a native equivalent in Gorgias. We map Change records as Tickets with a custom field change_type__c set to 'Change', a change_id__c field carrying the original Service Manager Change ID, and implementation notes as ticket comments. The approval chain status is preserved as a custom field value. For organizations that need Change audit history, we can create separate Note records per Change and link them to the parent Ticket.

OpenText Problem records (linked known-error records used for root-cause analysis) have no direct Gorgias equivalent. We map Problems as Tickets with a custom field problem_type__c, the Problem title as subject, and the known-error description as the initial comment. We preserve the Problem-to-Incident linkage in a custom field linked_incident_ids__c so the customer can see which tickets were symptoms of the same root cause. Problems that exceed the ticket-level treatment are exported as Note records linked to all related Tickets.

Service Manager Knowledge Articles (with title, HTML/RTF body, author, publish date, status, and category) map to Gorgias Knowledge Base articles. We export articles in structured format and import via the Gorgias knowledge base API. Article category hierarchies from Service Manager map to Gorgias category and subcategory structure. Articles attached to specific Services or service catalogs in Service Manager carry a custom metadata field in Gorgias for category placement. Published status migrates as-is; draft articles are imported as drafts for the customer's admin to publish post-migration.

OpenText Service Manager User and Contact records (name, email, phone, department, site/location, and group membership) map to Gorgias Customer records. The Contact email address is the dedupe key. We extract all unique Contact and Requester records referenced on ticket headers and note that Service Manager's role-based user model (IT operator, approver, self-service user) has no Gorgias equivalent — only the agent identity maps. Group memberships from Service Manager map to Gorgias Team assignments on the agent side and are not applied to Customer records.

OpenText Service Manager operator accounts (login name, display name, email, and group membership) map to Gorgias Agent accounts. We extract operator records by querying all agents referenced on ticket assignments and group memberships. The mapping uses email as the dedupe key. Agents without an email in Service Manager are flagged in reconciliation for the customer's admin to provision a login before migration. Operator permissions and roles do not migrate — Gorgias permission groups are configured post-migration by the admin.

OpenText Service Manager CIs (server names, asset tags, software version, affected service, relationship links) have no native CMDB in Gorgias. We extract CI data as a separate export and map key CI identifiers into Ticket custom fields (ci_name__c, ci_type__c, ci_id__c) so agents can see equipment context on tickets. CI relationship data (which CI caused or is related to which Incident) is preserved as a custom multi-value field (related_cis__c) on the related Gorgias Ticket. The full CI relationship graph does not reconstruct in Gorgias natively.

SMAX services (first-class objects defining fulfillment workflows, SLA rules, and catalog visibility) have no Gorgias equivalent. If the source system is SMAX and service catalog data exists, we extract the service name and map it to a custom field (source_service__c) on the Gorgias Ticket. Service categorization and catalog visibility in SMAX do not map to Gorgias — the customer decides whether to represent service categories as ticket tags, departments, or custom fields post-migration.

OpenText SLA rules (response time, resolution time, business hours calendar, and priority mapping) are not configurable in Gorgias at the same level of granularity. We extract the SLA name, priority mapping, and target values from Service Manager and represent them as read-only custom fields on the Gorgias Ticket (sla_name__c, sla_response_target__c, sla_resolution_target__c). First Response Time and Next Reply Time rules on Gorgias higher tiers can be partially configured to approximate SLA targets but require manual setup post-migration.

Attachments on Incidents, Requests, Changes, Problems, and Knowledge Articles in Service Manager are exported as binary files with their association metadata. We re-import them into Gorgias via the ticket attachment API, re-establishing the file-to-ticket association. Attachments on Knowledge Articles are imported as article attachments. File size limits from Gorgias are checked against the largest attachment before migration begins; oversized files are flagged for manual handling.

Both platforms allow administrators to add custom fields to ticket records. We extract the full Service Manager custom field schema (name, data type, picklist values, display order) and reproduce it in Gorgias via the custom-fields API before ticket import begins. Picklist values migrate as-is. Conditional display rules from Service Manager do not migrate — Gorgias custom field display rules are reconfigured by the admin post-migration. Custom field data migrates with the tickets using the matching field name on the destination.