Freshdesk Migration Checklist & Timeline

What moves vs what you rebuild

Start here, because this single distinction shapes your entire plan. The records that describe your customers and their history migrate cleanly. The configuration that describes how your help desk behaves does not — it has to be recreated in Freshdesk's interface. Per Help Desk Migration's Freshdesk data migration checklist, the split looks like this:

The line to internalise: operational logic doesn't port. Freshworks' own Import to Freshdesk migration app moves records, not rules. Budget real hours for rebuilding SLAs and automations — that work is often the longest pole in the tent, not the data transfer itself.

Native CSV import vs a paid migration tool

Freshdesk ships a native importer, but it's narrower than most people assume. Out of the box, the CSV import handles contacts and companies — you upload a UTF-8 CSV with a header row, map columns to Freshdesk fields, and duplicates merge on email. That's genuinely useful for a fresh contact list, and it's free. What it does not do is bring across tickets, full conversation threads, attachments, or historical timestamps.

For a real switch from another help desk — where you need ticket history, conversations, and attachments preserved — you reach for a dedicated tool like Help Desk Migration's Import to Freshdesk. Those tools run at roughly 2,000 tickets per hour and let you filter by date range, status, agent, or brand. The tradeoff is honest: the native importer is free but contacts-only; the paid tool costs money but preserves the history your agents need to answer follow-ups. Pick based on whether you're seeding a list or relocating a support history.

Phase 1: Pre-migration checklist

Do this in the days before you touch any data. Rushing here is where most migrations break.

1. Name an owner. One person owns the plan, the go/no-go call, and the rollback decision.
2. Provision the destination. Create agents, groups, business hours, and — critically — pre-create every custom field, because fields must exist before records can map into them.
3. Grab API credentials. Note the source platform's API URL and key; the migration tool needs both.
4. Disable interfering automations. Before any test run, turn off ticket-creation, time-triggered, and scenario automations so migrated tickets don't trigger a flood of stale rules. (Alternatively, tag migrated tickets and exclude them from rules.)
5. Run a demo migration. Transfer a small sample, then review 20 random tickets for comment authors, agent assignment, custom fields, attachments, tags, and inline images. Download the demo report for migrated/failed/skipped records.
6. Pick your timing. Choose a low-volume window and decide whether the old system stays live during the transfer.

Phase 2: During the migration

Once the demo checks out, you run the full migration. A few rules keep it clean:

1. Send the 24-hour heads-up to agents (template below), then a "stop using the old system" cutoff message when the full run starts.
2. Freeze configuration. Don't edit fields, agents, or groups mid-run — changing the target's shape while data lands is how mappings break.
3. Let it run. Full migrations take anywhere from 20 minutes to several days depending on volume, at that ~2,000 tickets/hour rate. You can keep handling tickets in the source or target while it works.
4. Plan a delta pass. If the old system stayed live, run a delta migration afterward to catch records created or updated during the transfer. (Note: delta migration typically requires the migration vendor's top-tier support plan.)

Phase 3: Post-migration validation

Going live isn't "the import finished" — it's "we verified it." Work this list before you flip the switch:

1. Spot-check records. Confirm tickets, contacts, conversations, custom fields, tags, and attachments are present and correctly attributed.
2. Test the rebuilt logic. Fire test tickets through your new SLA policies, automations, and dispatch rules — the parts that didn't migrate. This is where surprises hide.
3. Fix knowledge base links. Update internal article links and re-upload inline images before the old system expires.
4. Verify agent access. Confirm profiles, roles, and permissions landed correctly for every agent.
5. Watch the first 48 hours. Keep the source system readable (not writable) as a reference until you're confident nothing's missing.

Your rollback plan

Every migration needs an exit. The good news: a well-run migration is additive — you're importing into Freshdesk, not deleting the source — so rollback is mostly about not committing prematurely.

• Keep the source system read-only, not deleted, for at least a week post-cutover. It's your source of truth if something's off.
• Define a go/no-go checkpoint. If post-migration validation fails on something material (missing conversations, broken assignments), the owner calls it: pause routing to Freshdesk and send agents back to the source while you diagnose.
• Isolate imported data. Tagging migrated tickets means you can bulk-identify or, if needed, delete a bad batch and re-run — without touching anything created natively in Freshdesk.
• Never let both systems be "live" for writing at once beyond the planned overlap. Dual-write chaos is worse than a delayed cutover.

Agent-comms template

Communication is half the migration. Here's a template to adapt — one message 24 hours out, one at cutover.

Subject: Freshdesk migration — starting tomorrow at [time] Team, we're moving to Freshdesk. Starting [date/time], the full data migration begins. Your tickets, contacts, and history are all coming with us. During the transfer, please [keep working in the old system / stop new work in the old system] until you get the all-clear. A few rules you'll rebuild (SLAs, canned responses) may look different at first — that's expected. Questions to [owner].

Subject: We're live on Freshdesk — please switch now Freshdesk is live. Please stop using [old system] and work all new tickets in Freshdesk from now. If a ticket looks like it's missing history, don't panic or edit it — flag it to [owner] and we'll check the migration report. Thanks for your patience through the switch.

Where an AI layer fits after you land

Once you're live, the rebuild backlog is real — SLAs, automations, and routing rules all need reconstructing. That's the moment many teams reconsider how much of that logic they want to hand-code versus hand to an agent, and it's worth weighing the build-versus-buy tradeoff honestly. The broader category of AI agents for customer service exists to do the reasoning-heavy triage-and-reply work that brittle rule chains struggle with.

Macha is one such layer, and to be clear about what it is: it runs on top of the Freshdesk you just migrated into as a native connector — it does not replace Freshdesk or compete with it. You connect Macha with your subdomain and API key, and it reads and writes the same tickets you just imported: triaging by intent, drafting or posting grounded replies, and looking up order or account status through a custom tool that turns a REST API into something the agent can call. That means a chunk of the post-migration automation you'd otherwise rebuild rule by rule can be handled by AI agents you configure instead. Macha's connector is for Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller — and credits are consumed per AI action, not per resolution; the pricing page breaks that down.

FAQ

What data actually migrates to Freshdesk, and what doesn't? Tickets and conversations, contacts, companies, attachments, tags, notes, agent assignments, and knowledge base articles migrate with the right tool. SLAs, automations, triggers, dispatch rules, canned responses, and reports do not migrate — you rebuild those manually in Freshdesk's interface.

How long does a Freshdesk migration take? The data transfer itself runs at roughly 2,000 tickets per hour, so a full migration spans anywhere from 20 minutes to several days depending on volume. Budget separately for pre-migration setup and for rebuilding automations and SLAs, which is often the longer task.

Can I migrate with Freshdesk's free native import instead of a paid tool? Only partly. The native CSV importer handles contacts and companies — useful for seeding a list — but it doesn't bring across tickets, conversation history, or attachments. For a real help-desk switch you need a dedicated migration tool.

What's a safe rollback plan if the migration goes wrong? Keep your old system read-only (not deleted) for at least a week, define a go/no-go checkpoint after validation, tag migrated tickets so a bad batch can be isolated and re-run, and never let both systems accept new writes at the same time beyond the planned overlap.

Does adding AI to Freshdesk mean replacing it? No. A layer like Macha connects to Freshdesk as a native connector and runs on top of it — it doesn't replace your help desk. After migrating, it can handle triage and grounded replies while Freshdesk stays the system of record.

Migrated in and staring down a rebuild backlog? Start a free trial of Macha and connect it to your Freshdesk in minutes.