Helpdesk migration
Field-level mapping, validation, and rollback between eTicket and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.
eTicket
Source
Gorgias
Destination
Compatibility
9 of 12
objects map 1:1 between eTicket and Gorgias.
Complexity
CModerate
Timeline
1-3 weeks
Overview
Moving from eTicket to Gorgias is a platform replacement that moves your support data into an eCommerce-native helpdesk with deep Shopify and order-management integration. eTicket stores tickets, customers, agents, teams, and custom ticket fields that map to their Gorgias equivalents, but the two platforms handle status, attachments, and automation differently. Gorgias uses a two-status model (Open and Closed) that requires mapping any eTicket statuses beyond those two before migration. We pre-create custom fields in Gorgias using the /custom-fields endpoint with type set to Ticket or Customer, then use the Gorgias REST API with chunking and exponential backoff to insert tickets in batches that avoid the ~720-ticket-per-hour ceiling of Gorgias native import. We do not migrate eTicket workflows, automations, or SLAs as code; we deliver a written inventory for your admin to rebuild in Gorgias Rules.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a eTicket object lands in Gorgias, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
eTicket
Ticket
Gorgias
Ticket
1:1eTicket Tickets map to Gorgias Tickets with the status mapped from eTicket's status field to Gorgias Open or Closed. Any eTicket status values other than Open or Closed (Pending, On-Hold, Resolved) receive a pending or on_hold tag in Gorgias so that agents can filter using a saved View. We use Gorgias POST /tickets with channel=email or the source channel preserved from eTicket metadata. Created_at and updated_at timestamps migrate directly. Priority and source channel map from eTicket fields to Gorgias priority and channel.
eTicket
Customer
Gorgias
Customer
1:1eTicket Customer records map to Gorgias Customer using email as the primary dedupe key. Name, phone, company, and external_id migrate to the corresponding Gorgias Customer fields. If eTicket stores customer addresses, they migrate to the Customer address object in Gorgias. Shopify customer ID or other external identifiers migrate to the external_id field to preserve the link for order-context features in Gorgias.
eTicket
Agent
Gorgias
User
1:1eTicket Agents map to Gorgias Users. We resolve by email match. Agent name, role (admin, agent), and timezone migrate. Any eTicket agent without a matching Gorgias User goes to a reconciliation queue for the customer's admin to provision before record import. Agent availability and online status are not migrated because Gorgias sets these on login.
eTicket
Team
Gorgias
Team
1:1eTicket Teams map to Gorgias Teams. Team name and any team-level routing rules migrate. We assign the team_id on migrated tickets by resolving the original eTicket team assignment. If eTicket uses team-level SLAs, those do not migrate as Gorgias SLA Policies; we document the original SLA thresholds in the handoff inventory for the admin to configure in Gorgias.
eTicket
Conversation
Gorgias
Message
1:1eTicket conversation messages map to Gorgias Message records linked to the parent Ticket. We preserve message body, sender (agent or customer), timestamp, and channel. Threading order is preserved by setting the message sequence or created_at timestamp correctly. Private internal notes in eTicket map to Gorgias Messages with the private=true flag. Attachments stored on messages migrate as Gorgias message attachments using the attachments API.
eTicket
Attachment
Gorgias
Attachment
1:1eTicket file attachments migrate to Gorgias message attachments. We download the original file from eTicket (via export or direct URL), re-upload to Gorgias using the attachments upload endpoint, and link the returned attachment_id to the target Message. This differs from Gorgias native import tools that do not handle file attachments. Large attachments (>25 MB per Gorgias API limit) are noted in the scoping report for manual handling.
eTicket
Tag
Gorgias
Tag
1:1eTicket Tags migrate to Gorgias Tags. Tags applied at ticket level migrate as tags on the Gorgias Ticket. We preserve the tag string exactly so that any existing Gorgias Rules referencing those tag names continue to function after migration. Tags used for internal classification in eTicket that should not be visible to customers are flagged during scoping for migration as internal-only tags.
eTicket
Custom Ticket Field
Gorgias
Custom Field (Ticket type)
lossyeTicket custom ticket fields require pre-creation in Gorgias before any ticket data inserts. We use the Gorgias POST /custom-fields endpoint with type=ticket, set the field name and data_type matching the eTicket field type (text, number, date, boolean, dropdown). Dropdown options in eTicket map to Gorgias dropdown options list. Multi-select eTicket fields map to Gorgias multi-select custom fields. Fields without a direct Gorgias equivalent are flagged in the scoping report and mapped to a text custom field with the original field name preserved in the field description.
eTicket
KB Article
Gorgias
Article
1:1eTicket Knowledge Base articles map to Gorgias Help Center Articles. We extract article title, body (HTML or Markdown), author, created_at, updated_at, and status (draft, published). If eTicket uses article categories, we map these to Gorgias Help Center categories. Published status maps to published; draft maps to draft. Article view counts and feedback ratings do not migrate because Gorgias Help Center does not expose these as importable fields.
eTicket
KB Category
Gorgias
Help Center Category
1:1eTicket article categories map to Gorgias Help Center categories. Category name, description, and sort order migrate. Articles are re-parented to the correct category during migration based on the original eTicket category assignment. If eTicket supports nested category hierarchies deeper than Gorgias supports, we flatten to the Gorgias maximum depth and document the original hierarchy in the handoff inventory.
eTicket
SLA Policy
Gorgias
SLA Policy (not migrated)
lossyeTicket SLA policies do not migrate as Gorgias SLA Policies because the threshold definitions and escalation rules differ between platforms. We deliver a written inventory of every eTicket SLA policy with its name, applicable ticket filters, first-response target, resolution target, and escalation steps. The customer's admin configures the Gorgias equivalent using Gorgias SLA Policies in the Rules section.
eTicket
Workflow / Automation
Gorgias
Rule (not migrated)
lossyeTicket automations and rules do not migrate as Gorgias Rules. The two systems use different trigger models, condition syntax, and action types. We deliver a written inventory of every active eTicket automation with its trigger, conditions, actions, and recommended Gorgias Rule equivalent. The customer's admin rebuilds these in Gorgias Automation > Rules after migration.
| eTicket | Gorgias | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Customer | Customer1:1 | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Team | Team1:1 | Fully supported | |
| Conversation | Message1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| Custom Ticket Field | Custom Field (Ticket type)lossy | Fully supported | |
| KB Article | Article1:1 | Fully supported | |
| KB Category | Help Center Category1:1 | Fully supported | |
| SLA Policy | SLA Policy (not migrated)lossy | Fully supported | |
| Workflow / Automation | Rule (not migrated)lossy | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
eTicket gotchas
Project is effectively dormant — latest release dates to 2008
No public API or vendor-supported export tooling
Attachments live on disk and can be orphaned
No SLA, automation, or modern routing engine
Gorgias gotchas
AI Agent adds outcome-based fees on top of billable ticket costs
Overage billing for tickets scales nonlinearly
API rate limits restrict bulk export throughput
Agent data visibility cannot be restricted by role for GDPR use cases
Knowledge Base translations require separate API calls per locale
Pair-specific challenges
Migration approach
Scoping and custom field inventory
We audit the eTicket account to extract all record types, custom fields, tags, KB articles and categories, team structures, and agent roles. We use the eTicket API (or CSV export supplemented by API for message content) to build a complete record inventory. We produce a custom field mapping sheet that declares every eTicket custom field with its type, options, and the corresponding Gorgias Custom Field to be pre-created. This phase includes a scoping call with the customer to confirm status mapping, SLA policy inventory, and automation scope.
Pre-create Gorgias schema
Before any record migration, we create all required Gorgias objects using the REST API: Teams (from eTicket Teams), Users (for agent reconciliation), Custom Fields of type Ticket and Customer (per the mapping sheet), Help Center Categories (from eTicket KB categories), and a placeholder Knowledge Base Article for each eTicket article. We configure ticket statuses to match the agreed mapping (all non-Open eTicket statuses to Closed plus tagging). This phase runs in the customer's live Gorgias account so that the schema is ready when migration begins.
Agent and user reconciliation
We extract every distinct eTicket agent and customer email referenced on tickets and match against the Gorgias User and Customer tables. Agents without matching Gorgias accounts go to a reconciliation queue for the customer's admin to provision. Customers without matches are created during migration. Email is the primary dedupe key for both objects.
Sample migration and reconciliation
We run a sample migration using a subset of eTicket data (typically 50-200 tickets, 20-50 customers) into the customer's Gorgias account. The customer reconciles record counts, spot-checks message threading, verifies tag application, confirms custom field values, and validates Knowledge Base article structure. Corrections to the mapping sheet (field types, status mappings, tag handling) happen here before the full migration proceeds.
Full migration in dependency order
We run production migration in dependency order: Teams first, then Users (agents) and Customers, then Knowledge Base Articles and Categories, then Tickets with their Messages and Attachments. Tickets are chunked into batches of 200-500 records to respect Gorgias API rate limits, with exponential backoff on 429 responses. Tags are applied per-ticket using the tags API after ticket insert. The Knowledge Base is published last to avoid orphaned articles. Each phase emits a row-count reconciliation report.
Cutover and handoff inventory
We freeze eTicket writes during cutover, run a final delta migration of records modified during the migration window, then deliver the automation and SLA inventory document to the customer's admin. We re-enable Gorgias Rules after cutover confirmation. We provide a one-week hypercare window for reconciliation issues raised during the first week of live Gorgias operation. Workflow rebuild, SLA configuration, and Rule rebuild are outside standard scope and are documented for the customer's admin or a separate engagement.
Platform deep dives
eTicket
Source
Strengths
Weaknesses
Gorgias
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 6 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across eTicket and Gorgias.
Object compatibility
6 of 7 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
eTicket: Not applicable — no API surface exists..
Data volume sensitivity
eTicket doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during eTicket to Gorgias migration scoping. Not seeing yours? Book a call.
Walk through your eTicket to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave eTicket
Other ways to arrive at Gorgias
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.