Helpdesk migration

Migrate from Fernand to Gorgias

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

Fernand logo

Fernand

Source

Gorgias

Destination

Gorgias logo

Compatibility

83%

10 of 12

objects map 1:1 between Fernand and Gorgias.

Complexity

CModerate

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from Fernand to Gorgias is a shift from a keyboard-first SaaS helpdesk to an e-commerce-native platform built around per-ticket pricing and Shopify order context. Fernand organizes support around Conversations with threaded Replies and attaches Customers as contacts, while Gorgias uses Tickets with a Messages thread and a Customers object. The primary migration challenge is Fernand's lack of a documented bulk export endpoint: we extract records via the REST API in paginated batches, falling back to per-record retrieval if no bulk method exists. Custom Data payloads (the fetched API response data stored per conversation) transfer as static ticket fields, but the endpoint configuration that drives the fetch does not carry over. We document the original Custom Data setup so your team can rebuild the integration in Gorgias using their Rules and Macros system. GitHub and Linear issue links become static text fields on the migrated ticket; the auto-reopen behavior does not replicate without a native Gorgias equivalent integration.

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

Fernand logo

Fernand

What's pushing teams away

  • Small review base makes it hard to assess long-term reliability compared to more established helpdesk platforms.
  • Limited integrations beyond GitHub, Linear, and Stripe may constrain teams needing deeper CRM or telephony connections.
  • Smaller vendor risk for bootstrapped teams who worry about product continuity and long-term support availability.

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

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

Fernand

Conversation

maps to

Gorgias

Ticket

1:1
Fully supported

Fernand Conversations map to Gorgias Tickets. The conversation subject becomes the ticket subject. Conversation status (open, pending, resolved, closed) maps to Gorgias ticket status values. Priority and assignee from Fernand carry over as ticket priority and agent assignment. The original Fernand conversation ID is stored in an external_id field for reconciliation. Channel type (email, chat) from Fernand's channel field maps to Gorgias's channel field on the ticket.

Fernand

Reply

maps to

Gorgias

Message

1:1
Fully supported

Each Fernand Reply within a Conversation maps to a Gorgias Message on the corresponding Ticket. The reply body, author (agent name and email), creation timestamp, and internal/external flag migrate. If the reply was generated by Fernand's AI drafting feature, the message author reflects the original agent who sent or saved the draft. Message ordering is preserved by created_at timestamp within the ticket thread.

Fernand

Customer

maps to

Gorgias

Customer

1:1
Fully supported

Fernand Customers map directly to Gorgias Customers. The customer email address serves as the primary deduplication key during import. Name, email, and any custom properties migrate to Gorgias Customer fields. Custom property types (string, boolean, number) map to Gorgias custom field types (text, boolean, number) on the Customer object. If Fernand stores phone or language, those map to the corresponding Gorgias Customer fields.

Fernand

Custom Data

maps to

Gorgias

Custom Field (Ticket)

lossy
Mapping required

Fernand Custom Data consists of two parts: the API endpoint configuration (URL, headers, auth) and the fetched payload per conversation. We export the fetched payload as static ticket data, stored in a Gorgias custom text field per conversation. The original endpoint URL and header configuration are documented in the migration handoff report. The team recreates the data fetch logic in Gorgias using a Rules action that calls the external API or uses a webhook-based approach. This is a manual rebuild, not an automated migration.

Fernand

User / Agent

maps to

Gorgias

User

1:1
Fully supported

Fernand active users (those who can reply to customers) map to Gorgias Agents. We resolve by email match. Passive collaborators without a Gorgias agent equivalent are documented in the handoff with a recommendation to provision them as agents or tag them in the customer record. Agent role and permission level from Fernand do not have a direct equivalent in Gorgias without manual configuration post-migration.

Fernand

Tag

maps to

Gorgias

Tag

1:1
Fully supported

Fernand conversation tags migrate as Gorgias Ticket Tags. Tag names and counts are preserved. Tag usage frequency is noted in the handoff report. If the team uses tags for routing or priority logic, the Gorgias Rules equivalents are documented in the automation rebuild section.

Fernand

GitHub Link

maps to

Gorgias

Custom Field (Ticket)

1:1
Fully supported

