Helpdesk migration

Migrate from Seraph to Gorgias

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

Seraph logo

Seraph

Source

Gorgias

Destination

Gorgias logo

Compatibility

83%

10 of 12

objects map 1:1 between Seraph and Gorgias.

Complexity

CModerate

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Seraph to Gorgias is a helpdesk platform consolidation with distinct data model differences. Seraph supports ticket-based workflows with customer and agent records, while Gorgias structures its schema around Customers, Tickets, Agents, and Knowledge Base articles with native Shopify variable expansion in macros and rules. We extract Seraph data via its export or API interface, map customer and ticket records to Gorgias Customers and Tickets with preserved timestamps, resolve agent assignments by email match, and inventory macros and rules as a written deliverable for manual rebuild because Gorgias automation is structured differently from Seraph's rule engine. Knowledge Base articles transfer as HTML with category structure preserved. We do not migrate workflows, automated rules, or sequence rules as executable code; these are documented for your team to rebuild in Gorgias Rules, Macros, and Help Center settings post-migration.

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

Seraph logo

Seraph

What's pushing teams away

  • Self-hosting on the Basic tier requires the customer to manage infrastructure, backups, security patches, and uptime.
  • Premium tier (£299/month) is needed for full technical support and customisation — smaller teams may find that gap steep.
  • No public API documentation surfaced on seraphhelpdesk.com.
  • Small customer base relative to mainstream helpdesks (Freshdesk, Zendesk, Help Scout) — limited third-party benchmarking.
  • Customers scaling beyond the Premium tier or needing global multi-region deployment typically migrate to enterprise helpdesks.

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 Seraph objects map to Gorgias

Each row shows how a Seraph 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.

Seraph

Ticket

maps to

Gorgias

Ticket

1:1
Fully supported

Seraph ticket records (ID, Subject, Status, Tags, timestamps) map to Gorgias Ticket. We extract the source ticket ID as external_id on the Gorgias Ticket for audit and future reconciliation. Agent assignment resolves by email match to Gorgias User. Channel (email, chat, social) maps to Gorgias channel field. If Seraph exposes priority or SLA fields, these map to custom ticket fields in Gorgias.

Seraph

Customer

maps to

Gorgias

Customer

1:1
Fully supported

Seraph customer records (Name, Email, Phone, Language, Timezone, custom fields) map to Gorgias Customer. Email is the dedupe key. We map any Seraph customer type field to a Gorgias custom field on Customer. If Seraph stores a note or internal flag per customer, it migrates as a Customer Note or archived custom field. Timestamp history (created_at, updated_at) preserves as migration metadata on the destination record.

Seraph

Agent

maps to

Gorgias

User

1:1
Fully supported

Seraph agent records map to Gorgias User. We match agents by email address. If the destination Gorgias account does not yet have the agent User provisioned, we hold those ticket assignments in a reconciliation queue and assign to a default User until the admin provisions the correct accounts. Role and permissions (admin vs agent) map from Seraph role to Gorgias permission group.

Seraph

Macro (template)

maps to

Gorgias

Macro

1:1
Fully supported

Seraph canned responses or macro templates map to Gorgias Macros. We inventory every macro with its body text, shortcut trigger, and attached conditions. Note that Seraph macro conditions (if-then branching) may not have a 1:1 Gorgias equivalent; we document the gap and recommend rebuilding the conditional logic in Gorgias Rules or as separate Macros with distinct shortcuts. Shopify variable syntax in Seraph macros requires manual verification against Gorgias Liquid-style variable format.

Seraph

Rule or Automation

maps to

Gorgias

Rule

lossy
Fully supported

Seraph automated rules (ticket routing, auto-assignment, trigger responses) do not migrate as executable code. We deliver a written inventory of every active Seraph rule with its trigger event, conditions, and actions, mapped to the closest Gorgias Rule equivalent. Gorgias Rules operate on ticket events (created, updated, channelchanged) and can set assignee, priority, tags, and SLAs. Conditional branching and delay actions are documented as configuration notes for the customer admin to rebuild post-migration.

Seraph

Knowledge Base Article

maps to

Gorgias

Article

1:1
Fully supported

Seraph knowledge base articles with title, body (HTML), category, and tags map to Gorgias Help Center articles. HTML content transfers as-is; inline images require URL re-hosting or re-upload to Gorgias media storage. Category structure in Seraph maps to Gorgias article categories. Published status preserves; draft articles migrate as drafts. Article view counts and feedback ratings do not transfer unless Seraph exposes these as API fields.

