How to Migrate from Gorgias to Freshdesk: Complete Technical Guide

A Gorgias to Freshdesk migration moves ticket history, customer records, tags, and conversation threads from Gorgias's e-commerce-centric helpdesk to Freshdesk's general-purpose ITSM platform. The records can move. The hard part is preserving conversation context while replacing Gorgias's ecommerce-specific behavior with Freshdesk-native structures.

This guide covers the real API constraints, data model mismatches, and order of operations that determine whether a migration succeeds or quietly loses data. For a broader comparison of Freshdesk against other platforms before committing, see Freshdesk vs Help Scout vs Zendesk: The Operations Lead's Guide.

Why teams migrate from Gorgias to Freshdesk

The primary driver is pricing predictability. Gorgias charges based on monthly ticket volume — a helpdesk ticket becomes billable when at least one message in the thread is sent by a human agent, AI Agent, or a Rule (docs.gorgias.com). Plans range from $10/month (50 tickets) to $900/month (5,000 tickets), with overage charges of $0.25–$0.40 per additional ticket. Seasonal spikes — Black Friday, product launches — can double a monthly bill overnight. Freshdesk uses a per-agent subscription model (Growth at $15/agent/month, Pro at $49, Enterprise at $79), making costs predictable regardless of ticket volume.

Breakeven example: A 15-agent team handling 4,000 tickets/month pays $900/month on Gorgias's Advanced plan. On Freshdesk Pro, that same team pays $735/month ($49 × 15) with no ticket cap. During a peak month with 8,000 tickets, Gorgias costs spike to $2,100+ (overage at $0.36/ticket), while Freshdesk stays at $735. The crossover point where Freshdesk becomes cheaper depends on agent count versus ticket volume — teams with high ticket-to-agent ratios (>200 tickets/agent/month) almost always save on Freshdesk.

The second driver is multi-channel breadth. Gorgias is built for e-commerce: deep Shopify, BigCommerce, and Magento integrations with in-ticket order actions (refund, cancel, edit). But teams that expand beyond e-commerce support — handling IT requests, internal tickets, or B2B support alongside DTC — hit Gorgias's ceiling. Freshdesk offers native SLA management, parent-child ticketing, multi-product support, a full knowledge base with SEO controls, and a customer portal — none of which exist in Gorgias.

The third driver is API capacity. Gorgias's API rate limit of 40 requests per 20 seconds (API key) or 80 requests per 20 seconds (OAuth2) is per-account, shared across all integrations. Freshdesk's Enterprise plan provides 700 calls/min — nearly 6x the throughput for integration-heavy teams.

Core data model differences between Gorgias and Freshdesk

Four architectural mismatches make this migration non-trivial:

1. Status model. Gorgias uses only two ticket statuses: Open and Closed. Freshdesk has a four-stage lifecycle: Open → Pending → Resolved → Closed, plus support for custom statuses on Pro and Enterprise plans. Every Gorgias ticket status must be mapped to one of these stages. There is no 1:1 mapping — you must decide whether closed Gorgias tickets become "Resolved" (status 4) or "Closed" (status 5) in Freshdesk. The distinction matters: Resolved tickets can be reopened by a customer reply, while Closed tickets cannot (by default). This choice also affects SLA reporting — Freshdesk calculates resolution time based on when a ticket reaches Resolved, not Closed.

2. Embedded e-commerce data. In Gorgias, Shopify order details (order number, tracking, item list, refund status) are embedded in the ticket sidebar and accessible via macro variables like {{ticket.customer.integrations.shopify.orders}}. This data is not stored as ticket fields — it is pulled live from Shopify. Freshdesk has no native Shopify sidebar. You must either extract this data during migration and store it in Freshdesk custom fields or private notes, or accept that agents will need to look up orders in a separate tab. Freshdesk Marketplace apps like "Shopify for Freshdesk" can restore some sidebar functionality post-migration, but they do not carry over historical order context from Gorgias.