Fernand GitHub integration links (issue URL, issue number, current status) migrate as static text fields on the Gorgias Ticket. The live auto-reopen behavior (Fernand reopening a conversation when a GitHub issue changes state) does not replicate because Gorgias has no native GitHub sync. We document the linked issue URLs so the team can manually reference them or build a Gorgias Rule using a GitHub webhook for equivalent behavior.

Fernand

Linear Link

maps to

Gorgias

Custom Field (Ticket)

1:1
Fully supported

Linear integration links migrate as static text fields on the Gorgias Ticket, similar to GitHub links. The Linear issue reference and any linked team or project context are stored. The auto-reopen behavior does not carry over. We document the linked Linear issues for manual reference.

Fernand

Attachment

maps to

Gorgias

Attachment

1:1
Fully supported

File attachments on Fernand conversations and replies are downloaded and re-uploaded to the corresponding Gorgias Ticket Message. Original filenames and MIME types are preserved. Image attachments sent via the customer widget are included. We verify attachment integrity by comparing file hash before and after upload.

Fernand

Channel

maps to

Gorgias

Channel

1:1
Fully supported

Fernand channel type (email, chat) per conversation maps to Gorgias channel field on the Ticket. Email conversations migrate with full email thread context. Chat conversations migrate the message history as Messages on the ticket. Any channel types in Fernand that have no Gorgias equivalent are documented with a recommendation for the nearest channel mapping.

Fernand

Stripe Integration Data

maps to

Gorgias

Shopify Order Context (Gorgias native)

lossy
Fully supported

Fernand's Stripe integration provides payment context per conversation. Gorgias provides native Shopify order context natively, including order status, line items, and fulfillment state. For teams migrating from Stripe on Fernand to Shopify on Gorgias, we document the original Stripe payment references as a ticket custom field. If the team continues using Stripe without Shopify, the payment context is stored as a static field and the team can explore Gorgias's webhook Rules for future payment-status-triggered routing.

Fernand

AI Draft History

maps to

Gorgias

Message (via Agent)

1:1
Fully supported

Fernand AI-generated draft replies are included where the API exposes them. These migrate as Messages on the ticket with the original agent authorship reflected (since the draft was associated with a specific agent before sending). The AI generation context is not preserved as a separate flag. Gorgias AI features (Gorgias AI Agent, automated responses) are configured separately post-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.

Fernand logo

Fernand gotchas

High

Fernand has no documented bulk export endpoint

Medium

Custom Data configuration does not migrate as code

Medium

GitHub and Linear sync state does not carry over

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

  • Fernand has no confirmed bulk export endpoint

    Fernand's API is documented around Custom Data fetching and integrations rather than data export. We use the available REST API with Bearer token authentication to pull records in paginated batches. If the API lacks a bulk endpoint, we fall back to per-record retrieval which increases migration time for large conversation histories. We confirm API capabilities during discovery before committing to a timeline. This is the highest-risk gotcha for this pair and drives timeline estimates significantly.

  • Custom Data configuration does not migrate as code

    Fernand Custom Data stores API endpoint URLs, header names, and fetched payloads per conversation. We export the payloads as static conversation fields in Gorgias, but the endpoint configuration (URLs, auth headers, refresh logic) is platform-specific. The team must rebuild the fetch logic in Gorgias using Rules with HTTP actions or a third-party integration. We document the original Custom Data schema in the migration handoff so the rebuild has a reference.

  • GitHub and Linear sync state does not carry over

    Fernand's GitHub and Linear integrations track issue linking and auto-reopen conversations when issue status changes. These automation rules and linked issue references export as static conversation fields. The live sync behavior does not transfer; conversations will not auto-reopen at Gorgias when GitHub or Linear issues change state. The team documents the linked issues in the handoff and rebuilds the webhook logic in Gorgias Rules if needed.

  • Fernand automation rules have no Gorgias equivalent to migrate

    Fernand's GitHub and Linear integrations represent the primary automation surface in the platform. These are not generic rule builders and have no direct Gorgias analog without rebuilding. We do not migrate automations as code. We deliver a written inventory of every Fernand integration configuration with recommended Gorgias Rules equivalents. Macros and Rules in Gorgias are rebuilt by the customer's admin post-migration.

  • Gorgias per-ticket pricing requires volume audit before migration

    Gorgias charges per billable ticket, and ticket volume on Fernand may not map directly because of how each platform defines a ticket versus a conversation. Fernand may count multi-reply conversations as one conversation, while Gorgias counts billable tickets by channel events. We run a pre-migration volume audit comparing Fernand conversation counts against estimated Gorgias billable ticket counts so the team selects the correct Gorgias plan before migration begins and avoids overage surprises.

