Zendesk Data Migration: What Moves and What Doesn't

This is the reference guide for that distinction. We'll cover the four ways to get data into Zendesk, give you a clear what-moves-vs-what-doesn't breakdown, flag the caveats that quietly break migrations (ticket IDs, timestamps, agent matching), and hand you a pre/during/post checklist. If you want the step-by-step for a specific source platform, those live in their own guides — migrating to Zendesk from Freshdesk and migrating to Zendesk from Intercom. This post is the map; those are the turn-by-turn directions.

Update (June 2026): Salesforce has agreed to acquire Fin (formerly Intercom) for ~$3.6 billion and plans to fold it into Salesforce's Agentforce — the deal was announced June 15, 2026 and is expected to close around Q4 of Salesforce's FY2027, worth weighing in any long-term Intercom/Fin decision.

The four ways to move data into Zendesk

There is no single "import everything" button. Which method you use depends on what you're moving and how much history you care about.

1. The native Data importer (organizations, users, custom objects — not tickets)

Zendesk ships a built-in data importer, found in Admin Center → Objects and rules → Tools → Data importer. It's CSV-based and genuinely useful, but its scope is narrow. Per Zendesk's own documentation, it imports users, organizations, custom object records, and IT asset records — and that's the whole list. Tickets are explicitly not supported. Files can't exceed 1 GB, with a recommended ceiling of around 500,000 rows per file (Zendesk: About the data importer).

So the native importer is the right tool for seeding your customer base and account structure — your organizations and users — before you go live. It is the wrong tool if your goal is to bring years of conversation history with you. For that, you need option 4.

2. CSV import (users and organizations)

Closely related: plain CSV imports for users and organizations, including their custom field values (Zendesk: importing and exporting custom fields and values). This overlaps heavily with the data importer and is the path most teams use when they're starting relatively fresh and only need contacts and accounts in place. Again — no tickets.

3. The Zendesk API

The REST API can create essentially anything, tickets included, and it's how every third-party migration tool actually does its work under the hood. Building your own API-based migration gives you total control, but it's an engineering project: you'll handle pagination, rate limits, attachment downloads/re-uploads, ID remapping, retries, and error handling yourself. Worth it for unusual data shapes or strict compliance requirements; overkill for a standard help-desk move.

4. Third-party migration services (full history)

For an actual full migration — tickets, conversations, attachments, knowledge base, and the rest — most teams use a dedicated service like Help Desk Migration (Relokia) or a similar provider. These tools call the API for you, map your old fields to Zendesk's, and move the bulk of your historical data with far less risk than a hand-rolled script. This is the standard route, and it's the assumption behind the "what moves" table below.

For exporting your data out of Zendesk first (or auditing what you have before a move), see our guide on how to export data from Zendesk.

What moves vs. what doesn't

Here's the core of it. The left column is your data — the things a third-party tool can carry across. The right column is your configuration — the things that are platform-specific and must be rebuilt in Zendesk by hand. Treat this as a planning checklist, not a guarantee: exact coverage varies by tool, plan, and source platform, so confirm specifics for your setup.

The pattern: objects move, behavior doesn't. A ticket is a record, so it travels. A trigger is logic that lives inside one platform's rules engine, so it doesn't. As one migration provider puts it, Zendesk triggers, macros, and automations are platform-specific and simply don't port to a different tool — they have to be recreated (eesel: how to migrate from Zendesk).

The "moves" side in more detail

A mature third-party migration moves a lot. Help Desk Migration, for example, transfers tickets with their comments, attachments, and CSAT data, plus contacts, organizations, agents, tags, custom fields, side conversations, and call recordings, and your entire knowledge base including article content, translations, images, and the category/section structure (Help Desk Migration: Zendesk). Custom fields get handled with care — dropdown normalization and multi-form field mapping — rather than dumped as raw text.

One nuance worth knowing for Zendesk-to-Zendesk moves (consolidating two instances): macros can be migrated via a dedicated Business Rules Migration feature, and Help Desk Migration notes that automations are disabled during the migration and re-enabled manually afterward (Help Desk Migration: business rules in Zendesk). Across different platforms, though, treat all business rules as rebuild work.

