Zendesk to Gladly Migration: The Complete Technical Guide

What Is a Zendesk to Gladly Migration?

A Zendesk to Gladly migration is the process of extracting tickets, users, organizations, comments, tags, custom fields, and knowledge base articles from Zendesk Support and loading them into Gladly as conversations, conversation items, customers, teams, topics, inboxes, and answers — while translating Zendesk's ticket-centric data model into Gladly's person-centric timeline.

This is not a like-for-like transfer. It is a schema translation that fundamentally changes how customer history is organized. Gladly does not use ticket numbers, allows only one open Conversation per customer at a time, and treats the timeline as a customer view rather than a reportable unit. (help.gladly.com)

Why Teams Move from Zendesk to Gladly

Teams make this switch for three platform-specific architectural reasons:

• Person-centric architecture. Gladly organizes all interactions around a single customer profile — every email, chat, SMS, and phone call lives on one continuous timeline. Zendesk treats each interaction as a separate ticket. For brands with high repeat-contact rates (e-commerce, DTC, hospitality), this eliminates repeated context-gathering across tickets. For a deeper overview of Gladly's architecture, see our Gladly platform guide.
• Channel-native design. Gladly treats every channel (voice, email, chat, SMS, social) as a first-class citizen within a single conversation thread. Zendesk requires separate channel configurations and creates distinct tickets per channel, which fragments context across ticket records.
• Simplified pricing model. Gladly charges per agent (Hero) with unlimited conversations. Zendesk's usage-based add-ons for AI, advanced analytics, and the High Volume API can inflate costs at scale — particularly for high-volume support teams exceeding 100,000 tickets/month.

The 2 Architectural Differences That Make This Migration Non-Trivial

1. Tickets vs. Lifelong Conversations. A Zendesk Ticket is a discrete, numbered record with a lifecycle (New → Open → Pending → Solved → Closed). A Gladly Conversation is a period of related interactions on a customer's timeline — it has no ticket number. Multiple Zendesk tickets from the same requester must be collapsed into conversation items on a single Gladly customer profile. The mapping is many-to-one, not one-to-one.

2. Organization-centric vs. Person-centric. Zendesk groups end-users under Organizations, and tickets belong to requesters. Gladly has no Organization object — everything hangs off the Customer profile. If you rely on Zendesk Organizations for routing, reporting, or access control, you need to rethink that logic using Gladly's custom attributes or external Lookup Adapters to pull org data from your CRM.

How Does Zendesk Data Map to Gladly?

The object mapping table below covers every core Zendesk object and its Gladly equivalent. Lead with this when scoping your migration.

Field-Level Mapping Constraints

• Picklists / Dropdowns: Zendesk dropdown custom fields must be recreated as Gladly custom attributes with matching option values. Gladly does not enforce enum validation on custom attributes — values are stored as strings. This means typos or mismatched option values will not throw errors but will produce inconsistent data.
• Multi-select fields: Gladly does not natively support multi-select custom attributes. Flatten to comma-separated strings or split into multiple boolean attributes.
• Dates: Zendesk stores timestamps in UTC ISO 8601. Gladly's historical import expects createdAt / occurredAt in ISO 8601 format. No timezone conversion needed, but you must explicitly pass original creation timestamps to prevent the system from stamping all imported history with the current date.
• Rich text / HTML: Gladly conversation item bodies accept plain text through the historical import path. HTML from Zendesk ticket comments will need to be stripped or converted. Use a library like html2text (Python) or turndown (JavaScript) for consistent conversion.
• Character limits: In Gladly's CSV-based historical import, title is capped at 100 characters and body is capped at 25,000 characters. Zendesk ticket descriptions with long HTML content will be truncated silently. (help.gladly.com)
• Customer-level fields: In the CSV import, starred customer-level fields such as customAttribute, note, and address only apply on the first occurrence of each email. Sort your rows by customer_email and time so the first row for each customer carries any one-time profile attributes. (help.gladly.com)
• Phone numbers: Gladly requires E.164 format for phone numbers (e.g., +14155551234). Zendesk stores phone numbers in freeform text. Your transformation layer must normalize all phone numbers or omit malformed values.

