Migrate from Servicetonic Helpdesk Tool to Gorgias

Servicetonic Incidents map directly to Gorgias Tickets with a ticket_type discriminator field we set to 'incident'. Incident status, priority (critical/high/medium/low), category, and linked Configuration Items transfer to the corresponding Gorgias Ticket fields and a custom field cf_linked_configuration_item__c carrying the CI identifier. Conversation threads (requester's messages and agent responses) migrate as Gorgias message records preserving the original timestamps and channel metadata. If the source incident references a Service Request via a linked relationship, we resolve the Service Request ticket first, then link both tickets in Gorgias using a custom relationship field.

Servicetonic Service Requests map to Gorgias Tickets with ticket_type set to 'service_request'. Request type, approval status, and fulfillment step transfer to custom fields cf_request_type__c, cf_approval_status__c, and cf_fulfillment_step__c. If the Service Request is linked to a Service Catalog Item in Servicetonic, we record the catalog item identifier in cf_catalog_item__c and include the item in the written Service Catalog inventory document delivered to the customer. Approval workflows do not migrate as code; the approval chain is documented for the admin to configure in Gorgias Flows.

Servicetonic Knowledge Base articles migrate to Gorgias Help Center articles preserving title, body content, attachments, visibility settings, and category assignment. Article category hierarchy in Servicetonic maps to Gorgias article categories; we create the category structure in Gorgias before article import. Internal links within the knowledge base will not update automatically after migration due to ID changes on the destination platform. We flag every internal link found during the audit and deliver a link-replacement checklist for the customer's admin to address post-migration. Visibility flags (internal-only vs public) map to Gorgias's article visibility settings.

Servicetonic Service Catalog entries (service name, description, fulfillment process, price, and associated forms) have no direct Gorgias equivalent. We migrate catalog item metadata as custom fields on the linked Service Request Ticket: cf_catalog_item_name__c, cf_fulfillment_process__c, cf_catalog_price__c. The associated request fulfillment workflow is documented in the Service Catalog inventory deliverable for the admin to model in Gorgias's order management, a linked CMS, or a third-party automation layer. If the customer's Gorgias plan includes a product catalog feature, we assess whether catalog items map to Products in that context during scoping.

Servicetonic end-user requester profiles (name, email, organization, location, contact preferences) map to Gorgias Customer records. Email serves as the dedupe key during import. Organizational affiliation from Servicetonic maps to the Customer's organization field. If the destination Gorgias account is connected to Shopify, we validate the requester email against the Shopify customer database to preserve the ecommerce context layer. Contact preferences migrate as a custom field or as the customer's notification settings in Gorgias.

Servicetonic agents (staff members with role, team, and permission profiles) map to Gorgias Agent profiles. Agent identity and team assignment transfer directly. Permission level mapping depends on the Gorgias plan: at the Starter tier, all agents have equal permissions; at higher tiers, we map Servicetonic role levels (agent/supervisor/admin) to the corresponding Gorgias permission tier. Any agent without a matching email in the destination Gorgias account is placed in a reconciliation queue for the customer's admin to provision before the record import phase.

Servicetonic Configuration Items (IT assets, systems, and components linked to incidents and requests) do not have a native equivalent in Gorgias. CI type, name, and location transfer to a custom ticket field cf_configuration_item__c on the linked Ticket. Custom CI-to-CI relationships are not representable in Gorgias's flat ticket model; we document every relationship found during the audit in the CI Relationship Map deliverable. If the customer maintains a separate asset management system (e.g., Snipe-IT, ServiceNow CMDB), we recommend linking CI identifiers as external references in the custom field rather than attempting to replicate the relationship graph.

Servicetonic SLA definitions tie response and resolution targets to priority level, request type, and time plans referencing business-hour calendars and time zones. We preserve the SLA metric values (first response target in hours, resolution target in hours) in custom fields cf_sla_response_target__c and cf_sla_resolution_target__c on the Ticket. The time-zone-aware calendar model does not map directly to Gorgias's SLA policy structure, which uses a simpler schedule model. We flag every non-standard SLA calendar during the mapping phase, list the calendar's working hours and time zone, and call out the discrepancy for customer approval before import. SLA compliance reporting against these migrated targets is available via Gorgias's reporting module using the custom fields as data points.

Attachments associated with Incidents, Service Requests, and Knowledge Articles migrate as Gorgias attachments linked to the corresponding Ticket message or Help Center article. File size and format are preserved. Attachments exceeding Gorgias's size limit (typically 25 MB per file) are flagged during the audit and handled according to the customer's preference: compressed, hosted externally with a link embedded in the ticket, or excluded with documentation.

Servicetonic Change Records (part of the full ITSM module available at the Enterprise and On-Premise tiers) represent change requests with impact assessment, approval chains, and implementation plans. These do not map to Gorgias's ticket model. We extract Change Record metadata as a standalone CSV deliverable for the customer's records and do not import them into Gorgias. If the customer continues to require change management tracking, we recommend a separate ITSM tool.

Servicetonic Problem Records (root-cause analysis records linked to multiple Incidents) do not have a Gorgias equivalent. We extract Problem Record data as a CSV deliverable for the customer's records, noting the linked Incident IDs so the relationship can be reconstructed manually in a linked system if needed. Problem-to-Incident linkage is documented in the deliverable for the admin to assess for external tracking.

Servicetonic customer satisfaction surveys linked to resolved tickets migrate as custom fields on the Gorgias Ticket: cf_csat_score__c and cf_csat_submitted_at__c. The survey form structure itself does not migrate; we document the survey questions in the deliverable for the admin to configure in Gorgias's native satisfaction survey or a third-party tool like Delighted or Wootric if the customer continues to use one.