The "doesn't move" side is your real project plan

Here's the reframe that saves migrations: the right column is the work. Before you cut over, budget time to rebuild your triggers and automations, recreate your views, redefine SLA policies, set up groups and roles, reconnect every integration, rebuild any bot or AI flows, and re-theme your Help Center. Industry migration guides consistently list macros, triggers, automations, SLA policies, Explore dashboards, and app-dependent workflows as rebuild-not-migrate items (Gravity: Zendesk migration strategy). Historical Explore reporting is the one people mourn most — your past dashboards don't come with you, so export any reports you need to keep before you switch.

The caveats nobody warns you about

Even when data "moves," it doesn't always arrive looking identical. These are the gotchas that generate post-migration support tickets of their own.

• Ticket IDs change. This one surprises everyone. Help Desk Migration doesn't carry over source ticket IDs because Zendesk assigns its own IDs and they can't be overwritten (Help Desk Migration: Zendesk). The standard workaround is to create a custom text field in Zendesk and map your old ID into it during field mapping, so "ticket #44213" from your old system is still searchable after the move. Plan for this if any external links, internal docs, or customers reference old ticket numbers.
• Timestamps can shift. Don't assume every created/updated date survives. Notably, when knowledge base articles are imported, Zendesk replaces the original creation and update dates with the migration date (Help Desk Migration: Zendesk data migration checklist). Ticket dates are typically preserved by good tools, but verify it in your demo rather than trusting it.
• Agent assignments depend on mapping. Agents come over as users, and during setup you map each source agent to a Zendesk agent so historical tickets stay assigned to the right person (Help Desk Migration: Zendesk). This generally keys off matching email addresses — so make sure agent emails line up on both sides, or assignments scatter.
• Plan for downtime and a delta migration. Your old system keeps receiving tickets while the big migration runs. The clean pattern is a full migration of everything up to a cutoff, then a Delta Migration that sweeps up records created or changed since — available on Help Desk Migration's Signature support package (Help Desk Migration checklist). This is what lets you avoid a hard freeze on incoming support.
• Always run a demo/sandbox migration first. Help Desk Migration's Free Demo moves 20 sample tickets and 20 articles so you can inspect the result before committing — and as their checklist bluntly warns, if data is missing or wrong in the demo, the same issue will appear in the full migration (Help Desk Migration checklist). Test into a Zendesk sandbox where possible, eyeball a handful of tickets end-to-end, and only then run the real thing.

Your Zendesk migration checklist

A condensed, phase-by-phase checklist. Pair it with the platform-specific guide for your source (Freshdesk, Intercom).

Before migration

• Audit what you have. Count tickets, users, organizations, articles, and custom fields in the source system. This sizes the job and the cost.
• Decide your history cutoff. Moving five years of closed tickets is expensive and rarely useful. Many teams move open tickets + the last 12–24 months and archive the rest.
• Inventory your configuration (the "doesn't move" column): list every trigger, automation, macro, SLA, view, group, integration, and bot flow you'll need to rebuild.
• Export reports you want to keep, since historical Explore data won't migrate.
• Map your fields and agents ahead of time, and add a custom field to hold old ticket IDs if you need them.
• Stand up Zendesk basics first — brands, groups, custom fields, and an initial set of business rules — so imported data lands somewhere sensible.

During migration

• Run the free demo/sample migration and inspect 10–20 records by hand (comments, attachments, requester, assignee, dates, custom fields).
• Disable automations and triggers in the target so imported tickets don't fire notifications or actions at customers (Help Desk Migration checklist).
• Run the full migration against your cutoff. Don't touch the source config during the run.
• Keep the old system live for incoming tickets until cutover is confirmed.

After migration

• Run a delta migration to pull in anything created or updated since the full run.
• Spot-check thoroughly: ticket counts match, attachments open, requesters and agents are correct, articles render, custom field values populated.
• Re-enable and rebuild business rules — triggers, automations, SLAs, views — and reconnect integrations and apps.
• Verify timestamps and IDs, especially the old-ID custom field and KB article dates.
• Redirect or update links that referenced old ticket numbers or article URLs.
• Tell your team what changed (new IDs, where history lives) before you flip the switch for customers.

