How to Migrate to Freshdesk (2026): Step-by-Step

This guide is the migration-in playbook: why teams move to Freshdesk, exactly what to bring, how to import each data type (and which ones need the API or a migration service), how to map your statuses, priorities, agents and custom fields, the pitfalls that bite real migrations, and a pre/post go-live checklist. It's the mirror image of our how to migrate from Freshdesk guide — if you're going the other direction, start there. And if you're standing up a brand-new instance rather than moving data in, pair this with how to set up Freshdesk. Details are verified against Freshdesk's support docs and the Freshworks Marketplace as of June 2026; Freshworks revises its tooling periodically, so confirm specifics in your own account before you rely on them.

Why teams move to Freshdesk

Most migrations to Freshdesk trace back to one of a few reasons:

• Cost. Teams leaving Zendesk or another incumbent often cite per-agent pricing creep; Freshdesk's lower tiers (including a free plan for small teams) are a common landing spot.
• Simplicity. Smaller support teams find Freshdesk faster to administer than heavier enterprise suites.
• The Freshworks ecosystem. If you already run Freshsales, Freshchat, or Freshservice, consolidating on one vendor and one bill is appealing — and Freshdesk Omni brings ticketing, chat, and bots into a single omnichannel workspace.
• Channel coverage out of the box. Email, portal, chat, phone (Freshcaller), and social in one place, without a long list of paid add-ons.

Whatever the trigger, the migration mechanics are the same. Let's start with what you're actually moving.

What to bring (and what to leave behind)

Inventory your source data before you touch Freshdesk. The usual list:

Two judgment calls worth making early. First, how much ticket history do you actually need? Migrating five years of closed tickets is slow, expensive on per-record migration tools, and rarely useful. Many teams import only open/pending tickets plus the last 3–12 months of closed ones, and keep a read-only export of the rest as an archive. Second, don't try to migrate configuration. Macros, automation rules, SLA policies, and dispatch'r workflows don't port cleanly between platforms — rebuild them natively in Freshdesk using your old setup as a reference. Treat migration as data, and the new instance as a fresh, better-organized configuration.

Step 1 — Set up the Freshdesk destination first

Migrate into a configured instance, not an empty one. Before importing a single record:

1. Create your Freshdesk account and pick the plan you'll actually run on (the API and most automation features aren't on the legacy free/Sprout tier — check our API guide for the plan gate).
2. Add your agents and groups so tickets have someone to be assigned to.
3. Recreate your custom fields under Admin → Support Operations → Ticket Fields and Customer Fields. This is mandatory: Freshdesk's contact import will only map a custom column if that field already exists.
4. Set up your email channel (forwarding/mailbox) and business hours, but — importantly — leave outbound notifications and automations off until after the import (more on why under Pitfalls).

The full walkthrough lives in how to set up Freshdesk; do that first, then come back here for the data.

Step 2 — Map your fields before you export anything

Mapping is where migrations succeed or fail. Build a simple spreadsheet that lines up every source field with its Freshdesk equivalent. The fields that always need attention:

• Statuses. Freshdesk's defaults are integer-coded: 2 = Open, 3 = Pending, 4 = Resolved, 5 = Closed. Decide how each of your source statuses maps in (e.g. Zendesk's "Solved" → Resolved, "Pending"/"On-hold" → Pending).
• Priorities. Freshdesk uses 1 = Low, 2 = Medium, 3 = High, 4 = Urgent. Map your source scale onto those four.
• Agents. Match by email address — every imported ticket and reply needs to resolve to a real Freshdesk agent, so create the agents first and keep an email-to-email lookup.
• Custom fields. Map each one to the field you created in Step 1; note the data type (text, dropdown, number) so values import cleanly.
• Companies/organizations. Decide whether company associations come in via the contact import (Freshdesk will auto-create a company if the name doesn't exist) or are pre-loaded via the Companies import.

Write this mapping down. It becomes the spec for both your CSV columns and any migration tool's field-mapping screen.

Step 3 — Import contacts and companies (native)

This is the easy, well-supported part. Freshdesk has built-in CSV/Excel import for both, per its docs:

1. Go to the Contacts page (or Companies via the hamburger menu) and click Import.
2. Upload your CSV/Excel file. The first row must be column headers.
3. Map columns to Freshdesk fields, including any custom fields you created in Step 1.
4. Choose Skip duplicates or Update duplicates so you don't double-create existing records.
5. Run the import and review the results email.

A few rules that trip people up, straight from Freshdesk:

• Each contact row must have Name + Email, or Name + Phone — rows missing both are skipped.
• Custom fields must already exist in Freshdesk before import (Step 1).
• Format phone numbers with the country code (e.g. +14088481234) so the phone channel recognizes them.
• If a row's company name doesn't exist yet, Freshdesk creates it — handy, but it means typos spawn duplicate companies. Clean your data first.
• Keep files under ~10MB and around 25,000 contacts per import; split larger lists into batches.

Import companies first (or include a clean company column on the contact file), then contacts, so associations land correctly.

Step 4 — Import tickets (API or migration service)

Here's the part that surprises people: Freshdesk has no native CSV/bulk import for tickets. The Contacts/Companies importer doesn't cover them. You have exactly two real options (confirmed in Freshworks' community):

Option A — The Freshdesk REST API. Write a script that reads your exported tickets and creates them via POST /api/v2/tickets, then adds each reply/note via the conversations endpoint. This gives you full control and no per-record fee, but it's a real engineering task — see how to use the Freshdesk API for auth, endpoints, and rate limits. Know these documented limitations before you commit:

• You generally can't set arbitrary created/updated timestamps on imported tickets via the regular API — imported tickets tend to carry their import date, not the original date.
• You can't post agent replies as anyone other than the agent whose API key you're using, so multi-agent conversation history collapses onto one author unless you loop credentials.
• The regular API may send notification emails to customers when you create replies — exactly what you don't want during a bulk backfill.

Option B — A migration service. The official "Import to Freshdesk" app on the Freshworks Marketplace is powered by Help Desk Migration, which supports automated transfer from 80+ source platforms — including Zendesk, Zoho Desk, Help Scout, HubSpot Service Hub, and Salesforce Service Cloud (supported list). These tools handle the threading, attachments, agent mapping, and (importantly) timestamp preservation that the raw API struggles with, and they offer a free test/demo migration plus a field-mapping UI. Pricing is typically by record volume — get a quote for your ticket count; it's usually worth it versus weeks of scripting for anything beyond a few hundred tickets. (Other established services like Import2 do the same job.)

Rule of thumb: a few hundred tickets and an engineer on hand → the API may be fine. Thousands of tickets, multiple agents, attachments, and timestamp fidelity that matters → use a migration service.

Step 5 — Import your knowledge base

Solution (KB) articles have their own path. The official route, per Freshdesk, is to email a CSV of your articles to Freshdesk support ([email protected]), and their team processes the import — with columns for title, description/body, tags, status, category, and folder. For larger or richer knowledge bases, the same migration services from Step 4 will move articles, folders (sections), and categories — including HTML body, SEO metadata, attachments, and publication status — automatically. Either way, plan to re-check internal links between articles afterward, since URLs change with the platform.

Step 6 — Validate before you cut over

Run a test migration on a sample first if your tool supports it (most do). Then validate against your source:

• Counts match — tickets, contacts, companies, and articles within expected tolerances.
• A handful of spot-checked tickets show the right requester, agent, status, priority, full conversation thread, and attachments.
• Custom field values carried over and landed in the right fields.
• Agent assignments resolve to real Freshdesk agents (no orphaned tickets).
• KB articles render correctly and inter-article links work.

Fix mapping issues and re-run rather than patching by hand.

Migration pitfalls to plan around

These are the failure modes that show up again and again:

• Threading. API-created conversations can flatten multi-party threads. Verify reply order and authorship on sample tickets; this is the single biggest reason teams choose a migration service over the raw API.
• Timestamps. Imported tickets often show the import date, not the original. If "when did this come in" matters for reporting or SLA history, you need a tool that preserves original timestamps — the regular API generally won't.
• Agent/ID mapping. Tickets reference agents by ID; if an agent doesn't exist in Freshdesk yet, the ticket lands unassigned or fails. Create all agents first and map by email.
• Notification storms. Importing replies through the live API can fire customer emails. Disable outbound notifications/automations during the import window, then re-enable.
• Custom fields missing. Import silently drops values for fields you didn't pre-create. Build them in Step 1.
• Downtime / dual-running. Decide your cutover model: a hard switch (freeze the old system, migrate, go live) or a parallel period (run both briefly). Communicate the support email/portal change to customers either way.
• Duplicate companies. Auto-creation on typo'd company names spawns duplicates — clean source data before import.

Add an AI layer once you're on Freshdesk

One honest aside, since it's a natural "what's next" after a migration. Once your tickets, contacts, and knowledge base are settled in Freshdesk, the next lever isn't another data move — it's deflecting and drafting the repetitive tickets automatically. That's where an AI agent layer like Macha fits. Macha isn't a help desk and isn't a Freshdesk replacement — it runs on top of your existing Freshdesk, using its API plus your freshly migrated knowledge base to triage, draft, and resolve routine tickets, while anything it's unsure about stays a normal ticket for a human with full context attached. (We built this on Zendesk first; the same model applies to Freshdesk — see Macha on Zendesk.) The honest trade-offs: it's another integration to configure, and it's only as good as the KB you point it at — which is exactly why right-after-migration, with clean articles, is a good time to evaluate it. Billing is per AI action — each automated step — not per closed ticket. You can try it free — 7-day free trial, no credit card required.

Pre/post go-live checklist

Before cutover:

• [ ] Destination configured: plan chosen, agents + groups added, custom fields created, email channel set up.
• [ ] Field mapping spreadsheet complete (statuses, priorities, agents, custom fields).
• [ ] Source data cleaned (dedupe contacts/companies, format phone numbers).
• [ ] Contacts + companies imported and spot-checked.
• [ ] Ticket import method chosen (API vs. service) and test migration validated.
• [ ] KB articles imported; inter-article links checked.
• [ ] Outbound notifications/automations disabled for the import window.

At/after cutover:

• [ ] Full ticket import run and validated (counts, threads, timestamps, attachments, assignments).
• [ ] Notifications/automations, SLA policies, macros, and dispatch rules rebuilt and re-enabled.
• [ ] Email forwarding / portal pointed at Freshdesk; customers notified of any new support address.
• [ ] Agents trained on the new workspace; a few live tickets handled before announcing widely.
• [ ] Old system kept read-only as an archive for an agreed window.
• [ ] Reporting/dashboards rebuilt; AI layer evaluated against the migrated KB if relevant.

Frequently asked questions

Can I import tickets to Freshdesk from a CSV? No. Freshdesk's native importer covers contacts and companies, but not tickets. To bring tickets in you use the Freshdesk REST API (POST /api/v2/tickets) or a migration service like the official "Import to Freshdesk" app (powered by Help Desk Migration). The API has limits around timestamps, multi-agent replies, and customer notifications, so most teams with more than a few hundred tickets use a service.

How do I migrate from Zendesk to Freshdesk? Recreate your configuration in Freshdesk first (agents, custom fields, channels), import contacts/companies via CSV, then move tickets and KB articles with a migration service — Help Desk Migration supports Zendesk → Freshdesk directly, including agent mapping and timestamp preservation. Map Zendesk statuses/priorities to Freshdesk's (Solved → Resolved, etc.) before you start.

Does Freshdesk import contacts and companies natively? Yes. From the Contacts or Companies page, click Import, upload a CSV/Excel file, and map columns. Each contact needs Name + Email or Name + Phone, custom fields must exist beforehand, and you can choose to skip or update duplicates. Keep files under ~10MB and ~25,000 records per import.

How do I import my knowledge base into Freshdesk? The official method is to email a CSV of your articles (title, body, tags, status, category, folder) to [email protected] for their team to process. For larger or richer knowledge bases, a third-party migration tool can move articles, folders, HTML content, attachments, and publication status automatically.

Will my ticket timestamps and history be preserved? Not reliably via the raw API — imported tickets often carry the import date, and agent replies can collapse onto a single author. A dedicated migration service is designed to preserve original timestamps and per-agent authorship, which is why it's the safer choice when history matters.

How long does a Freshdesk migration take? Contacts/companies are minutes to hours. Tickets depend on volume and method: a scripted API import is gated by rate limits (and your engineering time), while a migration service runs in the background over hours to a few days for large datasets, with a test run first. Plan a maintenance window for the final cutover.

The bottom line

Migrating to Freshdesk is two very different jobs in one project. Contacts, companies, and knowledge base have supported, low-friction import paths — native CSV for the first two, a support-assisted CSV (or migration tool) for the third. Tickets are the hard part: there's no native import, so you either script against the Freshdesk API (fine for small volumes, with real limits on timestamps and threading) or use a migration service like the official Import to Freshdesk app for anything serious. Do the boring prep — configure the destination, build your field mapping, clean your data, and run a test migration — and the cutover is calm instead of chaotic. Heading the other way instead? See how to migrate from Freshdesk. Starting fresh? See how to set up Freshdesk.

Freshdesk import and migration details verified against Freshdesk's support documentation and the Freshworks Marketplace, June 2026. Freshworks updates its tooling, plans, and limits periodically — confirm import options, field requirements, and any migration-service pricing in the live docs and your own account before relying on them.