How to Migrate from Front to Zendesk: The Complete Technical Guide

A Front to Zendesk migration is a data-model translation — you are converting a conversation-centric shared inbox into a ticket-lifecycle system with statuses, SLAs, and structured workflows. The biggest risk is losing conversation history, threading, timestamps, and requester attribution. The data that does not move 1:1 includes Front rules, linked conversations, shared drafts, and analytics dashboards — plan to rebuild those deliberately. (help.front.com)

With the right API approach — specifically Zendesk's Ticket Import API — all conversation history can be preserved. CSV exports from Front do not include full conversation threads, so they are not viable for historical migration. Teams with fewer than 10K conversations and available engineering time can run this in-house. For anything larger, or if your engineers are needed elsewhere, a managed migration service is faster and lower risk.

If you are still deciding whether Zendesk is the right target, start with Zendesk vs Front (2026): The Operations Lead's Decision Matrix.

Why Teams Migrate from Front to Zendesk

Teams switch from Front to Zendesk when shared-inbox collaboration stops being enough and they need a formal support operating system. Zendesk centers work on tickets, support addresses, groups, statuses, SLAs, and Explore reporting. Front centers work on conversations inside inboxes and channels. (help.front.com)

Common triggers:

• Formal SLA management. Zendesk's SLA policies track first-reply and resolution times natively with escalation paths. Front handles SLAs through rules, but they are inbox-scoped and less granular.
• Ticket lifecycle control. Zendesk tickets move through defined statuses (new → open → pending → solved → closed) with triggers at each transition. Front conversations are either open or archived — there is no native pending or solved state.
• Reporting depth. Zendesk Explore provides cross-team reporting with custom metrics and drill-downs. Front's analytics are more limited for enterprise reporting needs.
• Enterprise compliance. Zendesk offers FedRAMP authorization and advanced data privacy add-ons. Teams in regulated industries often need these certifications. (zendesk.com)
• Marketplace ecosystem. Zendesk's app marketplace has 1,500+ integrations versus Front's smaller ecosystem.

The migration is non-trivial because the data models are structurally different:

• Front is conversation-centric. Messages, comments, and drafts live inside threaded conversations within shared inboxes.
• Zendesk is ticket-centric. Every interaction is a structured record with defined fields, statuses, and group assignments.
• Front inboxes are routing containers that can hold multiple channels, and a channel belongs to one inbox. (help.front.com)
• Zendesk expects ticket lifecycle state — requester, submitter, assignee, group, status, and optionally SLA context. (developer.zendesk.com)
• Front collaboration is richer inside the thread. Shared drafts and threaded internal comments are first-class collaboration objects. Zendesk imported history is a linear sequence of public and private comments — that internal threading does not survive 1:1. (help.front.com)
• Rules are scoped differently. Front rules are inbox-scoped; Zendesk models equivalent logic through global triggers, automations, and SLA policies. (help.front.com)

Every mapping decision between these models determines whether data arrives intact or silently drops.

Front to Zendesk Object & Field Mapping

The mapping table below covers every Front object and its Zendesk equivalent. Objects without a clean equivalent require manual rebuild or will not migrate.

Field-level mapping details

Conversation status → Ticket status: Front conversations are open, assigned, unassigned, or archived. A practical mapping: assigned → open, unassigned → new (or open in a triage group), archived → solved, trashed → closed (or skip). This is a recommended implementation mapping based on the two data models, not an official vendor-provided conversion path. (dev.frontapp.com)

Message type → Comment visibility: Front messages from contacts map to public comments. Internal comments in Front map to private (internal) notes in Zendesk. The public boolean on the Zendesk comment payload controls this.

Requester attribution: Each Zendesk ticket requires a valid requester_id. The Front contact who initiated the conversation must already exist as a Zendesk end-user before the ticket is imported. If you load tickets before users, they default to the API admin's user ID — permanently destroying attribution.