Seraph

Attachment

maps to

Gorgias

Attachment

1:1
Fully supported

Ticket attachments migrate to Gorgias ticket attachments via API upload. We handle file type validation (Gorgias accepts common image and document formats), chunk large files above single-request size limits, and verify attachment references on the destination ticket record. Attachments on knowledge base articles migrate as embedded media with updated image URLs.

Seraph

Tag

maps to

Gorgias

Tag

1:1
Fully supported

Seraph ticket tags migrate to Gorgias Ticket Tags. Tags are preserved as a flat list unless Seraph exposes a hierarchical taxonomy, which we flatten to Gorgias-compatible flat tags. Tag usage counts migrate as reference data in the migration audit report.

Seraph

Team

maps to

Gorgias

Team

1:1
Fully supported

Seraph team or group records map to Gorgias Teams. Agent membership in teams preserves. If Seraph uses team-based routing rules, these are flagged as Rule inventory items for manual rebuild in Gorgias.

Seraph

Custom Object (if applicable)

maps to

Gorgias

Custom Object

1:1
Fully supported

If the Seraph instance includes custom record types beyond the standard Ticket/Customer/Agent schema, we map them to Gorgias custom objects or Jira-linked issues depending on the customer's post-migration workflow. Custom object mapping requires pre-migration schema discovery because Seraph's custom object support is not confirmed in available research.

Seraph

SLA Policy

maps to

Gorgias

SLA

lossy
Fully supported

Seraph SLA definitions (first response time, resolution time thresholds per priority) map to Gorgias SLA configurations. If Seraph exposes SLA breach timestamps, these do not retroactively apply to migrated tickets; we set SLA status as not_started or paused pending manual restart in Gorgias.

Seraph

Satisfaction Survey

maps to

Gorgias

Satisfaction Survey

1:1
Fully supported

If Seraph exposes CSAT response history, these migrate as Satisfaction records linked to the migrated Ticket in Gorgias. Score, comment, and timestamp preserve. Note that Gorgias Satisfaction Survey is available on Pro and above plans; Starter tier does not include this feature.

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.

Seraph logo

Seraph gotchas

High

Self-hosted extraction depends on customer-controlled database

Medium

Managed-hosted (Standard/Premium) customers extract through vendor

High

No public API or developer portal

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

  • Seraph data export method determines migration approach

    Available research does not confirm Seraph's API availability, export tooling, or data schema. If Seraph exposes a REST API or structured CSV export, we can automate ingestion. If the platform requires manual CSV assembly or screen-scraping of ticket exports, migration requires a manual data preparation phase before automated ingestion begins. We assess export method during discovery and adjust timeline and pricing accordingly. Teams on self-hosted or legacy Seraph instances should confirm API access with their current provider before scoping.

  • Macro conditional logic does not migrate as executable rules

    Gorgias separates Macros (agent-assist templates triggered manually) from Rules (automated event-triggered actions). Many Seraph platforms use a unified automation model where a single rule both triggers and sends a response. We do not migrate these as executable code because Gorgias Rules and Macros are structurally different. We inventory every Seraph automation with its trigger, conditions, and actions, and deliver a written mapping to the nearest Gorgias equivalent for the customer admin to rebuild. This is a manual post-migration task that must be budgeted separately.

  • Gorgias custom field scoping to Ticket vs Customer objects

    Gorgias custom fields are scoped to specific object types via the object_type parameter on GET /api/custom-fields (Ticket or Customer). Seraph custom fields may not expose their object type in the export. We validate object type for each custom field during discovery by checking field usage on sample records. Fields that appear only on tickets become Gorgias Ticket custom fields; fields that appear only on customer records become Customer custom fields. Fields that appear on both require a design decision during scoping.

  • Shopify variable expansion syntax differs between platforms

    If Seraph macros include order data, customer data, or product data variables, these may use different syntax than Gorgias variable expansion. Gorgias uses Shopify Liquid-style variables (e.g., ticket.customer.email) without requiring Liquid coding. We inventory all variable references in Seraph macros during discovery and provide a syntax translation reference in the macro handoff document. Any macros that reference custom order attributes or third-party variables not supported by Gorgias are flagged for manual rewrite.

  • Satisfaction Survey requires Pro tier or above in Gorgias

    Gorgias CSAT and satisfaction survey functionality is available only on Pro ($300/month) and above. Starter ($50/month) and Basic ($60/month) tiers do not include the satisfaction survey feature. If CSAT history migrates to a Starter or Basic destination, the satisfaction records attach to the tickets but the survey trigger and reporting features are not available. We confirm the destination Gorgias plan during scoping and flag any satisfaction data risk for Starter/Basic destinations.