For reusable field mapping worksheets, see our data mapping guide.

What Are the API Rate Limits for This Migration?

[For engineering] Rate limits are the primary throughput bottleneck. Both platforms impose hard caps that directly determine how long your migration takes.

Zendesk Extraction Limits

Use the cursor-based Incremental Export API (GET /api/v2/incremental/tickets/cursor) for extraction. At 10 requests per minute with 1,000 tickets per response, you can extract roughly 10,000 tickets per minute under ideal conditions — but each ticket then requires separate calls for comments and attachments, which consumes your account-wide API budget. (developer.zendesk.com)

For messaging tickets where you need reliable comment-author attribution, Zendesk recommends using the ticket audits endpoint (GET /api/v2/tickets/{id}/audits) after you identify the relevant ticket IDs. If you need a fallback full dump, Zendesk's full JSON export uses NDJSON, is not available on Team plans, and accounts with more than 1 million tickets are broken into 31-day increments.

For a detailed guide on Zendesk data extraction, see How to Export Tickets from Zendesk.

Gladly Ingestion Limits

Gladly's API enforces a hard cap of 10 requests per second across all methods. Exceed it and Gladly returns a 429 Too Many Requests error. Your ingestion script must include exponential backoff with jitter and retry logic. Gladly exposes rate-limit headers (Ratelimit-Limit-Second, Ratelimit-Remaining-Second) that your script should monitor and use to throttle proactively rather than reactively. (developer.gladly.com)

In practice, creating a customer profile and adding multiple conversation items requires 2–5+ API calls per customer:

1. POST /api/v1/customer-profiles — create the customer
2. POST /api/v1/customer-profiles/{id}/emails — add email addresses
3. POST /api/v1/customer-profiles/{id}/phones — add phone numbers (if applicable)
4. POST /api/v1/conversations — create the conversation
5. POST /api/v1/conversations/{id}/items — add each conversation item

At 10 requests per second, effective throughput drops to approximately 150–300 customer records per minute.

How Should You Approach This Migration? DIY vs. Native Import vs. Managed Service

For most teams, the safest plan is split-path: import legacy history through Gladly's historical import process and move live work through a separate cutover path. A pure REST API rewrite is rarely the best primary method because Gladly's public create-item API writes non-routable customer activities that sit outside conversations. (help.gladly.com)

Approach 1: Gladly's Native Historical Import

How it works: Export your Zendesk data as JSON via Zendesk's full data export. Transform it into Gladly's required CSV or JSON format with columns for customer_email, customer_name, title, body, occurredAt, activityType, and sourceName. Upload the file to a Gladly-provided Dropbox link. Gladly's implementation team processes the import.

When to use it: You're a new Gladly customer going through onboarding, and your dataset is relatively clean and under 500K conversation items.

Complexity: Low (for you) · Scalability: Medium · Risk: Medium — limited visibility into failures

Approach 2: Custom API-Based Migration (DIY)

How it works: Write scripts to extract via Zendesk's REST/Incremental APIs, transform the data model, and load via Gladly's REST API.

When to use it: You have dedicated engineering capacity, need full control over field mapping and transformation logic, and can tolerate a 2–4 week build + test cycle.

Complexity: High · Scalability: High · Risk: High without prior migration experience. The hidden cost is not the build — it's the re-migration when a deduplication bug at 2 AM creates hundreds of duplicate customer profiles that must be individually merged via the Gladly UI or support ticket.

Approach 3: Managed Migration Service

How it works: A migration team builds custom extraction, transformation, and load scripts tailored to your specific Zendesk configuration and Gladly setup. The service handles rate-limit orchestration, deduplication, validation, and cutover.

When to use it: You have 50,000+ tickets, complex custom fields, attachment archival requirements, or cannot afford downtime.

