How to Migrate from Freshdesk to Freshservice

Why teams make the support-to-ITSM move

The trigger is almost always the same: a support team on Freshdesk starts fielding internal IT requests — laptop provisioning, access grants, software installs — and discovers that a customer-support help desk has no native concept of the things those requests revolve around. There is no asset record for the laptop, no configuration item for the server, no change process for the deployment. Freshservice adds all of that. Its CMDB (configuration management database) stores assets and the relationships between them, so a ticket can be linked to the exact device or service it concerns, and change management wraps risky work in approvals instead of hope.

That is the gain worth migrating for. The cost is that Freshservice's richer object model does not fall out of a Freshdesk export automatically — assets and CMDB items are built fresh in Freshservice, and your Freshdesk data has to be mapped into a structure it was never shaped for.

What actually moves — and what you rebuild

Before touching any tool, it helps to see the whole picture at once. Based on Help Desk Migration's Freshdesk to Freshservice documentation and its Freshservice migration checklist, here is the honest split between what ports and what you re-create by hand.

The pattern is the one every honest migration guide will tell you: records travel, logic does not. Tickets, people, and articles cross the gap; the SLAs, automations, and reports that acted on them are re-created in the new system. Budget real time for that rebuild — it is usually the longest part of the project, not the data copy.

Step 1: Prepare Freshservice before you import anything

The single biggest cause of a messy migration is importing into a Freshservice instance that is still live and reacting. Per the migration checklist, turn the following off first:

1. Email notifications — Admin → General Settings → Email Notifications; disable across all tabs so migrated tickets don't blast your requesters.
2. Automations — deactivate every Workflow Automator rule and Scenario Automation so nothing fires on imported records.
3. Priority Matrix — toggle it off (Admin → Priority Matrix) so original ticket priorities are preserved rather than recalculated.
4. Closure rules — deactivate them (Admin → Service Management → Service Desk Settings) to stop unexpected status changes.
5. Parent-child ticketing — toggle off in Admin → Workflows to avoid errors on linked tickets.

Then do the prep that has to happen up front: replicate your custom fields. Custom fields only migrate if a matching field already exists in Freshservice, so re-create each one — same type, same required flag, same dropdown options — before the import runs. Get this wrong and custom-field data silently lands nowhere.

Step 2: Choose native import vs a dedicated migration tool

You have two realistic paths, and they suit different data sizes.

Freshservice's native CSV import is free and fine for the simple objects — requesters, agents, and especially assets, which do not come from Freshdesk at all and have to be built in Freshservice regardless. It is the right tool for standing up your CMDB. But CSV import is manual and rule-bound: per Freshservice's Importing Assets documentation, you can only import one asset type per import, you must create custom asset types and fields before importing, Display Name is mandatory, and serial numbers must be unique. It gives you no automated way to carry ticket conversations, history, or the cross-object relationships an ITSM instance depends on.

A paid migration tool like Help Desk Migration (Relokia) automates the ticket-and-history side — the part CSV can't handle well. Its process is: connect both platforms, map fields, run a free demo migration on a small sample, review the result, then run the full migration followed by a delta migration to catch anything that changed while you worked. Cost scales with record volume, attachment size, and customization — the free demo is how you get an exact quote before committing.

A common split that works: use the paid tool for tickets, contacts, agents, and the knowledge base; use native CSV import to build out assets and the CMDB from your own inventory data.

Step 3: Map fields carefully, then demo before you commit

Mapping is where a migration is won or lost. Because Freshservice renames and restructures things, you have to decide explicitly how each Freshdesk value lands: statuses, priorities, ticket types, and tags all need mapping, and custom fields need matching by name, type, and options. Two mappings people forget: contacts becoming requesters and companies becoming departments — check those relationships survived.

The safety net is the demo migration. Run it on a small, representative slice of tickets, then open Freshservice and verify the details: ticket formats, timelines, requester and department links, custom fields, tags, and attachments. If the closed_at/solved_at dates matter to you for reporting, confirm your custom-field mapping actually captured them here — before you migrate tens of thousands of records with the same mistake baked in. If migrating your Freshdesk history to a support platform rather than ITSM is what you actually need, the sibling Freshdesk to Zendesk migration guide covers that path instead.