Custom fields: Person-level Front fields belong in Zendesk user fields. Conversation-specific Front fields belong in Zendesk ticket fields. Front custom fields support types like date and time, number, text, dropdown, and yes/no. Zendesk fields support text, date, integer, decimal, dropdown, lookup, and multiselect. Zendesk dropdown fields should be populated with the option tag/value, not the display label. (help.front.com)

Legacy IDs: Store the original Front conversation ID in Zendesk's external_id field or a dedicated custom ticket field so agents can look up legacy references after cutover. (help.front.com)

Multi-brand mapping: If your Zendesk instance uses multiple brands, each Front inbox should map to a specific brand_id on the imported ticket. Define this mapping during configuration — the Ticket Import API accepts brand_id as a ticket property. Failing to set it will assign all imported tickets to the default brand.

Migration Approaches: CSV vs API vs Managed Service

There are five realistic methods. Only two reliably preserve full conversation history.

CSV Export/Import

Front's account data export must be requested through Front Support — you cannot self-serve it. The export delivers CSV files organized by inbox, but it does not include attachments, individual inbox conversations, contact data, message templates, or tags. The analytics message export only includes a 200-character extract of the message body, not the full content. (help.front.com)

Zendesk's CSV import handles users and organizations (up to 2,000 rows per file) but does not support ticket import via CSV.

Bottom line: CSV works for migrating contacts and organizations as reference data. It does not work for conversation history.

API-Based Migration

This is the only method that reliably preserves full conversation history with original timestamps and author attribution.

Front API authentication: Front uses API tokens (Bearer tokens) for authentication. Generate a token under Settings → Developers → API tokens. Each token inherits the permissions of the teammate who created it. For migration, use a token created by an admin to ensure access to all inboxes and conversations. OAuth is also available but unnecessary for one-time extraction. (dev.frontapp.com)

Front extraction endpoints:

• GET /conversations — list all conversations (paginated via page_token)
• GET /conversations/{id}/messages — get all messages with bodies, timestamps, authors
• GET /conversations/{id}/comments — get internal comments
• GET /contacts — list all contacts
• GET /teammates — list all teammates
• GET /inboxes — list all inboxes
• GET /tags — list all tags

Zendesk API authentication: Use an API token with basic auth ({email}/token:{api_token}) for the import. OAuth tokens work but add setup complexity for a one-time migration. API tokens are generated under Admin Center → Apps and Integrations → Zendesk API. Do not use a password-based auth method — it is deprecated and less secure. (developer.zendesk.com)

Zendesk load endpoints:

• POST /api/v2/imports/tickets — Ticket Import API (single ticket with comments array)
• POST /api/v2/imports/tickets/create_many — batch import (up to 100 tickets per request)
• POST /api/v2/users/create_or_update_many — bulk user creation (up to 100 per request)
• POST /api/v2/organizations/create_many — bulk org creation
• POST /api/v2/uploads — attachment upload (returns a token to attach to comments)

Self-Serve Migration Tools

Tools like Import2 and Help Desk Migration position themselves as standardized migration products. They can be useful when your mapping is standard and your volume is moderate. They are less comfortable when you need deterministic treatment of merged conversations, internal note fidelity, legacy IDs, or custom field remodeling. (zendesk.co.uk)

Managed Migration Service

When your conversation volume exceeds 50K, your Front setup includes custom fields and multi-channel conversations, or your engineering team is allocated elsewhere, a managed service handles extraction, transformation, loading, and validation end to end. This trades engineering time for speed and risk reduction. Indicative pricing for managed migrations ranges from $2,000–$15,000+ depending on volume, field complexity, and number of channels — though quotes vary significantly by provider.

For a broader comparison of approaches and their true costs, see Cost of Help Desk Data Migration: What to Budget For.

API Rate Limits: The Hidden Migration Bottleneck

Rate limits determine how fast you can extract and load data. Front is almost always the bottleneck.

Front API rate limits

Front's API rate limits are enforced per-company, not per-token. The standard limit starts at 50 requests per minute on lower-tier plans and scales with plan level. Some resource-intensive routes are subject to an additional burst limit of 5 requests per second per resource type. Throwing more workers at Front does not bypass the per-company cap. (dev.frontapp.com)