Migration approach

Six steps for a successful Fernand to Gorgias data migration

  1. Discovery and API capability audit

    We audit the Fernand account for conversation volume, reply count, custom field configurations, active user count, channel types, tag usage, and any active GitHub or Linear integrations. We test the Fernand API to confirm whether a bulk export endpoint exists or whether we are working with paginated per-record retrieval. We also audit Gorgias destination settings, existing custom fields, and channel configurations. The discovery output is a written migration scope, an API capability confirmation, and a Gorgias plan recommendation based on estimated billable ticket volume.

  2. Schema design and custom field pre-creation

    We pre-create custom fields in Gorgias to receive Fernand Custom Data payloads, GitHub and Linear link fields, and any custom properties from the Fernand Customer object. Custom fields are created via the Gorgias API (object_type: Ticket or Customer) with the appropriate type (text, boolean, number). We document the mapping between each Fernand Custom Data field and its Gorgias destination field name. Schema is validated in a Gorgias test environment before production migration.

  3. Sample migration and reconciliation

    We run a test migration with 50-100 Fernand conversations into Gorgias to validate field mapping accuracy, attachment integrity, reply thread ordering, and customer deduplication. The customer spot-checks migrated records against the Fernand source and confirms that Custom Data payloads land in the correct custom fields. Any mapping corrections are made before the full migration begins. This step also confirms the API extraction rate for timeline estimation.

  4. Customer and agent provisioning

    We extract every distinct Fernand Customer and map them to Gorgias Customers by email deduplication. Active Fernand users are mapped to Gorgias Agents by email match. Any Fernand user without a matching Gorgias agent account goes to a reconciliation queue for the customer to provision before record import resumes. Passive collaborators are documented with a recommendation to either provision them as agents or exclude them from the migration.

  5. Full migration in dependency order

    We run the full migration in dependency order: Customers (first, as ticket references), Users/Agents (validated), then Conversations mapped to Tickets with Messages, Tags, Attachments, Custom Data payloads, and integration link fields. GitHub and Linear links are stored as static text fields during this phase. Each phase emits a row-count reconciliation report. If the Fernand API lacks a bulk endpoint, we use batched pagination with exponential backoff on rate limit responses.

  6. Cutover, validation, and automation rebuild handoff

    We freeze Fernand writes during cutover, run a delta migration of any records modified during the migration window, then mark Gorgias as the system of record. We deliver the automation rebuild inventory documenting every Fernand integration configuration (GitHub links, Linear links, Custom Data endpoints) with recommended Gorgias Rules equivalents. Macros and workflow rebuilds are outside migration scope and handled by the customer's admin or a Gorgias implementation partner.

Platform deep dives

Context on both ends of the pair

Fernand logo

Fernand

Source

Strengths

  • Transparent pricing at $29/active user with unlimited features and no per-conversation caps.
  • AI reply drafting built into the core inbox experience reduces agent effort on standard queries.
  • Fast, keyboard-first UX with Linear-inspired design appeals to technical SaaS teams.
  • Direct GitHub and Linear integrations create a support-to-engineering feedback loop.
  • 14-day free trial with no credit card lowers the evaluation barrier.

Weaknesses

  • Very small market footprint with limited public reviews and third-party community discussion.
  • API documentation is not publicly indexed in research; bulk export capabilities are not fully confirmed.
  • Limited integration ecosystem beyond GitHub, Linear, and Stripe restricts use cases in complex tech stacks.
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. 4 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 Fernand and Gorgias.

  • Object compatibility

    C

    4 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

    Fernand: Not publicly documented.

  • Data volume sensitivity

    B

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

Estimator

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

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

Can't find your answer?

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

Book a free 30 minute consultation

Most migrations complete in two to four weeks for accounts under 10,000 conversations with a straightforward Customer and Tag structure. Migrations with large Custom Data payloads, multiple channel types, active user counts over 20, or an unconfirmed bulk export endpoint (requiring per-record API iteration) extend to four to six weeks. The primary timeline variable is the Fernand API extraction rate, which we validate during discovery before committing to an estimate.

Adjacent paths

Related migrations to explore

Ready when you are

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