Complexity: Low (for you) · Scalability: Enterprise · Risk: Low

For a deeper comparison of migration tools and services, see our help desk migration solutions guide.

Cost Comparison

What Is the Step-by-Step Migration Process?

The order of operations matters. Loading conversation items before their parent customer profiles exist will orphan records. Here is the correct sequence:

Step 1: Extract Data from Zendesk

Use the Incremental Export API with cursor-based pagination for tickets, users, and organizations. Use the Ticket Comments API to pull full thread history per ticket. For bulk comment history, the Incremental Ticket Event Export with comment_events is more efficient than per-ticket comment pulls.

import requests
import time
 
ZD_SUBDOMAIN = "yourcompany"
ZD_AUTH = ("[email protected]/token", "your_api_token")
 
def extract_tickets(start_time=0):
    url = f"https://{ZD_SUBDOMAIN}.zendesk.com/api/v2/incremental/tickets/cursor"
    params = {"start_time": start_time}
    all_tickets = []
    
    while True:
        resp = requests.get(url, params=params, auth=ZD_AUTH)
        if resp.status_code == 429:
            wait = int(resp.headers.get("Retry-After", 60))
            time.sleep(wait)
            continue
        resp.raise_for_status()
        data = resp.json()
        all_tickets.extend(data["tickets"])
        if data.get("end_of_stream"):
            break
        params = {"cursor": data["after_cursor"]}
        url = f"https://{ZD_SUBDOMAIN}.zendesk.com/api/v2/incremental/tickets/cursor"
        time.sleep(6)  # Respect 10 req/min limit
    
    return all_tickets
 
def extract_comments(ticket_id):
    url = f"https://{ZD_SUBDOMAIN}.zendesk.com/api/v2/tickets/{ticket_id}/comments"
    comments = []
    while url:
        resp = requests.get(url, auth=ZD_AUTH)
        if resp.status_code == 429:
            wait = int(resp.headers.get("Retry-After", 60))
            time.sleep(wait)
            continue
        resp.raise_for_status()
        data = resp.json()
        comments.extend(data["comments"])
        url = data.get("next_page")
    return comments

Step 2: Clean and Deduplicate

• Merge duplicate Zendesk requesters by email address. Gladly uses email as a unique identifier — attempting to create two customers with the same email will return a 409 Conflict.
• Strip HTML from comment bodies if targeting Gladly's CSV import path. Preserve HTML if loading via API and your Gladly contract supports rich content.
• Remove or archive tickets with no valid requester email. Gladly will reject any import row without a well-formatted email address.
• Audit your Zendesk user base before extraction — run GET /api/v2/search?query=type:user role:end-user email:"" to identify email-less users (common in voice, messaging, and older data).
• Normalize phone numbers to E.164 format (+{country_code}{number}). Malformed phone numbers will cause Gladly API errors.
• Filter out suspended tickets (spam). Do not migrate them — they consume API quota and clutter customer timelines.

Step 3: Transform the Data Model

This is the critical step. You must reshape Zendesk's flat ticket structure into Gladly's nested customer → conversation → conversation item hierarchy.

Zendesk:                          Gladly:
┌─────────────┐                   ┌─────────────────────┐
│  Ticket #1  │──┐                │     Customer        │
│  Ticket #2  │──┼──▶ Transform ──▶│  ├─ Conversation A  │
│  Ticket #3  │──┘                │  │  ├─ Item 1       │
└─────────────┘                   │  │  ├─ Item 2       │
  (3 separate records             │  ├─ Conversation B  │
   for same requester)            │  │  ├─ Item 1       │
                                  └─────────────────────┘
                                    (1 customer profile,
                                     tickets become
                                     conversation items)

Group all tickets by requester email. Each ticket becomes a conversation; each comment becomes a conversation item within that conversation. For the documented Zendesk import path, map each ticket comment to one historical item using comment created_at, ticket subject, tags plus html_body, and requester identity.

import html2text
import re
 
h = html2text.HTML2Text()
h.ignore_links = False
 