The honest bit: downtime and what breaks

No migration is truly zero-downtime, and anyone who promises otherwise is selling something. Realistically the full cutover runs one to two weeks end to end, with a period of minimal downtime or read-only access during the main data copy — you keep Freshdesk answering live tickets, run the migration, then use a delta pass to sweep up anything that changed, and cut over.

Be clear-eyed about what does not survive the trip:

• Your SLA policies are gone — targets, reminders, and escalations all rebuild in Freshservice from scratch.
• Automations rebuild — every rule you wrote in Freshdesk is re-authored in the Workflow Automator.
• Reports and dashboards rebuild — historical analytics are re-created against the migrated data.
• Resolution timestamps slip unless you deliberately mapped them into custom fields.

None of this is a reason not to migrate. It is a reason to plan the migration as a rebuild project with a data-copy inside it, not a one-click import. The teams that get burned are the ones who treated the copy as the whole job and discovered on go-live day that their SLAs and reports were blank.

Where an AI layer fits — on the Freshdesk you keep

Not every team on Freshdesk actually needs the full weight of ITSM. If your driver is "our agents are drowning in repetitive tickets" rather than "we need asset and change management," a migration may be solving the wrong problem — the answer might be automation on the help desk you already run, which we cover in how to automate Freshdesk with AI.

That is the seam Macha fits into. Macha is an AI agent layer that runs on top of the Freshdesk you already use as a native connector — it is not a help desk, not a Freshdesk replacement, and not a reason to migrate. The broader category of AI agents for customer service exists to do the reasoning work — reading a ticket, drafting a grounded reply, looking up an order — that no amount of ITSM structure does for you, and it is worth understanding the build-versus-buy tradeoff before you add any of it. You connect Macha to Freshdesk with your subdomain and API key, and it reads and writes the same tickets, drafting or posting grounded replies and looking up account or order status through a custom tool that turns a REST API into something the agent can call.

One honest caveat, since this is a Freshservice post: Macha's connector is for Freshdesk specifically — not Freshservice, Freshchat, or Freshcaller. If your endgame is ITSM on Freshservice, Macha isn't the layer for that instance. And when it does apply, credits are consumed per AI action, not per resolution — the pricing page has the breakdown. The clean framing: migrate to Freshservice when you genuinely need assets, CMDB, and change management; automate on Freshdesk when you just need faster, smarter tickets.

FAQ

What data migrates from Freshdesk to Freshservice? Tickets (with notes and history), attachments and inline images, contacts (which become requesters), companies (which become departments), agents, and the knowledge base (categories, folders, and articles). Custom fields migrate only if you create matching fields in Freshservice first.

What does not migrate and has to be rebuilt? SLA policies, automations and workflows, and reports and dashboards do not port — you rebuild them by hand in Freshservice. Freshservice also doesn't migrate closed_at/solved_at dates by default, so map those into custom fields to preserve resolution history.

How long does the migration take and is there downtime? A full Freshdesk-to-Freshservice migration typically runs one to two weeks end to end, with minimal downtime or read-only access during the main data copy. A delta migration afterward catches records that changed while you worked, so you cut over cleanly.

Do my Freshdesk assets migrate into the Freshservice CMDB? No — assets and CMDB items are new to Freshservice and are built separately, usually via CSV import. You can import only one asset type per import, must create custom asset types and fields first, and Display Name is required with unique serial numbers.

Can I add AI to Freshdesk instead of migrating? Yes. If your goal is deflecting repetitive tickets rather than IT asset management, an AI agent layer like Macha connects to Freshdesk as a native connector and runs on top of it — no migration required. Macha connects to Freshdesk specifically, not Freshservice.

Planning the migration but want your Freshdesk agents faster in the meantime? Start a free trial of Macha and connect it to your Freshdesk in minutes.