3. Message threading. In Gorgias, a ticket contains a flat list of messages — each with a channel (email, chat, api, phone, sms, internal-note), a sender, and body_html/body_text. Gorgias also requires at least one message when creating a ticket (developers.gorgias.com). In Freshdesk, a ticket has a description (the first message) and a list of conversations — either public replies or private notes. Internal notes in Gorgias (channel: 'internal-note') map to Freshdesk private notes via POST /api/v2/tickets/{id}/notes. Public messages map to Freshdesk replies.

4. Customer identity. Gorgias customers are built around contact channels — the API lets you filter by channel type and channel address. A single shopper may have email, SMS, Instagram, and Facebook history under one Gorgias customer (developers.gorgias.com). Freshdesk contacts are more traditional: primary email, phone, mobile, twitter_id, other_emails, and optional multi-company relationships. If you do not normalize identities before import, you will create duplicate contacts in Freshdesk. Freshdesk deduplicates contacts by email and returns HTTP 409 if you attempt to create a contact with an email that already exists.

How Gorgias objects map to Freshdesk

Use this mapping as your baseline. Skip the caveats column and you will end up with broken threads, duplicate contacts, or missing ecommerce context.

What data cannot be migrated from Gorgias to Freshdesk?

• Shopify sidebar data. Order history, refund status, and tracking info displayed in Gorgias's ticket sidebar. This data lives in Shopify, not Gorgias. Extract it during migration and store it as Freshdesk custom fields or private notes if you need historical context.
• Macro variables. Any macro referencing {{ticket.customer.integrations.shopify.*}} or similar dynamic variables. These must be rewritten against Freshdesk's placeholder syntax (e.g., {{ticket.cf_shopify_order_id}}) or a Shopify marketplace app.
• Rules and automations. Gorgias's rule engine (triggers, auto-close, intent detection) cannot be exported programmatically. Freshdesk uses Dispatch'r (on ticket creation), Supervisor (time-based), and Observer (on ticket update) rules — different architecture, different configuration.
• Revenue attribution. Gorgias's revenue-per-ticket statistics. Freshdesk does not track this natively.
• Chat widget configuration. Gorgias chat widget settings and styling. Freshdesk uses Freshchat, a separate product with its own configuration.
• Channel and source semantics. Gorgias message via values include e-commerce and social variants like WhatsApp, Instagram, and Facebook that have no default Freshdesk source equivalent. Freshdesk's default source values are narrower: Email 1, Portal 2, Phone 3, Chat 7, Feedback Widget 9, and Outbound Email 10. Unsupported variants should go into a custom field like cf_gorgias_via, not be discarded.
• Multi-language/locale metadata. Gorgias stores language preferences per customer for auto-translated responses. Freshdesk supports multi-language knowledge bases and portals but does not have a per-contact language field exposed via API — store this in a custom field like cf_customer_language if needed for routing.

API rate limits and throughput math

Both platforms enforce rate limits that directly govern migration throughput. Getting these wrong is the #1 cause of failed or incomplete migrations.

Gorgias extraction limits

The Gorgias API uses a leaky bucket algorithm with a per-account limit:

The limit is per account, not per key. If your Shopify integration, analytics sync, and migration script all hit the same account simultaneously, they share the same bucket. During migration, pause non-essential integrations to maximize available throughput.

Gorgias uses cursor-based pagination (offset-based was removed in February 2024) with a maximum of 100 records per page. List endpoints do not support server-side date filtering — all date filtering must happen client-side after fetching.

Gorgias UI exports are capped at 1 million tickets and can take up to 10 hours to process, but they only include ticket metadata — not internal notes, attachments, or customer records. The analytics drill-down export with message content includes only public messages from the most recent 30 days and caps at 100,000 tickets (docs.gorgias.com). For a full-fidelity migration, use the API.

