Migrating Freshdesk to Freshservice

Same vendor, same login, very different product. To migrate from Freshdesk to Freshservice is easier than leaving Freshworks and harder than people assume.

Start free trial All guides

Why teams migrate from Freshdesk to Freshservice

Freshdesk is built for customer support. Freshservice is built for IT service management. Both are Freshworks products, both put a ticket at the centre, and that shared shape is exactly what makes people underestimate the gap.

The trigger is almost always one of three things. IT started using the customer helpdesk because it was already there, and has now outgrown it. Somebody needs assets tracked against tickets. Or a change process, an approval chain or an ITIL-shaped audit requirement has arrived and there's nowhere to put it.

If none of those apply to you, don't move. The side-by-side comparison is worth reading before you commit, because a lot of teams who think they need ITSM actually need three custom fields and an automation.

What maps across cleanly

The core objects have direct counterparts, and this is the part that goes well.

Tickets become incidents or service requests. The conversation, the requester, the timestamps and the attachments all have somewhere to land.

Contacts become requesters. Same idea, different vocabulary. Companies become departments, which is close enough for most organisations and slightly wrong for a few.

Agents and groups. Group structure carries over conceptually, though roles and permissions are modelled differently and you should expect to rebuild rather than import them.

Solution articles become knowledge base articles. The content moves; the folder and category structure usually needs rethinking because the audience changed from customers to employees.

SLA policies and business hours. The concepts are the same. Rebuild them rather than trying to transfer them, because Freshservice has priority and impact dimensions that Freshdesk does not.

Custom fields. They move, but plan the mapping first. This is where an unplanned migration turns into a field called Custom Field 7 that nobody dares delete two years later.

What has no equivalent going back

The asymmetry is the point. Freshservice has whole modules Freshdesk simply lacks, and there's nothing in your Freshdesk data to fill them.

The service catalogue. In Freshservice, a request for a laptop or access to a system is a catalogue item with its own form, approval and fulfilment workflow. In Freshdesk that was an email. You're not migrating this, you're designing it, and it's the largest single piece of work in the project.

Assets and the CMDB. Freshdesk has no asset model at all. Everything here comes from a discovery tool, an existing inventory or a spreadsheet, not from your old helpdesk.

Change, problem and release. Same story. New processes, not migrated ones.

Approvals. Freshservice models approval as a first-class step. Any approval you were faking in Freshdesk with a status and a private note gets rebuilt properly.

And going the other way, a few Freshdesk things don't transplant. Marketplace apps are per-product, so check each one has a Freshservice equivalent. Portal customisation is rebuilt. Satisfaction survey history and ticket ID sequences generally do not survive intact, so if you report on year-over-year trends, export a clean archive before you start.

Running both during the transition

The most common shape, and the one I would recommend, is not a cutover at all. It's a split by audience.

External customers stay in Freshdesk. Internal employees move to Freshservice. Two products, two portals, two email addresses, one company. That's a completely legitimate permanent end state, and plenty of Freshworks customers run exactly that.

If you do need a genuine cutover, keep the old instance read-only rather than deleting it. Freeze new ticket creation, redirect the inbound address, and leave Freshdesk accessible to agents for historical lookup for at least a quarter. Somebody will need a ticket from four months ago in week three. They always do.

For the overlap period, connect them. The Freshdesk and Freshservice integration lets a customer-facing ticket raise a linked internal one, which stops agents copying and pasting between two browser tabs and losing half the context on the way.

A sequence that works

Roughly eight weeks for a mid-sized team, longer if the service catalogue is ambitious.

Weeks one and two. Audit what you have. Every ticket type, every automation, every custom field, every integration. Mark each one keep, redesign or drop. Expect to drop a third.

Weeks three and four. Build the Freshservice foundation. Groups, roles, business hours, SLAs, ticket forms. No data yet.

Week five. Design the service catalogue with the people who will actually request from it. This is the step teams skip and then regret.

Week six. Migrate data into a sandbox or a test instance. Check a sample of tickets by hand, not by row count. Row counts always match, content often does not.

Week seven. Pilot with one department. Fix what they find.

Week eight. Redirect inbound, announce it properly, and keep Freshdesk open behind you.

Announce it properly matters more than it sounds. Half of a failed rollout is people continuing to email the old address because nobody told them not to. If you want the wider picture on where Freshservice fits, the Freshservice hub has it.

FAQ

Frequently asked questions

Is there an official migration guide?

Freshworks documents the move. Any Freshdesk to Freshservice migration guide covers the same ground as this page: what maps, what doesn't, and the parallel period. Teams switch from Freshdesk to Freshservice when assets and change control start mattering.

Is there an automatic way to migrate from Freshdesk to Freshservice?

There are import tools and Freshworks can assist, but treat it as a rebuild with a data import rather than a lift and shift. Tickets, contacts and articles move. Workflows, roles and portals get rebuilt.

Can I run Freshdesk and Freshservice at the same time?

Yes, and for many companies it is the right permanent answer. Customers stay in Freshdesk, employees go to Freshservice, and the integration links tickets across the two when a customer issue needs internal IT.

Do my Freshdesk ticket IDs carry over?

Generally not in a way you can rely on. Export a full archive before you cut over if you report on historical trends or need old tickets for audit.

What's the hardest part of the migration?

The service catalogue. It has no Freshdesk equivalent, so there is nothing to migrate and everything to design, and it's the part employees judge the new system on.

Should every Freshdesk customer move to Freshservice?

No. If you support external customers and have no asset, change or approval requirement, Freshdesk is the correct product and Freshservice will feel like paperwork.

Duplicates survive a migration

Ticket Merger merges duplicate tickets automatically in Freshdesk and Zendesk today. Freshservice support is coming soon, so a move doesn't have to mean losing it.

Start free trial

14-day free trial. No credit card required.

Published August 18, 2026