Rate limit add-ons are available on higher-tier plans (300 additional calls per minute per add-on), but you need to purchase them in advance of the migration.

Zendesk API rate limits

Zendesk rate limits are account-level — every integration, webhook, and UI action shares the same bucket. The Ticket Import batch endpoint accepts up to 100 tickets per request, so on Professional (400 req/min), you can theoretically push up to 40,000 tickets per minute. In practice, attachment uploads consume additional requests and slow this down. The High Volume API add-on increases the limit to 2,500 req/min and is included with Enterprise Plus. (developer.zendesk.com)

Step-by-Step Front to Zendesk Migration Process

The order of operations matters. Zendesk's Ticket Import API requires valid requester_id and assignee_id values, which means users and organizations must exist in Zendesk before you import tickets.

1. Audit your Front data

Inventory conversations, contacts, accounts, tags, custom fields, and inboxes. Identify conversations with shared drafts (they need to be finalized or discarded), merged conversations, and multi-channel threads. Decide what becomes a user field, organization field, ticket field, tag, macro, or manual rebuild item. This is also when you decide what not to migrate — see Help Desk Data Migration Playbook: What Data to Move and What to Leave Behind.

2. Configure Zendesk structure

Set up groups (mapped from Front inboxes and teams), ticket fields (mapped from Front conversation custom fields), user fields (mapped from Front contact custom fields), agent accounts, support addresses, brands (if using multi-brand), and any SLA policies you need. Disable welcome emails before importing users to avoid flooding end-users with notifications. Disable triggers that act on ticket creation or update events — even though the Import API bypasses triggers by default, any custom triggers you've already configured in Zendesk could fire on subsequent updates. All required structure must exist before you load any data — this prevents rework during ticket loading.

Use a Zendesk sandbox for testing. Zendesk provides sandbox environments on Professional plans and above. Run your entire migration script against the sandbox first, validate the results, and only then execute against production. This catches mapping errors, malformed payloads, and edge cases before they affect live data. (developer.zendesk.com)

3. Migrate users and organizations first

Extract contacts from Front via GET /contacts and accounts via the accounts endpoint. Transform them to Zendesk user and organization format, then load via POST /api/v2/users/create_or_update_many and POST /api/v2/organizations/create_many. Store the Front contact ID → Zendesk user ID mapping — you will need it for every ticket import. (developer.zendesk.com)

{
  "users": [
    {
      "name": "Jane Doe",
      "email": "jane@example.com",
      "role": "end-user",
      "user_fields": {
        "front_contact_id": "crd_abc123"
      }
    }
  ]
}

4. Import tickets with comments

For each Front conversation, fetch all messages via GET /conversations/{id}/messages, build a Zendesk ticket payload with a comments array, and submit via the Ticket Import API. Set requester_id, assignee_id, and each comment's author_id explicitly — Zendesk makes the submitter the author of the first comment if you do not control it.

For already closed legacy tickets, archive_immediately=true lets you create closed records directly in the ticket archive. Archived tickets are not returned by default in Zendesk views or search results — they must be queried explicitly. This keeps the agent workspace clean but means archived tickets won't appear in Explore reports unless you configure the dataset to include them. (developer.zendesk.com)

{
  "ticket": {
    "subject": "Order #4521 - Shipping delay",
    "created_at": "2024-09-15T14:23:00Z",
    "updated_at": "2024-09-17T09:45:00Z",
    "status": "solved",
    "requester_id": 98765,
    "assignee_id": 12345,
    "group_id": 678,
    "brand_id": 456,
    "tags": ["shipping", "escalated", "migrated_from_front"],
    "external_id": "cnv_front_abc123",
    "comments": [
      {
        "author_id": 98765,
        "value": "Hi, my order hasn't shipped yet...",
        "created_at": "2024-09-15T14:23:00Z",
        "public": true
      },
      {
        "author_id": 12345,
        "value": "Checking with the warehouse now.",
        "created_at": "2024-09-15T15:01:00Z",
        "public": false
      },
      {
        "author_id": 12345,
        "html_body": "<p>Your order has been expedited. See attached shipping label.</p><img src='cid:inline_image_token'/>",
        "created_at": "2024-09-16T10:30:00Z",
        "public": true,
        "uploads": ["token_from_uploads_api"]
      }
    ]
  }
}