Webhook-based extraction alternative: For delta sync phases, Gorgias supports webhooks that fire on ticket creation, update, and message creation events. Configuring webhooks via POST /api/events can supplement polling-based extraction during the cutover window, reducing API call consumption and latency compared to repeatedly polling GET /api/tickets with client-side date filtering.

Key response headers to monitor: X-Gorgias-Account-Api-Call-Limit (current usage, formatted as used/total) and Retry-After (seconds to wait after a 429).

Freshdesk loading limits

Freshdesk enforces per-minute rate limits by plan, with per-endpoint sub-limits that most migration guides miss. Sub-limits are per-endpoint caps enforced within the overall plan limit — meaning you can exhaust your ticket-creation budget while still having unused capacity on other endpoints.

Note: Sub-limits (marked with ~) are empirically observed thresholds, not officially documented by Freshdesk. Actual limits may vary. Plan for 70% of these values as a safety margin.

The sub-limits are the constraint that kills DIY migrations. Even on a Pro plan with 400 total calls/min, you can only create approximately 160 tickets per minute. Each ticket also needs conversation and note creates (separate API calls), which eat into the same per-minute budget.

Freshdesk uses HTTP Basic Auth with an API key as the username (password left blank). Rate limit headers: X-RateLimit-Total, X-RateLimit-Remaining, X-RateLimit-Used-CurrentRequest (support.freshdesk.com).

