Migrate from Jira Service Management to Gorgias

JSM requests map directly to Gorgias tickets. The JSM summary field becomes the ticket subject, the description becomes the first message body, and priority (Low/Medium/High/Critical) maps to Gorgias priority (1-5 scale). Status mapping requires a custom state translation because JSM uses workflow-driven status categories (Open, In Progress, Resolved, Closed) while Gorgias uses a simpler ticket state model. We apply a status mapping table during import. Created and updated timestamps migrate as-is to preserve the ticket timeline.

Each JSM service project maps to a Gorgias Store, which is the top-level container for settings, channels, macros, and ticket routing. We extract portal URL, branding settings, and allowed email domains from the JSM project configuration and re-apply them to the Gorgias store. Team inbox routing maps to Gorgias user groups configured during import. Multiple JSM projects may map to a single Gorgias store if the customer's service teams consolidate on Gorgias.

JSM request types define the intake form and determine issue subtype. Gorgias has no equivalent request type schema; tickets are categorized by tags and categories. We map each distinct JSM request type to a Gorgias tag with the request type name as the tag value. If the customer uses JSM issue subtypes, we create multiple tags (e.g., request_type:hardware, subtype:laptop). The customer selects tag strategy during scoping.

Public comments on JSM requests migrate to Gorgias messages as public agent replies. The comment body, author (agent name), and timestamp transfer directly. Internal notes from JSM (visible only to agents) migrate as Gorgias internal notes attached to the ticket. We distinguish public and internal via the JSM comment visibility property and set the message visibility field accordingly during import.

JSM customers (portal-only users who submit requests but cannot resolve them) map to Gorgias customers by email address. The JSM customer display name becomes the Gorgias customer name, and any customer portal phone or company attributes map to Gorgias customer fields. We set the customer_type field on every imported user to 'customer' unless the record is explicitly designated as an agent in the migration scope, preventing unintended role assignment.

JSM agents (licensed resolvers) map to Gorgias agents by email. Agent name and email transfer directly. JSM agent groups map to Gorgias user groups, and JSM project team memberships map to Gorgias team assignments. We resolve agents by email match against the destination Gorgias user table.

File attachments on JSM requests and comments are downloaded from Atlassian's CDN and re-uploaded to the Gorgias ticket. We preserve original filenames and attach them to the corresponding ticket message. Large attachment batches are chunked to avoid timeout. JSM attachments linked to internal notes attach as internal notes in Gorgias.

JSM Knowledge Base articles live in Confluence spaces linked to a service project. We extract articles from the linked Confluence space, including article body (HTML), title, labels, and space permissions. Articles import to Gorgias Help Center with the same title and body content. Space permissions must be manually re-applied post-import. Gorgias Help Center articles are public-facing by default; we set visibility per article based on the original Confluence space access level.

JSM labels on requests migrate to Gorgias tags. Label names transfer as-is. We create missing tags on the destination Gorgias store during the import phase and append all source labels to each migrated ticket.

JSM issue links (blocks, relates to, duplicate, cloned) have no equivalent in Gorgias. We extract issue links during scoping, validate whether the linked issue exists in the migrated set, and flag any broken links where the target record was not included in the migration scope. The customer receives a written inventory of issue links requiring manual recreation or closure.

The full JSM change history field changes, status transitions, and assignee updates exports via the issue changelog API. We transfer the change log as a series of internal notes on each Gorgias ticket, annotated with the field name, old value, new value, timestamp, and actor. This preserves the audit trail for compliance-conscious teams without requiring a separate audit log system.

JSM SLA goals, starting conditions, and pause conditions do not have a Gorgias equivalent. Gorgias does not support native SLA tracking on any tier. We flag SLA definitions during scoping and exclude them from migration scope. Teams requiring SLA monitoring post-migration must implement a third-party integration or accept that SLA governance is not available in Gorgias without an upgrade.

JSM automation rules (triggers, conditions, Jira-specific actions) do not migrate to Gorgias macros because they are structurally different. JSM automations run on issue lifecycle events with Jira-native actions; Gorgias macros are canned response templates with variable substitution. We extract every active JSM automation rule as a JSON document, map each action to a Gorgias macro equivalent where possible, and deliver a written automation inventory for the customer's admin to rebuild in Gorgias Rule Builder.

JSM Assets objects (object schemas, object types, attributes, and cross-schema references) have no destination in Gorgias. The JSM Assets CSV export captures object data but excludes import configurations, LDAP mappings, and ticket linkages. We reconstruct asset-to-request linkages during extraction and deliver a written asset inventory with ticket associations for the customer to manage outside Gorgias or in a separate CMDB tool post-migration.