5. Upload attachments

For each attachment in a Front message, download it from Front, upload it to Zendesk via POST /api/v2/uploads?filename={name}, capture the returned token, and include it in the corresponding comment's uploads array. Zendesk enforces a 50 MB per file size limit via API. Pre-scan for oversized files and handle them separately. (developer.zendesk.com)

Inline images embedded in Front message HTML must be extracted, uploaded to the Uploads API, and re-linked in the comment's html_body. If you use value instead of html_body, inline images will be lost.

6. Rebuild tags and automations

Apply Front conversation tags to the newly created Zendesk tickets. Transform tags during this phase — Front tags can contain spaces and mixed case, but Zendesk tags must be lowercase only with underscores instead of spaces. "High Priority" in Front becomes "high_priority" in Zendesk.

Front rules must be re-expressed as Zendesk triggers, automations, and SLA policies manually. There is no programmatic conversion path. For guidance on rebuilding automations, see Your Help Desk Data Migration's Secret Saboteur: Automations, Macros, and Workflows.

7. Run a delta sync

Between the initial full extraction and the cutover moment, new conversations will have been created in Front. To capture them, run a final delta sync using Front's GET /conversations endpoint filtered by after timestamp (the updated_after query parameter). Use the timestamp of your last successful extraction as the cursor. This ensures no conversations created or updated during the migration window are lost. The delta sync typically covers 1–3 days of new activity and runs much faster than the initial extraction.

8. Validate and go live

Run record-count reconciliation, field-level spot checks, and agent UAT. Only then cut over inbound support addresses from Front to Zendesk. Details in the validation section below.

Error handling

Implement retry logic with exponential backoff for 429 responses. Both Front and Zendesk return a Retry-After header — respect it. Front's list endpoints use page_token pagination; follow the next link until it is null rather than relying on record counts. Merged conversations in Front can return HTTP 301 redirects on message and comment endpoints — your extractor must resolve these redirects instead of treating them as failures. (dev.frontapp.com)

Beyond 429 and 301, handle these specific error codes:

• 422 Unprocessable Entity — Zendesk returns this when a ticket payload is malformed (e.g., missing required requester_id, invalid status value, or empty comment body). Log the full response body, which includes a description field explaining the specific validation failure.
• 409 Conflict — Returned when a user or organization with the same unique identifier already exists. Use create_or_update endpoints to handle this gracefully.
• 413 Request Entity Too Large — Attachment exceeds Zendesk's 50 MB limit. Log and skip, or compress and retry.
• 500/502/503 — Transient server errors on either side. Retry with backoff; do not treat as permanent failures.

Log every failed record with its Front conversation ID so you can reprocess failures without re-running the entire migration. Zendesk's Ticket Import API supports idempotency keys via the Idempotency-Key header — use them to prevent duplicate tickets on retry. Set external_id on every ticket so reruns stay idempotent.

In practice, expect a 2–5% failure rate on the first import attempt for migrations over 50K conversations, primarily due to edge cases like empty comment bodies, oversized attachments, and orphaned requester references. Budget time for a failure-reprocessing pass.

# Front extract
GET /conversations?limit=100
GET /conversations/{conversation_id}/messages?sort_order=asc
GET /conversations/{conversation_id}/comments
 
# Zendesk load
POST /api/v2/users/create_many.json
POST /api/v2/organizations/create_many
POST /api/v2/imports/tickets/create_many
POST /api/v2/uploads?filename=file.pdf

How Long Does a Front to Zendesk Migration Take?

A realistic timeline for a team with 50 agents and 100K conversations:

Small, clean migrations (under 10K conversations, simple setup) can finish in 1–2 weeks. A managed migration service compresses the timeline to 1–3 weeks because the extraction and transformation logic is already built.