All endpoints referenced in this guide use Freshdesk API v2 (base URL: https://yourdomain.freshdesk.com/api/v2/). Freshdesk's legacy API (v1) was deprecated in 2018 and should not be used.

Throughput calculation

For a 100K-ticket migration with an average of 4 messages per ticket on a Freshdesk Pro plan:

• Gorgias read side: 100K tickets ÷ 100 per page = 1,000 list calls. At 2 req/s (API key), that is about 8 minutes for ticket stubs. Then 100K individual ticket fetches for full messages: roughly 14 hours at 2 req/s, or 7 hours with OAuth2 at 4 req/s.
• Freshdesk write side: 100K ticket creates + 400K conversation creates = 500K API calls. At the ~160 ticket creates/min sub-limit, ticket creation alone takes about 10.4 hours. The remaining 400K conversation calls at the overall 400/min budget take another 16+ hours.
• Realistic total: 2–4 days of continuous processing for the data transfer alone, before validation and retries.

At 160 tickets per minute, your theoretical maximum throughput is 9,600 tickets per hour. A dataset of 500,000 tickets takes a minimum of 52 hours of continuous, perfectly optimized API loading. If your script exceeds the limit, Freshdesk returns a 429 Too Many Requests error, and poorly written scripts will drop those records entirely.

Handling the Freshdesk 20 MB attachment limit

Attachments are the most common point of failure in helpdesk migrations.

Freshdesk enforces a 20 MB per conversation attachment size limit on paid plans (15 MB on the free plan). This is a hard limit — the API rejects any attachment exceeding it. Worse, Freshdesk can create the ticket while silently dropping attachments that exceed the threshold (support.freshdesk.com).

Gorgias does not enforce a comparable hard limit on incoming attachments — they are stored as-is from the source channel.

The mitigation strategy:

1. Pre-audit attachment sizes before starting. Query Gorgias messages for attachments and flag any exceeding 20 MB.
2. Files under 20 MB: Download to your middleware and pass to Freshdesk as multipart/form-data via the attachments [] parameter.
3. Files over 20 MB: Upload to external storage (S3, Google Cloud Storage) and inject a public URL into the Freshdesk ticket body or a private note. Use a consistent format like [Attachment: filename.pdf](https://storage.example.com/attachments/filename.pdf) so agents can identify externally hosted files.

Migration approaches: which method fits your team?

Recommendation by scenario:

• Small team (<10 agents, <10K tickets, no custom Shopify data): Third-party tool or DIY if you have a developer available.
• Mid-market (10–50 agents, 10K–200K tickets, Shopify data in tickets): Managed service or experienced engineer with 3–4 weeks dedicated.
• Enterprise (50+ agents, 200K+ tickets, multi-brand, compliance requirements): Managed service with delta sync and UAT phases.

Step-by-step migration architecture

The order of operations matters. Import entities in dependency order or you will create orphaned records and broken relationships.

Phase 0: Set up Freshdesk sandbox

Before touching production data, create a Freshdesk sandbox environment for test migrations. Freshdesk Pro and Enterprise plans include a sandbox instance (accessible via Admin > Sandbox). The sandbox mirrors your production configuration — custom fields, automations, groups — and lets you run a full test migration without risk. If you're on a Growth plan, use a separate Freshdesk trial account as a staging environment (trials last 14 days with API access at 50 calls/min).

Phase 1: Extract from Gorgias

# Extraction order (dependency-safe):
1. GET /api/customers         → All customer records
2. GET /api/tags              → All tags
3. GET /api/users             → All agents
4. GET /api/macros            → All macros (for manual rebuild reference)
5. GET /api/tickets           → All ticket stubs
6. For each ticket:
   GET /api/tickets/{id}/messages → Full conversation thread

Use cursor-based pagination. Set limit=100 on every list call. Follow next_cursor until it returns null. Store raw JSON payloads in a local database (PostgreSQL or MongoDB) before attempting transformations. Implement exponential backoff to handle the leaky bucket rate limits gracefully.

import requests
import time
 
BASE_URL = "https://{domain}.gorgias.com/api"
AUTH = ("your-email@example.com", "your-api-key")
 
def extract_tickets():
    cursor = None
    all_tickets = []
    while True:
        params = {"limit": 100}
        if cursor:
            params["cursor"] = cursor
        resp = requests.get(f"{BASE_URL}/tickets", auth=AUTH, params=params)
        if resp.status_code == 429:
            wait = int(resp.headers.get("Retry-After", 5))
            time.sleep(wait)
            continue
        data = resp.json()
        all_tickets.extend(data.get("data", []))
        cursor = data.get("meta", {}).get("next_cursor")
        if not cursor:
            break
        time.sleep(0.5)  # Pace to stay under 2 req/s
    return all_tickets

Be aware that Gorgias customer endpoints can return a 301 redirect when a customer has been merged into another record. Your HTTP client must follow redirects, and you should resolve merged identities before your final extract (developers.gorgias.com).

Phase 2: Transform and map

1. Map statuses. Gorgias open → Freshdesk 2 (Open). Gorgias closed → Freshdesk 4 (Resolved) or 5 (Closed). Decide based on whether you want closed tickets to be reopenable by customer reply.
2. Map priorities. Gorgias has no native priority field. If you have used tags or custom fields for priority, map them to Freshdesk's 1 (Low), 2 (Medium), 3 (High), 4 (Urgent).
3. Transform custom fields. Rename to cf_ prefix format. Convert enum values to match pre-created Freshdesk dropdown options. Verify you will not exceed plan-level custom field limits (Growth: ~20, Pro: ~50, Enterprise: ~150).
4. Extract Shopify data. If ticket messages contain Shopify order references, parse them and store as structured custom fields (cf_shopify_order_id, cf_order_status, cf_order_total) or append as a formatted private note.
5. Deduplicate customers. Gorgias allows customers with multiple channels. Freshdesk deduplicates contacts by email — creating a duplicate returns HTTP 409. Implement upsert logic: check existence first via GET /api/v2/contacts?email={email}, then create or update.
6. Normalize timestamps. Gorgias stores dates in ISO 8601 format. Freshdesk accepts ISO 8601 but strictly enforces UTC. If your Gorgias instance exports local time, normalize all timestamps to UTC before pushing to Freshdesk, or your historical SLA reporting will be corrupted.
7. Handle GDPR and data residency. If you operate in the EU, verify that your Freshdesk instance's data center region matches your compliance requirements. Freshdesk offers US, EU (Frankfurt), India, and Australia data centers. Moving customer PII between regions during migration may require a Data Processing Agreement update. Document the transfer in your Records of Processing Activities.

Phase 3: Load into Freshdesk

# Load order (dependency-safe):
1. POST /api/v2/companies        → Create companies (if applicable)
2. POST /api/v2/contacts         → Create contacts (deduplicate by email)
3. Create custom ticket fields   → Via Freshdesk admin UI or API
4. POST /api/v2/tickets          → Create tickets with description (first message)
   — or POST /api/v2/imports/tickets on Pro/Enterprise plans
5. POST /api/v2/tickets/{id}/notes → Add subsequent messages as notes
6. PUT /api/v2/tickets/{id}       → Set final status, tags, custom fields

For the ticket load, use the Freshdesk Ticket Import API (POST /api/v2/imports/tickets) instead of the standard Ticket Create endpoint whenever possible. The differences are significant:

// Example Freshdesk Import Payload
{
  "requester_id": 1234567890,
  "status": 5,
  "priority": 1,
  "subject": "Where is my order?",
  "description": "Customer inquired about Shopify Order #9999.",
  "created_at": "2023-01-15T14:30:00Z",
  "custom_fields": {
    "cf_gorgias_ticket_id": "48291",
    "cf_shopify_order_id": "9999",
    "cf_gorgias_via": "email"
  },
  "tags": ["order-inquiry", "shopify"],
  "comments": [
    {
      "body": "Your order has shipped. Tracking: 1Z999AA10123456784",
      "created_at": "2023-01-15T15:00:00Z",
      "user_id": 987654321
    }
  ]
}

Store the original Gorgias ticket ID in a dedicated custom field like cf_gorgias_ticket_id. This makes re-runs and reconciliations queryable:

GET /api/v2/search/tickets?query="cf_gorgias_ticket_id:48291"

Build a Dead Letter Queue (DLQ). When Freshdesk rejects a payload — malformed email, oversized attachment, rate limit hit, HTTP 409 duplicate — log the exact Gorgias ID, the Freshdesk HTTP status code, the error response body, and the original payload. This lets you patch the specific data issue and replay failed records without restarting the entire multi-day load process. Implement the DLQ as a database table or a message queue (Redis, SQS) with retry counters.

For parent/child relationships and linked records, Freshdesk handles threaded history via the Conversation object linked to a parent Ticket ID. You must load the Ticket first, capture the resulting Freshdesk ID, and use that ID when creating the subsequent Conversations.

Phase 4: Delta sync for zero downtime

Do not freeze your Gorgias instance during migration. Instead:

1. Run the full historical migration with Gorgias still active.
2. After the initial load completes, run a delta sync — re-extract tickets from Gorgias with updated_datetime after the migration start time. Since Gorgias list endpoints do not support server-side date filtering, fetch tickets in reverse chronological order and stop when you reach tickets older than your migration start timestamp.
3. Upsert only new and modified tickets into Freshdesk using cf_gorgias_ticket_id for matching.
4. For ongoing real-time sync during the cutover window, configure Gorgias webhooks (POST /api/events) for ticket-created and ticket-updated events to push changes to your migration middleware.
5. Cut over to Freshdesk only after the delta gap is under 1 hour.

Cutover checklist:

• Update MX records or email forwarding rules to point your support inbox at Freshdesk
• Set up email forwarding from the Gorgias-connected inbox to Freshdesk as a safety net for customers replying to old threads
• Swap chat widgets on your storefront from Gorgias to Freshchat
• Update any Shopify webhook endpoints that point to Gorgias
• Verify Freshdesk is receiving new tickets before deactivating Gorgias

For a deeper dive on zero-downtime approaches, see Zero-Downtime Help Desk Data Migration.

How long does a Gorgias to Freshdesk migration take?

A typical Gorgias to Freshdesk migration takes 2–4 weeks end-to-end for a mid-market team. For small teams with under 20K tickets and light customization, 5–10 working days is realistic. For 100K+ tickets, multi-brand inboxes, or heavy Shopify workflow rebuilds, plan for 3–6 weeks.

Risk register:

What customers and agents notice during migration

With a well-executed delta sync approach, customers should notice nothing. Their ticket history — every message thread — will be accessible in Freshdesk. Agents can reference past conversations without interruption.

What changes:

• Ticket IDs change. Freshdesk assigns new ticket IDs. Store the Gorgias ticket ID in cf_gorgias_ticket_id so agents can cross-reference during the transition period.
• SLA timers reset. Freshdesk SLA policies apply from the moment tickets are created in Freshdesk (or from the preserved created_at if using the Import API). Historical SLA performance from Gorgias does not carry over — export it as a report before cutover and archive in your BI tool.
• Reply-to behavior changes. Customers replying to old Gorgias email threads will hit Gorgias, not Freshdesk. Set up email forwarding from your Gorgias-connected inbox to Freshdesk immediately after cutover. Freshdesk email threading checks ticket ID, Message-ID, and a unique identifier ({{ticket.id}} in the reply-to address) to decide whether incoming email appends to an existing ticket (support.freshdesk.com).
• Customer portal changes. If you used Gorgias's chat widget, switching to Freshdesk's portal or Freshchat widget requires updating your site. Plan for a widget swap during the cutover window.
• Workflow gaps. Agents will notice differences immediately if they relied on Gorgias order actions (one-click refund, cancel, edit), suggested Shopify tags, or macro-driven order edits. Budget time for training on Freshdesk equivalents (Shopify Marketplace app, manual Shopify admin lookup).

Communication plan: Notify agents 2 weeks before cutover. Provide a comparison guide showing Gorgias vs. Freshdesk UI equivalents for their top 10 daily workflows. Run a 1-hour training session on Freshdesk's interface using the sandbox with real migrated data. Do not notify customers — if the migration is done correctly, they will not know it happened.

Edge cases and known limitations

These are the specific failure modes that catch teams off guard:

• Gorgias CSV export excludes internal notes. The standard ticket CSV export omits internal notes, ticket events, Facebook wall posts, and Instagram media messages. The analytics export with message content includes only public messages from the most recent 30 days and caps at 100K tickets. A full migration requires the API (docs.gorgias.com).
• Gorgias does not export contacts as CSV. Customer records must be extracted via GET /api/customers.
• Gorgias message bodies are capped at 1 MB. If the source already truncated a message, no migration can restore the missing text (developers.gorgias.com).
• Inline images. Gorgias stores inline images as base64-encoded strings or temporary AWS S3 pre-signed URLs (which expire). If your script does not parse the HTML body, download the image, re-host it on permanent storage, and update the src attribute, you will migrate broken image icons.
• Agent authorship. If a Gorgias agent has left the company and does not have a licensed seat in Freshdesk, you cannot assign historical replies to them. Map inactive agents to a generic "Legacy Agent" account in Freshdesk to preserve the history. Include the original agent name in the message body (e.g., " [Originally from: Jane Smith, 2023-01-15]").
• Freshdesk pagination ceiling. The /api/v2/tickets list endpoint caps at page 500 (using per_page=100, that is 50,000 tickets). Beyond that, use the search endpoint or filter by date ranges. The filter endpoint is capped at 10 pages (300 results).
• Multi-brand Gorgias accounts. If you operate multiple Shopify stores through one Gorgias account, you must decide whether to merge into one Freshdesk instance (using Products to separate brands) or split into separate Freshdesk portals. This decision affects custom field design, automation rules, and reporting. Make this architectural decision in Phase 0, not mid-migration.
• Bot and AI Agent messages. Gorgias AI Agent messages are stored as regular messages with sender.type indicating a bot. They migrate to Freshdesk as standard conversation entries — the AI attribution is not preserved. Tag these with cf_ai_response: true during transformation if you want to track them.
• Macros and automations. Gorgias rules cannot be exported via API. Every macro using Shopify variables must be manually rewritten into Freshdesk Scenario Automations, canned responses, and rule configurations. Budget 3–5 days for this rebuild. See Your Help Desk Data Migration's Secret Saboteur: Automations, Macros, and Workflows.

How to validate a Gorgias to Freshdesk migration

Do not rely on total ticket counts alone. A migration can have matching ticket counts but missing replies or corrupted attachments.

1. Record-count reconciliation. Compare total tickets, contacts, tags, and conversation entries between Gorgias and Freshdesk. Document expected counts from extraction and actual counts post-load.
2. Field-level sampling. Pull 50 random tickets from each status category (Open, Closed). Compare subject, description, status, tags, custom field values, and conversation count against the Gorgias source. Use cf_gorgias_ticket_id to cross-reference.
3. Attachment verification. Spot-check 20 tickets with attachments. Verify files are downloadable, not corrupted, and that inline images render correctly in the ticket body.
4. Conversation threading. Verify that messages appear in chronological order and that internal notes are correctly marked as private (not visible to customers in the portal).
5. Agent attribution. Confirm that tickets are assigned to the correct Freshdesk agents and that conversation entries show the correct author.
6. Search validation. Search for 10 known customer email addresses in Freshdesk. Verify their ticket history appears complete. Search by cf_gorgias_ticket_id to confirm cross-reference integrity.
7. Edge case sampling. Check one ticket per original channel (email, chat, Instagram, SMS), one with oversized attachments (verify external URL link), one with 10+ private notes, and one from a merged customer record.
8. Timestamp accuracy. For 10 sampled tickets, compare created_at and conversation timestamps against Gorgias originals. Verify UTC normalization was applied correctly.
9. Custom field validation. Verify that Shopify-derived fields (cf_shopify_order_id, cf_order_status) contain the expected values for 10 sampled tickets.
10. Negative test. Confirm that no email notifications were sent to customers during import. Check Freshdesk's email send logs (Admin > Email Notifications > Logs) for the migration window.

Rollback plan: If UAT fails on go-live day, repoint DNS/email forwarding back to Gorgias. Because you used a delta sync, no data is lost in Gorgias. For tickets created in Freshdesk during the failed cutover window (between DNS switch and rollback), export them from Freshdesk via API and manually create them in Gorgias, or accept a short gap. Keep Gorgias intact and the account active until the hypercare period (typically 1–2 weeks post-cutover) is complete.

For a comprehensive post-migration QA framework, see Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration.

Build in-house vs. use a managed service

Build in-house when:

• You have a dedicated engineer with 2–4 weeks of availability
• Your dataset is under 50K tickets with minimal custom fields
• You do not use Shopify order data embedded in ticket conversations
• You are comfortable building and maintaining retry logic, rate limit handling, and deduplication
• You have access to a Freshdesk Pro or Enterprise plan (for the Import API)

Use a managed service when:

• Your dataset exceeds 100K tickets
• You have Shopify order data that must be preserved as structured Freshdesk fields
• You need zero downtime with a delta sync approach
• Your team does not have 2–4 weeks of engineering bandwidth to dedicate
• You have compliance requirements (GDPR, SOC 2) that mandate documented data handling procedures during migration
• You have attempted a DIY migration and hit rate limit issues or data inconsistencies

The hidden cost of DIY is not the initial build — it is the debugging. When 3% of tickets fail silently due to attachment size limits, when conversation threading breaks because messages were imported out of order, when a Freshdesk automation fires and sends 10,000 emails to customers on closed tickets — those costs turn a "two-week project" into a two-month recovery.

ClonePartner has run complex Gorgias environments with Shopify data mapping, custom field transformation, and zero-downtime delta syncs. Our migration engine automatically throttles to respect Freshdesk's per-endpoint sub-limits without dropping records, so your engineering team stays focused on your core product.