Where AI fits in — once your data has landed

Here's the part most migration guides miss. The two things you worked hardest to bring across — your knowledge base articles and your historical tickets — are exactly what an AI agent learns from to resolve future tickets. Your migrated content isn't just an archive; it's training data. Once it's all sitting in Zendesk, you've quietly assembled the ideal corpus for automation.

That's the layer Macha adds. To be clear about what it is and isn't: Macha is not a help desk and not a Zendesk replacement — it's an AI agent layer that runs on top of your existing Zendesk. It reads a customer's actual question, pulls from your connected knowledge base and past conversations, and resolves the issue inside the Zendesk ticket — while handling the housekeeping (tagging, routing, status) and escalating to a human, with full context, when it isn't confident.

The honest framing: it's another integration to configure, and it's only as good as the knowledge you connect it to — which is precisely why doing it after a clean migration makes sense. On cost, Macha bills per AI action — any automated step it takes, whether drafting a reply, tagging, routing, or resolving — not per closed ticket, because most automation is work done along the way, not a tidy "resolution." If you've just gone to the trouble of moving years of tickets and articles into Zendesk, connecting an AI agent is how you make that history actively pay off. You can try it free — 7-day free trial, no credit card required.

Frequently asked questions

Does the native Zendesk data importer move tickets? No. The built-in data importer (Admin Center → Objects and rules → Tools → Data importer) supports users, organizations, custom object records, and IT asset records only — tickets are not supported. To migrate tickets and conversation history, use the Zendesk API or a third-party service like Help Desk Migration.

What actually transfers to Zendesk in a migration? With a third-party tool, you can typically move tickets and their comments, attachments, requesters/users, organizations, agents (as users), tags, knowledge base articles, many custom field values, and — tool-dependent — CSAT ratings and inline images. Your configuration (triggers, automations, macros, SLAs, views, groups, integrations, dashboards, bot flows, business hours) does not transfer and must be rebuilt in Zendesk.

Will my ticket IDs stay the same? No. Zendesk assigns its own ticket IDs and they can't be overwritten, so old IDs change. The fix is to create a custom text field in Zendesk and map your original ID into it during setup, keeping the old number searchable.

Do creation dates and timestamps survive? Mostly, but verify. Good tools preserve ticket dates, but knowledge base articles take on the migration date rather than their original creation/update date when imported (Help Desk Migration checklist). Always confirm in a demo run.

Should I run a test migration first? Yes — always. Help Desk Migration offers a free demo of 20 tickets and 20 articles; whatever's wrong in the demo will be wrong in the full migration, so inspect it carefully and use a Zendesk sandbox where you can.

How do I avoid downtime during migration? Run a full migration up to a cutoff while keeping your old system live for new tickets, then run a delta migration to sweep up everything created or changed since. This avoids freezing support during the move.

The bottom line

A Zendesk migration is two projects: moving data and rebuilding configuration. The native data importer and CSV imports handle users, organizations, and custom objects — but not tickets; for full history you'll use the API or a third-party service like Help Desk Migration. On the data side, expect tickets, contacts, organizations, agents, attachments, tags, custom field values, and your knowledge base to come across (CSAT and inline images tool-dependent). On the configuration side, plan to rebuild triggers, automations, macros, SLAs, views, groups, integrations, dashboards, bot flows, and business hours from scratch. Watch the caveats — changed ticket IDs, shifted article dates, agent mapping by email — and never skip the demo. Get the data clean, rebuild the rules deliberately, and then put that migrated knowledge to work. For the step-by-step on your specific source, see the Freshdesk and Intercom guides; for what to pull out first, how to export data from Zendesk.

Migration scope and tool behavior verified against Zendesk and Help Desk Migration documentation, June 2026. Coverage varies by tool, plan, and source platform — confirm specifics for your own migration before relying on them.