The timeline is driven primarily by Front extraction limits, rule rebuild work, and attachment volume — not by Zendesk write speed. (dev.frontapp.com)

Use a phased migration if inboxes or brands are operationally separate. Use a big-bang cutover only when your queues are tightly shared and your team can absorb a single retraining window.

Risk register

What Happens to Customers During Migration?

Your end-users should not experience downtime during a well-executed migration.

Will customers see downtime? No. Both Front and Zendesk can run in parallel during migration. New conversations continue in Front until cutover; historical data loads into Zendesk in the background. Zendesk can reply from the same support address a customer emailed, once that address is configured. (developer.zendesk.com)

Will old conversations be referenceable? Yes — every migrated Front conversation becomes a Zendesk ticket with its full message history. Front conversation IDs will not match Zendesk ticket IDs. Maintain a mapping table (via external_id) if your team references ticket numbers externally.

What if a customer replies to an old thread? After cutover, if a customer replies to a migrated conversation's email thread, Zendesk will attempt to match it using email threading headers (In-Reply-To and References). This works for email conversations where the original Message-ID was preserved. For other channels (SMS, chat), the reply will create a new ticket. Treat old-thread continuation as something to validate during testing, not a guaranteed default. (developer.zendesk.com)

Will SLA clocks reset? Yes. Zendesk's SLA policies start fresh — historical SLA compliance data from Front does not carry over. SLA timers on imported tickets are not calculated by Zendesk.

Do you need to shut down Front during migration? No. Historical data can be extracted from Front while it remains active. Most teams extract historical data first, then run a final delta sync of new conversations (using the updated_after query parameter with the timestamp of the last extraction) immediately before the cutover to capture anything created during the migration window. Only the cutover itself — when you stop accepting new conversations in Front and start accepting them in Zendesk — requires coordination. This is typically done over a weekend or low-traffic window.

Change management checklist:

• Retrain agents on Zendesk's agent workspace — Front habits like inbox moves, comments, and shared drafts do not feel the same in Zendesk's group/status/macro model
• Update customer-facing auto-replies, signatures, and help center links
• Update any external systems that reference Front conversation URLs
• Communicate the transition to customers if your support email address is changing

Edge Cases That Break Front to Zendesk Migrations

Standard API scripts fail on edge cases. You must engineer solutions for each of the following.

Merged conversations

Front allows merging conversations. The resulting conversation contains messages from multiple original threads. Front's message and comment endpoints can return HTTP 301 redirects when a conversation has been merged — your extractor needs to resolve those redirects or you will double-import or orphan history. When importing to Zendesk, a merged conversation becomes a single ticket. If you need to preserve the pre-merge history, handle it at the extraction layer with a canonical-conversation map. (dev.frontapp.com)

Multi-channel conversations

A single Front conversation can span email and SMS. Zendesk tickets are typically single-channel. Decide which channel the Zendesk ticket represents and note the channel transitions in internal comments.

Contact identity cleanup

The real identity issue is alias normalization, secondary handles, and deciding which email becomes primary in Zendesk. Zendesk email identities are unique per user. Contacts with multiple email handles in Front need intentional mapping to Zendesk user identities. Use Zendesk's POST /api/v2/users/{id}/identities endpoint to add secondary email identities to a single user record rather than creating duplicate users. (help.front.com)

Inline images and attachments

Front messages may contain inline images embedded in HTML. These must be extracted, uploaded to Zendesk's Uploads API, and re-linked in the comment's html_body. If you use value instead of html_body, inline images will be lost. Zendesk enforces a 50 MB per file limit — files larger than this will fail to upload. Front's support-led account export provides attachments from shared inboxes only, and only in EML format, so API extraction is the reliable path. (developer.zendesk.com)

Tags

Front tags can contain spaces and mixed case. Zendesk tags are lowercase only and use underscores instead of spaces. "High Priority" in Front becomes "high_priority" in Zendesk. Automate this transformation in your migration script. Note that Front's support-led account export does not include tags — you must extract them via API. (help.front.com)

Shared drafts