def truncate(text, max_len):
    if text and len(text) > max_len:
        return text[:max_len - 3] + "..."
    return text or ""
 
def canonical_email(user):
    email = (user.get("email") or "").strip().lower()
    # Handle common alias patterns
    email = re.sub(r'\+.*@', '@', email)
    return email
 
def e164_or_blank(phone):
    if not phone:
        return ""
    digits = re.sub(r'[^\d+]', '', phone)
    if digits.startswith('+') and len(digits) >= 10:
        return digits
    return ""
 
def transform_to_gladly_row(ticket, comment, requester):
    email = canonical_email(requester)
    if not email:
        return None  # Log and skip
    
    tags_text = ", ".join(ticket.get("tags", []))
    body_text = h.handle(comment.get("html_body", comment.get("body", "")))
    
    return {
        'customer_email': email,
        'customer_name': requester.get('name', ''),
        'customer_phone': e164_or_blank(requester.get('phone')),
        'title': truncate(
            ticket.get('subject') or f"Zendesk ticket {ticket['id']}", 100
        ),
        'body': truncate(
            f"Tags: {tags_text}\n\n{body_text}" if tags_text else body_text,
            25000
        ),
        'activityType': 'CUSTOMER_ACTIVITY',
        'occurredAt': comment['created_at'],
        'sourceName': 'Zendesk',
    }

This transform pattern mirrors Gladly's documented Zendesk field mapping and its CSV constraints. Log every rejected row — especially missing-email rows, long-body truncations, and alias merges. (help.gladly.com)

Step 4: Load in the Correct Order

1. Agents first — Create agent profiles in Gladly (or confirm they exist). Agent IDs are referenced in conversation items.
2. Teams and Inboxes — Configure Gladly Teams (mapped from Zendesk Groups) and Inboxes. Gladly Inboxes are routing containers, not filter-based views — redesign your Zendesk Views as Inboxes based on routing logic, not display logic.
3. Topics — Create all Topics in Gladly that correspond to your Zendesk Tags. If a Zendesk tag does not exist as a Gladly Topic, the Gladly API will reject the payload with a validation error.
4. Answers and Rules — Rebuild Zendesk Macros as Gladly Answers and Triggers as Gladly Rules before cutover so active work has a destination. Do not auto-port Zendesk automations blindly — Gladly Rules do not act on closed conversations and use a different condition/action model.
5. Customers — Create customer profiles via POST /api/v1/customer-profiles. Email, name, and phone are mapped from Zendesk user records. Then add contact points via POST /api/v1/customer-profiles/{id}/emails and /phones.
6. Conversations and Items — Add conversation items to customer timelines. Use the historical import (CSV/JSON via Gladly PS) for legacy data, or the conversation/item creation endpoints for API-based loading: POST /api/v1/conversations followed by POST /api/v1/conversations/{id}/items.

Step 5: Migrate Integrations

Zendesk integrations do not carry over to Gladly. Common integrations that must be re-wired:

Budget 1–3 days per integration for re-wiring and testing. For Shopify-heavy e-commerce teams, Gladly's native Shopify integration is typically simpler than Zendesk's app-based approach, but the data mapping (order lookup, refund actions) must be validated in the sandbox.

Step 6: Validate

See the Validation section below.

Step 7: Go-Live with Delta Sync

Run the production migration while Zendesk is still live. Perform a delta sync to capture tickets created or updated during the migration window. Switch live traffic to Gladly and keep Zendesk in read-only mode for 1–2 weeks as a rollback option and attachment lookup archive.

Gladly's own import guidance recommends running history imports in batches of 500K rows about two weeks before launch, with a final delta pass two days before go-live. (help.gladly.com)

If your inbound email address is visibly tied to Zendesk, set customer-facing auto-replies in the old system before cutover so customers know where to send new messages. Update DNS MX records and any forwarding rules to route to Gladly's email endpoints. (help.gladly.com)

Rollback Procedure