Migration approach

Six steps for a successful Seraph to Gorgias data migration

  1. Discovery and export method assessment

    We audit the source Seraph instance for record counts (tickets, customers, agents, macros, articles), custom field definitions, team structure, and attachment volumes. The critical deliverable at this step is confirming the export method: REST API with authentication credentials, CSV export capability, or manual export instructions. We also confirm the Gorgias destination account plan (Starter through Enterprise) because satisfaction survey, AI Agent, and advanced rule features tier-gate available functionality. Discovery output is a written migration scope with record counts, field inventory, and export method decision.

  2. Schema design and custom field mapping

    We design the Gorgias schema before any data moves. This includes creating any custom fields on Ticket and Customer objects using the Gorgias custom-fields API, defining Teams and permission groups, and mapping Seraph agent roles to Gorgias permission structures. We resolve the object type (Ticket vs Customer) for each Seraph custom field by sampling usage on source records. Knowledge base category structure maps to Gorgias article categories. Shopify integration credentials are connected during this phase if the destination is on Shopify.

  3. Macro and automation inventory

    We inventory every Seraph macro, canned response, and automated rule. For each item we document: trigger type, conditions, actions, and assigned variables. This inventory is the handoff deliverable for the customer admin to rebuild in Gorgias Macros and Rules post-migration. We do not execute the rebuild inside the migration scope. This step produces a structured spreadsheet with Seraph object reference, recommended Gorgias equivalent, and any syntax gaps that require manual rewrite.

  4. Test migration and reconciliation

    We run a full test migration into the destination Gorgias account using production-like data volume. Customer reconciliation leads: record count verification (tickets in, customers in, agents in), spot-check of 25-50 random ticket and customer records for field-level accuracy, timestamp preservation verification, and attachment link validation. We also validate agent email matching and default assignment for any unreconciled owners. Corrections to field mapping, custom field creation, or team assignment happen here before production cutover.

  5. Production migration with dependency ordering

    We run production migration in dependency order: Users and Teams first (agent provisioning validated), then Customers (email dedupe applied), then Tickets (with Customer and User lookups resolved), then Knowledge Base articles (with media re-hosted), then Attachments (chunked for size), then Tags (applied to migrated tickets). Each phase emits a row-count reconciliation report. Delta migration captures any records created or modified during the migration window. We use Gorgias REST API with rate-limit handling and exponential backoff.

  6. Cutover and rebuild handoff

    We freeze source Seraph writes during cutover, run a final delta migration of records modified since the last sync, then confirm Gorgias as the system of record. We deliver the macro and automation inventory document to the customer admin. We support a five-business-day hypercare window where we resolve data quality issues raised during initial Gorgias use. We do not rebuild Seraph automations as Gorgias Rules inside the migration scope; that is a separate configuration engagement or internal admin task.

Platform deep dives

Context on both ends of the pair

Seraph logo

Seraph

Source

Strengths

  • Free self-hosted Basic tier removes licensing cost.
  • 20-year vendor history with bundled helpdesk, credit control, HR, and analytics features.
  • Three tiers with clear positioning across team sizes.
  • Open-source posture allows code-level customisation by capable customers.
  • Managed hosting available at the £50/month Standard tier.

Weaknesses

  • Self-hosting on Basic tier requires meaningful IT effort.
  • Premium support level requires £299/month commitment.
  • No public API documentation.
  • Small customer base limits independent reviewer corpus.
  • UK-centric — overseas customers find limited regional support.
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. 3 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 Seraph and Gorgias.

  • Object compatibility

    C

    3 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

    Seraph: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

Estimate your Seraph 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 Seraph to Gorgias data migrations

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

Can't find your answer?

Walk through your Seraph 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 two and four weeks for accounts under 10,000 tickets and 2,000 customers with no complex custom field schemas. Migrations with large custom field schemas, knowledge base articles with embedded media, multiple team structures with routing rules, or attachments exceeding 1 GB total volume move to five to eight weeks because of field mapping design, media re-hosting, and rule inventory documentation. The export method (API vs manual CSV) is the primary timeline variable; if Seraph does not expose a structured export, add one to two weeks for manual data preparation.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Seraph.
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