Helpdesk migration

Migrate from eTicket to Gorgias

Field-level mapping, validation, and rollback between eTicket and Gorgias. We move data and schema; workflows are rebuilt natively in Gorgias.

eTicket logo

eTicket

Source

Gorgias

Destination

Gorgias logo

Compatibility

75%

9 of 12

objects map 1:1 between eTicket and Gorgias.

Complexity

CModerate

Timeline

1-3 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

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.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

eTicket logo

eTicket

What's pushing teams away

  • The project is effectively dormant — the latest documented release (1.7.3) is from October 2008, with no modern development cadence, leaving customers exposed to unpatched dependency and security issues.
  • No public API and no modern integration story — teams that want to connect helpdesk data to CRM, BI, or modern automation tools have no native path.
  • PHP and MySQL stack assumptions are dated; deploying on modern hosting often requires patching PHP compatibility issues that the upstream project does not address.
  • Limited reporting and analytics — eTicket is a basic queue-and-conversation tool, with no SLA timers, no advanced workflow, and no dashboard depth that modern helpdesks ship by default.
  • Migration paths to modern helpdesks (Zendesk, Freshdesk, Help Scout) are entirely manual — there is no published export tool or supported migration partner, so teams must scrape the MySQL database directly.

Choosing

Gorgias logo

Gorgias

What's pulling them in

  • Shopify-native integrations pull order details, shipment status, and return data directly into the ticket view, eliminating the need for agents to switch between apps.
  • Unlimited user seats mean growing support teams do not trigger billing changes; pricing scales only on billable ticket volume.
  • AI Agent automates responses to high-volume queries like order status and returns, measurably reducing the number of billable tickets each month.
  • Omnichannel inbox consolidates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.
  • SOC 2 Type II certification and GDPR-aligned data handling satisfy enterprise procurement requirements for customer support platforms.

Object mapping

How eTicket objects map to Gorgias

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

maps to

Gorgias

Ticket

1:1
Fully supported

eTicket 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

maps to

Gorgias

Customer

1:1
Fully supported

eTicket 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

maps to

Gorgias

User

1:1
Fully supported

eTicket 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

maps to

Gorgias

Team

1:1
Fully supported

eTicket 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

maps to

Gorgias

Message

1:1
Fully supported

eTicket 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

maps to

Gorgias

Attachment

1:1
Fully supported

eTicket 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

maps to

Gorgias

Tag

1:1
Fully supported

eTicket 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

maps to

Gorgias

Custom Field (Ticket type)

lossy
Fully supported

eTicket 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

maps to

Gorgias

Article

1:1
Fully supported

eTicket 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

maps to

Gorgias

Help Center Category

1:1
Fully supported

eTicket 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

maps to

Gorgias

SLA Policy (not migrated)

lossy
Fully supported

eTicket 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

maps to

Gorgias

Rule (not migrated)

lossy
Fully supported

eTicket 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.

Gotchas + challenges

What specifically takes care here

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 logo

eTicket gotchas

High

Project is effectively dormant — latest release dates to 2008

High

No public API or vendor-supported export tooling

Medium

Attachments live on disk and can be orphaned

Medium

No SLA, automation, or modern routing engine

Gorgias logo

Gorgias gotchas

High

AI Agent adds outcome-based fees on top of billable ticket costs

High

Overage billing for tickets scales nonlinearly

Medium

API rate limits restrict bulk export throughput

Medium

Agent data visibility cannot be restricted by role for GDPR use cases

Low

Knowledge Base translations require separate API calls per locale