If critical issues are discovered post-cutover:

1. Re-route inbound email back to Zendesk by reverting DNS/forwarding changes (MX record TTL should be set low — 300 seconds — before cutover to enable fast rollback).
2. Re-enable Zendesk chat/messaging widgets on your site by swapping the JavaScript snippet.
3. Zendesk phone routing can be restored by updating your IVR/telephony provider to point back to Zendesk Talk.
4. Records created in Gladly during the interim remain in Gladly but are not automatically synced back to Zendesk. Export any Gladly-created tickets via the Gladly API and import them into Zendesk if needed for continuity.
5. Keep Zendesk licenses active for at least 30 days post-cutover to preserve rollback capability.

How Long Does a Zendesk to Gladly Migration Take?

[For PMs] A typical Zendesk to Gladly migration takes 2–4 weeks from kickoff to go-live. The calendar is driven less by export speed than by identity cleanup, sample QA, workflow rebuild, and integration re-wiring.

Total: 16–29 business days. This compresses to 10–14 days with a dedicated migration team and a clean Zendesk instance. Instances under 10,000 tickets with simple configurations and no integration re-wiring can complete in 7–10 business days. Enterprise instances with 500,000+ tickets, multiple brands, and complex automations may take 4–6 weeks.

Risk Register

For a comprehensive approach to zero-downtime migrations, see our zero-downtime migration guide.

What Do Customers and Agents Notice During Migration?

[For customer success] Done correctly, customers notice nothing. Here is what to plan for:

• Conversation history: Historical tickets appear as conversation items on the customer's Gladly timeline. Agents see the full history when a returning customer contacts support. However, imported items are not searchable in Gladly — agents can see them on the customer timeline but cannot full-text search across imported history. (help.gladly.com)
• AI features: Imported historical items do not feed Gladly Sidekick (Gladly's AI assistant) or AI-powered answer suggestions. Sidekick operates on native Gladly data and configured Answers — not on imported conversation history. Plan for a ramp-up period where AI suggestions improve as new native data accumulates.
• Ticket numbers are gone. Gladly does not use ticket numbers. Imported historical data behaves more like reference context on the customer profile than live reportable work. Leaders should not expect legacy Zendesk data to show up in native Gladly analytics.
• Attachments: If your Zendesk tickets contain screenshots, PDFs, or recordings, these will not appear in Gladly's imported timeline. Brief your agents on where to find archived attachments (e.g., a shared drive, S3 bucket, or read-only Zendesk instance linked in a pinned note).
• Voice history: Zendesk Talk call recordings cannot be imported. Call metadata (duration, disposition) can be embedded in conversation item text during transformation, but playback is not available. Archive recordings separately if needed for compliance.
• SLAs: Zendesk SLA metrics are not carried over. Reset SLA tracking on go-live. Communicate to stakeholders that historical SLA data lives in Zendesk Explore exports, not in Gladly.
• Downtime: Zero downtime is achievable with a delta-sync strategy — run the historical load while Zendesk is still live, then sync the delta immediately before cutover.

Change Management Checklist

• Train agents on Gladly's conversation-based UI at least 1 week before go-live
• Prepare a "day one" quick-reference card: how to find imported history, where attachments are archived, how to create Topics, how to use Answers (replacing Macros)
• Set up a dedicated Slack channel or internal ticket queue for agent questions during the first 48 hours
• Brief team leads on what is and isn't in Gladly (no CSAT history, no attachment playback, no ticket numbers)
• Communicate externally only if customers will notice a change (e.g., new chat widget, new email sender address, new SMS short code)
• Update internal documentation and SOPs that reference Zendesk-specific features (Views, Macros, ticket statuses)

What Data Cannot Be Migrated from Zendesk to Gladly?

Be explicit with stakeholders about these hard limits:

Edge Cases: Identity, Truncation, Multi-Brand, and API Caps

Most migration failures come from identity, not transport. The migration breaks when the same customer exists under multiple emails, when teams assume attachments will be native in Gladly history, or when validation relies on truncated API responses or fresh reports.

Duplicate Requesters and Identity Fragmentation

Zendesk allows multiple end-user records with no email (phone-only, anonymous). Gladly requires a valid email for every imported record. Records without a valid email will be silently rejected — no error, no log entry in the historical import process. Audit your Zendesk user base before extraction — run GET /api/v2/search?query=type:user role:end-user email:"" to identify email-less users.

The trickier problem is alias fragmentation. A single customer may exist under multiple Zendesk requester records with different email addresses. If you do not canonicalize emails before import, that customer gets split across multiple Gladly profiles. Multi-brand and multi-channel Zendesk instances are especially prone to this — the same customer may have tickets under [email protected] in brand A and [email protected] in brand B.

Multi-Brand Migration

If your Zendesk instance serves multiple brands, each brand's tickets, help center, and configurations require separate treatment:

• Inbox mapping: Each Zendesk brand typically maps to a separate Gladly Inbox. Configure inboxes and email channels per brand before import.
• Identity deduplication across brands: This is the highest-risk area. Build a cross-brand customer identity map before migration. Match on email first, then phone number, then name + company as a fuzzy fallback.
• Import sequencing: You can run all brands in a single import pass if email canonicalization is complete. Otherwise, run brand-by-brand and merge duplicates post-import (more expensive and error-prone).
• Help Center content: Each brand's Help Center maps to a separate set of Gladly Answers. Import and tag Answers by brand/topic.

Truncated Conversation Items

Gladly truncates imported bodies at 25,000 characters and subjects at 100 characters. Zendesk ticket descriptions and comments with long HTML content (common in email-heavy instances) may be cut. Pre-process by stripping HTML tags and checking character counts before load. For content exceeding the limit, append an external archive link to the truncated body so agents can access the full text.

The 100-Conversation / 1,000-Item API Retrieval Cap

Gladly's REST API returns at most 100 conversations per customer and 1,000 items per conversation, both unpaginated. This is a retrieval limit, not an ingestion limit — data beyond these thresholds still exists in Gladly but is not returned by standard GET calls. The Gladly-Limited-Data response header indicates when data has been truncated. For post-migration validation on high-volume customer profiles, use Gladly's Export API rather than standard GET endpoints. (developer.gladly.com)

Attachment Strategy

Since Gladly's historical import does not include attachments, you have three practical options:

1. Archive to cloud storage (S3/GCS) and link URLs in a pinned note on each Gladly customer profile. Use Zendesk's GET /api/v2/tickets/{id}/comments response to extract attachments [].content_url for each comment.
2. Embed attachment URLs in conversation item text during transformation — append download links to the imported body. Note that Zendesk attachment URLs use temporary tokens that expire; download and re-host files before import.
3. Keep Zendesk in read-only mode as a lookup archive for attachments, audits, and records that could not be imported due to missing email addresses. This is often the cheapest option and avoids discovering a missing compliance artifact later. Budget for continued Zendesk licensing (typically at a reduced tier).

Inline Attachments in Zendesk

Zendesk allows agents to paste images directly into comments. These are stored as inline attachments with temporary AWS-signed URLs. If you are extracting these for archival, your extraction script must identify <img> tags in Zendesk HTML payloads, download the source file before the signed URL expires (typically 5–7 days after ticket closure), and store it in your archive destination. Process inline attachments during the extraction phase, not as a post-migration cleanup.

Zendesk Talk / Voice Data

Zendesk Talk stores call recordings, voicemails, call duration, wait time, and disposition. None of these transfer to Gladly's historical import. To preserve voice history:

• Export call recordings via the Zendesk Talk API (GET /api/v2/channels/voice/calls/{id}/recording) and archive to cloud storage.
• Embed call metadata (duration, disposition, callback number) in the conversation item body during transformation.
• For compliance-required call recordings (HIPAA, PCI, financial services), ensure your archive meets retention requirements independently of either platform.

GDPR/CCPA Deletion Flows

Deleted customers or conversations in Gladly can be expected — Gladly supports deletion flows for CCPA and GDPR requests. If you see records disappear after migration, verify whether a deletion request was processed before assuming data loss. Build a post-migration reconciliation report that flags record count discrepancies and cross-references against Gladly's deletion logs. (help.gladly.com)

How Do You Validate a Zendesk to Gladly Migration?

Validation proves data integrity. Do not rely on top-level record counts alone.

Record-Count Reconciliation

Sampling Strategy

1. Random sample: Pull 100 random Zendesk ticket IDs. For each, verify the corresponding Gladly customer profile exists, the conversation item count matches the ticket comment count, and the original timestamps are correct.
2. Edge-case sample: Specifically check tickets with 50+ comments, tickets with attachments (verify archive links work), tickets from requester emails that appear on multiple tickets, tickets with custom field values, and tickets from phone-only or email-less requesters (should be excluded).
3. Multi-brand sample: If migrating multiple brands, verify that cross-brand customers are merged into a single Gladly profile and that brand-specific Topics and Inboxes are correctly applied.
4. Negative test: Confirm that Zendesk-only objects (SLAs, side conversations, suspended tickets) did not create unexpected records in Gladly.

Do not use same-hour Gladly reports as your only source of truth — report data has approximately a one-hour latency. Use direct API calls or Gladly's Export API for validation immediately after load. (help.gladly.com)

UAT Protocol

Have 3–5 agents search for known returning customers in Gladly and confirm:

• Historical conversation items appear on the timeline in correct chronological order
• Customer name, email, and phone are correct
• Topics (from Zendesk tags) are applied
• Custom attributes are populated with correct values
• Agent assignments on historical items are accurate (if imported via API path)
• Attachment archive links work (if you embedded them in conversation item text)
• Integration data loads correctly (Shopify order lookup, Salesforce account data via Lookup Adapter)

For a full post-migration testing checklist, see our QA checklist.

Should You Build In-House or Use a Managed Service?

Build in-house when:

• Your Zendesk instance has fewer than 10,000 tickets
• You have minimal custom fields and no attachment archival requirements
• Your data is mostly email-based (few phone-only or anonymous requesters)
• You operate a single Zendesk brand
• You have a developer with 40+ hours available and Zendesk/Gladly API experience
• You can tolerate a longer timeline and iterative debugging

Use a managed service when:

• Your instance exceeds 50,000 tickets or 10,000 unique customers
• You need attachment archival and linking
• You require zero downtime and a delta-sync cutover
• You operate multiple Zendesk brands with cross-brand customer overlap
• Your engineering team is already committed to other projects
• You have compliance requirements (HIPAA, SOC 2, PCI) that demand audit trails during migration
• You have multi-channel data (voice, messaging) with identity fragmentation challenges
• You have complex integrations (Shopify, Salesforce, Jira) that must be re-wired simultaneously

The hidden cost of DIY is not the build — it is the re-migration. A rate-limit miscalculation or deduplication bug at 2 AM creates duplicate customer profiles that take days to untangle. The engineering time for a first-time Zendesk-to-Gladly migration typically runs 120–200 hours including testing and fixes.

The Decision That Saves Rework Later

Decide early whether your goal is historical context, native Gladly analytics, or workflow parity. You can get all three eventually, but not through one naive import path.

• If your main goal is agent context (agents can see past interactions), the official history-import route is usually enough. Accept that imported data will not be searchable, will not feed AI features, and will not appear in Gladly analytics.
• If your main goal is native reporting and workflow parity, you need a broader program: history import for context, live cutover for active work, integration re-wiring for operational continuity, and often a read-only Zendesk archive for attachments and audits.
• If your main goal is compliance continuity, keep Zendesk in read-only mode as your system of record for historical data and use Gladly exclusively for forward-looking interactions.

The teams that avoid rework are the ones that separate legacy history, live work, integration re-wiring, and archive strategy before the first export runs.