Migrate from ServiceNow IT Service Management to Gorgias

ServiceNow Incidents map to Gorgias Tickets with the state machine transformed to Gorgias status values. ServiceNow Active/On Hold/Resolved/Cancelled/Closed maps to Gorgias Open/Pending/Solved/Closed. Priority from ServiceNow (1-Critical through 5-Low) maps to Gorgias priority (high/normal/low). The incident_number becomes the Gorgias ticket external_id. Caller and affected user map to the Gorgias customer (contact) reference. Assignment group maps to Gorgias team. Short description becomes ticket subject; description and work_notes collapse into the Gorgias ticket body with internal comments flagged as private. SLA breach timers are not recreated in Gorgias; we document SLA thresholds as reference data for the customer's admin to re-implement using Gorgias timers or third-party SLA tooling.

ServiceNow Problem records (linked root-cause investigations separate from incidents) do not have a native Gorgias object. We offer two options during scoping: N:1 merge where all related Incidents are enriched with a Problem reference custom field and the Problem itself is stored as a Gorgias internal note on the primary ticket; or 1:1 where a dedicated custom field problem_id references a Problem record stored as a separate Gorgias custom object if the customer's Gorgias plan supports custom objects. The problem manager assignment maps to an internal tag or assigned agent.

ServiceNow Change Requests carry risk assessments, approval chains, and implementation schedules that Gorgias cannot represent natively. We migrate Change Request number, type (Standard/Normal/Emergency), state, risk level, and schedule dates into Gorgias as custom fields on a Ticket. CAB approval records and approval comments migrate as private internal notes. The customer accepts that the approval workflow itself must be rebuilt in Gorgias as a manual review step or a separate change management tool. Change Freeze Calendar associations are not migrated.

ServiceNow Knowledge Articles migrate to Gorgias Articles. Article title maps to Gorgias title; article text body migrates as Gorgias body (HTML preserved where possible). ServiceNow category hierarchy (parent-child categories) maps to Gorgias folder structure. Active/Retired status in ServiceNow maps to Gorgias published/draft status. Article author and last modified date migrate as metadata. Approval workflows for knowledge articles are not migrated; we flag articles in pending-approval state for the customer's admin to republish post-migration. Variable-set content within articles requires field extraction during transformation.

ServiceNow Fulfiller users map to Gorgias Agents. We resolve by email match against the Gorgias agent list. Active Fulfiller users with incident assignment history are created as Gorgias agents with inbox access. Department, location, and manager fields map to Gorgias agent metadata fields where supported. Inactive ServiceNow users are flagged for review and can be imported as inactive Gorgias agents at the customer's discretion. Requester users (end users submitting requests) do not map to Gorgias agents; they map to Customers/Contacts.

ServiceNow Requester users map to Gorgias Customers. We extract name, email, phone, and department from the Requester record. If the customer is making a request on behalf of an end user, we map to the Gorgias Customer object directly. Users without email addresses require review during scoping; they may need manual creation in Gorgias or email address assignment before migration. Large user volumes (over 50,000 Requesters) require chunked export and a phased customer import in Gorgias.

ServiceNow Groups with members and managers map to Gorgias Teams. Group name becomes Team name; group managers become Team leaders. Group membership maps to agent-to-team assignment. Routing rules in ServiceNow (based on category and assignment group) do not migrate; we document each ServiceNow assignment rule and deliver it as a Gorgias Rules or Split configuration plan for the customer's admin to rebuild post-migration.

ServiceNow Configuration Items in the CMDB have no native Gorgias equivalent. We scope the CI data to identify which CIs are relevant as product or customer references in Gorgias. For CIs that represent physical or logical products, we map them to Gorgias Products (if the customer manages product inventory in Gorgias). For CIs that represent customer-owned assets, we store them as a custom field ci_reference on the Gorgias Customer record. CMDB dependency graphs and parent-child CI relationships are not migrated; we deliver a written CI relationship map for the customer's records.

ServiceNow Service Catalog Items with custom variables and variable sets require disaggregation. Each variable on a catalog item maps either to a Gorgias Ticket custom field (for simple variable types like text, number, boolean) or to a Gorgias Macro that pre-populates ticket fields and body content based on the catalog item. Variable set definitions are exported separately and reconstructed as a set of Gorgias custom fields. Catalog item category and workflow state do not have direct Gorgias equivalents; these map to Gorgias tags and ticket status.

ServiceNow SLA records reference business hours calendars and breach actions that Gorgias cannot natively replicate. We extract SLA names, target durations, and applicable business hours as reference data and store them in a Gorgias custom field sla_definition__c on the Ticket. SLA breach timers are not recreated in Gorgias. If the customer requires active SLA tracking post-migration, we recommend a third-party SLA management integration or a custom Gorgias timer rule rebuilt by the customer's admin.

File attachments on Incidents, Problems, and Change Requests export from ServiceNow via the table API and import into Gorgias as ticket attachments. We chunk large attachment volumes to avoid exceeding ServiceNow API timeouts. Inline images within knowledge article HTML bodies are exported separately and reinserted as Gorgias article image assets. Total attachment volume and storage requirements are estimated during scoping.

Instance-specific custom fields on Incident, Problem, Change Request, and other ServiceNow tables require field-level mapping during discovery. We inventory every custom field by table, extract its type (string, boolean, date, number, reference, choice), and pre-create matching Gorgias custom fields before data import begins. Custom field types that do not have a Gorgias equivalent (such as ServiceNow reference fields pointing to unrelated tables) are converted to string fields with the referenced sys_id or display value stored as text. The customer approves the custom field mapping table before migration.

ServiceNow Workflows and Flow Designer flows are configuration, not data. We do not migrate executable workflows to Gorgias because the execution models are incompatible. We deliver a written inventory of every active ServiceNow Workflow and Flow with its trigger, conditions, and actions, and recommend Gorgias Macros and Rules equivalents for the customer's admin to rebuild post-migration.

ServiceNow Virtual Agent chat logs and NLU training data are not persistently stored as exportable records. Conversation logs, intent classifications, and Virtual Agent training data are ephemeral and unavailable for migration. We note this as a gap in the data coverage report delivered during scoping.