Pair-specific challenges

  • Gorgias supports only Open and Closed ticket statuses

    eTicket commonly uses more than two statuses (Pending, On-Hold, Resolved, Waiting on Customer) that have no direct Gorgias equivalent. We map all non-Open eTicket statuses to Closed in Gorgias and apply a tag (pending, on_hold, waiting) so that the customer's admin can create a Gorgias View to surface these tickets without changing their status. Skipping this mapping results in imported tickets with an inconsistent or lost status that agents cannot filter from the default queue.

  • Gorgias custom fields must be declared before ticket import

    The Gorgias REST API enforces that any custom field referenced on a ticket must already exist in the destination account. We pre-create all eTicket custom ticket fields using POST /custom-fields with the correct type (Ticket or Customer) and data type (text, number, boolean, date, dropdown, multi-select) before any ticket records are inserted. Fields declared after ticket import begins cause partial record inserts that require a correction run. This is a platform constraint, not a FlitStack AI limitation, and we handle it in our standard pre-flight phase.

  • Gorgias does not migrate attachments via native import tools

    Gorgias native Zendesk migration and Help Desk Migration app do not transfer file attachments. We handle attachments by downloading from eTicket, re-uploading to Gorgias via the message attachments endpoint, and linking the returned attachment_id to the target Message. This adds per-attachment API round-trips and requires that the total attachment volume be included in migration scoping. Files over 25 MB (the Gorgias API limit) are flagged for manual handling or alternative storage.

  • Disable Gorgias automation rules before migration

    Gorgias Rules that fire on ticket creation or update can conflict with imported records, causing duplicate responses, incorrect status overrides, or unwanted macro applications during the migration window. We require the customer to disable all active Gorgias Rules (Automation > Rules) before migration begins and re-enable them after cutover. This is documented in the Gorgias Help Desk Migration checklist and confirmed in our pre-flight checklist.

  • Gorgias CSV export omits message body text

    Gorgias CSV export (available via Settings > Exports) includes ticket metadata (assignee, tags, statistics, timestamps) but does not include the actual message body content. If the customer uses Gorgias CSV export as a source during migration scoping, we flag that message content must come from API export or the original eTicket data. This affects the scoping audit but not the production migration path, which uses eTicket API as the primary source.

Migration approach

Six steps for a successful eTicket to Gorgias data migration

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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

Context on both ends of the pair

eTicket logo

eTicket

Source

Strengths

  • Free and open-source self-hosted PHP/MySQL helpdesk.
  • Email-to-ticket (pop3/pipe) and web-form ticket creation in the core distribution.
  • Skinnable to match the host website's branding.
  • Multi-lingual UI and CAPTCHA / spam filtering included.
  • Full database ownership for teams that need on-premise data control.

Weaknesses

  • Project is effectively dormant; last release in October 2008.
  • No public API or supported migration tooling — exports go through direct MySQL queries.
  • No SLA engine, no automation rules, no modern reporting.
  • PHP / MySQL stack compatibility issues on modern hosting are not addressed upstream.
  • Limited third-party community or commercial support for new deployments.
Gorgias logo

Gorgias

Destination

Strengths

  • Shopify and BigCommerce integrations surface order, return, and shipment data natively inside every ticket.
  • Unlimited agent seats remove per-user licensing friction as support teams grow.
  • AI Agent reduces billable ticket volume through automated resolution of high-frequency queries.
  • SOC 2 Type II certified with GDPR-aligned data handling for enterprise procurement readiness.
  • Omnichannel inbox aggregates email, live chat, Facebook, Instagram, WhatsApp, SMS, and voice into a single threaded view.

Weaknesses

  • Ticket-volume pricing with overage fees creates unpredictable monthly costs during seasonal traffic spikes.
  • Custom reporting is shallow; raw event-level data export for BI tooling is not natively supported.
  • Knowledge Base, Macros, and Rules lack simple export tooling, making competitive migrations complex.
  • GDPR compliance limitations mean customer data cannot be hidden from agents by role, blocking use by teams with freelance staff.
  • Performance and glitch reports emerge in G2 reviews at higher ticket volumes.

Complexity grading

How hard is this migration?

Moderate Helpdesk migration. 6 of 7 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across eTicket and Gorgias.

  • Object compatibility

    D

    6 of 7 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    eTicket: Not applicable — no API surface exists..

  • Data volume sensitivity

    B

    eTicket doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your eTicket to Gorgias migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about eTicket to Gorgias data migrations

Answers to the questions buyers ask most during eTicket to Gorgias migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your eTicket to Gorgias migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most migrations land between one and three weeks for accounts under 5,000 tickets and 2,000 customers without knowledge base content. Migrations with knowledge base articles, attachment-heavy histories (over 50 GB), or more than 20 custom ticket fields extend to four to seven weeks because of the pre-creation phase, sample reconciliation, and Knowledge Base article structure mapping. The Gorgias API rate limit (approximately 720 tickets per hour for native import) does not directly apply to our REST API approach, but batch sizing and backoff add incremental time for accounts above 10,000 tickets.

Adjacent paths

Related migrations to explore

Ready when you are

Move from eTicket.
Land in Gorgias, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day