Front's shared drafts have no Zendesk equivalent. Any active drafts must be sent or discarded before cutover. There is no API to extract draft content for migration. (help.front.com)

Empty comment bodies

The Zendesk Ticket Import API rejects comments with empty bodies, even though Front allows sending attachments without body text. Add placeholder text like "(Attachment only)" for these cases.

What Can't Be Migrated from Front to Zendesk?

Be clear with stakeholders: the following items must be manually rebuilt or will not exist in Zendesk post-migration.

• Rules and automations — Front rules are inbox-scoped with a different logic structure than Zendesk's global triggers and automations. There is no programmatic migration path. Every rule must be rebuilt. (help.front.com)
• Analytics dashboards — All reports must be recreated in Zendesk Explore. Front analytics exports can give you raw data, but dashboards themselves do not transfer.
• Shared drafts — No equivalent exists in Zendesk. Resolve before cutover.
• Conversation links — Front's linked-conversation feature has no native Zendesk equivalent. Side Conversations and problem/incident patterns are only partial substitutes. (help.front.com)
• Integration configurations — Salesforce sync, Slack integrations, and CRM links must all be reconfigured using Zendesk's marketplace apps.
• Channel routing logic — Front's per-inbox routing rules do not map to Zendesk's omnichannel routing configuration.
• SLA timer state — SLA policies must be recreated. Historical SLA compliance data does not carry over.
• Message templates — Front templates with dynamic variables require manual recreation as Zendesk macros with different placeholder syntax.
• Tags and templates in export-led projects — Front's support-led account export does not include tags or message templates. If you rely on that export path, these are also excluded. (help.front.com)

For a deeper dive on what to move and what to leave behind, see Help Desk Data Migration Playbook.

Post-Migration Validation and Testing

Validation is where migrations succeed or fail. A "completed" migration with wrong requester attribution or missing comments is worse than no migration at all.

Record-count reconciliation

Field-level spot checks

• Verify custom field values on 20+ tickets across different date ranges
• Confirm tags transferred correctly (check for case and formatting issues)
• Verify created_at timestamps match Front's original timestamps
• Confirm requester attribution — the right person should appear as the ticket requester, not the migration script's API user
• Check that external_id contains the original Front conversation ID for backward lookup
• Verify html_body rendering — confirm inline images display correctly, not as broken links
• Spot-check tickets from merged conversations to confirm no duplicate or orphaned messages

Agent UAT

Have 2–3 agents review their own recent conversations in Zendesk. Ask them to find their most complex Front conversations and verify threading, internal notes, and attachments. They will catch issues that automated checks miss.

Rollback plan

Keep your Front account active and read-only for at least 4 weeks post-migration. If a critical issue surfaces, agents can reference Front while you fix Zendesk data.

Data retention and decommissioning

After the 4-week parallel-run period and full validation sign-off, export a final backup from Front for archival purposes. Before decommissioning your Front account, confirm any data retention obligations under your contracts or regulatory requirements (e.g., GDPR, SOC 2 audit trails). Front does not automatically delete data on account cancellation — contact Front Support to understand the retention and deletion timeline for your plan tier.

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

Should You Migrate In-House or Use a Service?

In-house makes sense when: your conversation volume is under 10K, your Front setup is straightforward (few custom fields, single channel), you have an engineer with 2–3 weeks of available bandwidth, and you are comfortable with both APIs.

In-house is risky when: you have 50K+ conversations, multi-channel inboxes, complex custom field mappings, a tight cutover window, or your engineering team is already committed to product work. The hidden costs of DIY — broken threading, lost requester attribution, timestamps showing the migration date instead of the original, and the re-migration after the first attempt flattens history — often exceed the cost of a managed service.

Self-serve tools sit in the middle. Import2 and Help Desk Migration both work when your needs fit their connectors. Once the project depends on custom field remodeling, merged-conversation logic, or careful cutover design, engineer-led execution tends to be safer. (zendesk.co.uk)

For budgeting the project around engineering time, validation time, and rework risk, see Cost of Help Desk Data Migration.