How to Migrate from Freshdesk: Export Inventory, Field Mapping and Cutover Plan

To migrate from Freshdesk without losing anything you need, export every object your team depends on (tickets with their conversations, contacts, companies, knowledge base articles, canned responses and automation rules), map each field to its destination before importing, and run both systems side by side for about a week with Freshdesk kept read-only as your rollback. Import open tickets in full, archive old closed history instead of re-creating it, and write down each Freshdesk feature you are giving up along with how you will cover it. The rest of this page is the runbook: the export inventory, a field mapping table, a day-by-day cutover plan, the parallel run, the rollback, and the gaps.

This guide covers the mechanics only. For whether to leave Freshdesk at all and how the alternatives compare, read the Freshdesk alternatives and pricing guide. If you are moving off Zendesk instead, the steps differ enough that we wrote a separate Zendesk migration guide.

Step 1: Build the Export Inventory

Teams get surprised by the objects nobody thought to export: canned responses, custom ticket statuses, time entries, or satisfaction ratings that a manager still quotes in reviews. List every object before you export anything, then give each one an owner and a disposition: migrate (move it into the new system), rebuild (re-create it by hand), archive (keep a read-only copy you can search), or retire (deliberately drop it).

Freshdesk object	How to get it out	Typical disposition	Watch for
Tickets	Ticket list CSV export for the fields; the REST API for full records	Migrate open tickets, archive old closed ones	The API ticket list returns only recent tickets by default, so pass an updated_since date far enough back to cover your full history
Ticket conversations (replies and private notes)	REST API, one call per ticket	Migrate for open tickets, archive for closed	The CSV export does not include the full thread. Keep public replies and private notes apart
Attachments	Download through the URLs in API responses	Migrate for open tickets, archive the rest	Attachment links can expire, so download the files while you export instead of saving the links
Contacts	Contacts CSV export	Migrate	Duplicates with different email addresses, and custom contact fields
Companies	Companies CSV export	Migrate	Contacts that have no company, and companies whose names differ only by suffix ("Acme" and "Acme Inc.")
Agents and groups	Admin screens; write them down by hand	Rebuild	Departed agents who are still assignees on open tickets
Ticket fields, custom statuses, ticket types	Admin field settings; screenshot every dropdown	Rebuild as a mapping	Custom statuses such as "Waiting on third party" that have no one-to-one equivalent
Solution articles (knowledge base)	REST API, by category, folder and article	Migrate	Article-to-article links and images hosted on Freshdesk
Canned responses	REST API or copy-paste	Rebuild or archive	Placeholders that only work in Freshdesk
Automations (ticket creation, ticket update, time triggers)	No clean export, so screenshot and transcribe each rule	Rebuild or retire	Rules that reference deleted agents, groups or products
SLA policies and business hours	Admin screens	Archive as documentation	Response-time commitments in customer contracts
Satisfaction ratings and time entries	REST API or reports export	Archive	Managers who still report on them
Email setup (support addresses, forwarding)	Admin email settings and your mail provider	Rebuild	Forwarding rules on your own mail server that point at Freshdesk

Menus and export options differ by Freshdesk plan and role. Record the method you actually used and the time you ran it in a migration log. Once the export is done, keep the raw files read-only and do all cleanup on copies, so you always have an untouched source to go back to.

Step 2: Decide How Much History to Bring

When a ticket is re-created in a new help desk it gets a new number and a new created date. Re-importing years of closed tickets therefore produces thousands of records that look recent, fill up your status counts, and are harder to search than a good archive. Split your history into three tiers instead:

1. Open, pending and recently updated tickets: migrate in full, with every reply and note. Agents will keep working these.
2. Recently closed tickets (choose the window from how far back agents actually look): migrate them as closed tickets with the conversation attached, so agents can see a customer's recent problems on their record.
3. Everything older: archive it as the original export files plus the downloaded attachments, stored somewhere your team can search and with access limited to the people who need it. Write down who can open the archive and how long you keep it.

Base the window on real lookups, not on a habit. Ask your agents how far back they actually scrolled last month. Check whether any customer contract requires you to keep records for a set period.

Step 3: Map Every Field Before You Import

Build the mapping from the column headers in your own export, not from field labels that look similar. The table below maps Freshdesk's standard ticket fields to PipeCrush ticketing. Use it as a starting point and add a row for each custom field you have.

Freshdesk field	PipeCrush destination	Transformation
Ticket ID	Ticket custom field "Freshdesk ID", plus a tag such as fd-import	Keep it as text. It is how you cross-reference the archive and old customer emails
Subject	Subject	Required. Give blank subjects a placeholder such as "No subject (Freshdesk #ID)"
Description	Description	Required. Convert the HTML to readable text and keep the links
Status	Status	See the status table below
Priority (Low, Medium, High, Urgent)	Priority (Low, Medium, High, Urgent)	Maps one-to-one
Type	Type	See the type table below
Requester	Contact, matched by email	Import contacts first, then link each ticket to its contact
Company	Customer (company) record	Import companies through the contact import's Company column
Agent	Assignee	The user must already exist. Leave tickets from departed agents unassigned and review them
Group	Tag (for example group-billing)	Groups have no direct equivalent, so tags let saved views filter by team
Tags	Tags	Carry over as they are, after you remove near-duplicates
Source (email, portal, phone, chat)	Tag (for example source-email)	Imported tickets get their own source value, so keep the original channel as a tag
Created at, resolved at	Ticket custom date fields "Original created" and "Original resolved"	The new system stamps the import time, so keep the real dates in fields
Public replies	Ticket comments	Put the original author and timestamp at the top of each comment body
Private notes	Internal ticket comments	Must stay internal. Check this on your sample import
Custom ticket fields	Ticket custom fields	Create the fields first, and make one required only after the import
CC and BCC, satisfaction rating, time spent	Archive	No matching ticket fields. They stay in the archive

Status and type mapping

Freshdesk status	PipeCrush status
Open	Open
Pending	Waiting
Custom "waiting on customer" or "waiting on third party" statuses	Waiting, plus a tag naming who you are waiting on
Resolved	Resolved
Closed	Closed

Freshdesk type	PipeCrush type
Question	Question
Incident	Technical issue
Problem	Bug
Feature Request	Feature request
Refund	Billing
Anything custom	Other, plus a tag carrying the original type

Choose the right import path

PipeCrush gives you two ways to bring tickets in, and they suit different jobs:

• CSV import takes subject, description, priority and type. Imported tickets arrive open and unassigned. That makes it a good fit for a simple backlog, and a poor fit for history that needs statuses, threads or links to contacts.
• The REST API (part of the PipeCrush API platform) creates a ticket with tags, custom fields, an assignee, and links to a contact and customer. Comments can then be added as public or internal, and the status updated afterward. Use it for the open-ticket tier and anything else that needs its full conversation.

Contacts use their own CSV import. You map columns to name, email, phone, title and company, and you can create custom contact fields during the mapping step. Rows with no company go under an "Unassigned" company, so fill in the company column first if you want contacts grouped correctly.

Step 4: Move the Knowledge Base

PipeCrush's knowledge base imports articles from a CSV file (title, content, plus optional excerpt, category, tags and slug) or from Markdown and HTML files. Imported articles arrive as drafts, which gives you a natural review step before anything goes public.

1. Export articles through the API with their category and folder. Freshdesk has categories, folders and articles. PipeCrush has categories, subcategories and tags, so map each folder to a subcategory or a tag.
2. Search the exported HTML for links pointing to your Freshdesk portal domain, and list every article-to-article link that will need its new URL.
3. Download any images that Freshdesk hosts and re-upload them, because those image links stop working once the old portal is shut down.
4. Rewrite steps that describe Freshdesk screens ("open the Freshdesk portal and...").
5. Publish in batches, then set up redirects from your old help center URLs if your public help center domain is changing.

Publishing an article with sync turned on also adds it to your AI chatbot's training. So finish the knowledge base before you put a support chatbot in front of customers.

Step 5: Write Down What You Lose, and How You Will Cover It

Every help desk switch drops something. Finding a gap during the parallel run is fine. Finding it in a customer escalation is not. These are the Freshdesk capabilities that do not carry over to PipeCrush one-to-one:

Freshdesk capability	What PipeCrush has	How to keep the outcome
Email-to-ticket conversion	Tickets come from the AI chatbot, the AI receptionist, a public ticket form, CSV import and the API. Email lands in the Inbox	Send customers to the public ticket form for issues you need to track, handle quick questions in the Inbox, or create tickets from mail through the API
SLA policies and timers	No SLA engine. You get priorities, status tiles and saved views	Keep a saved view of open urgent and high-priority tickets sorted by age, and check it at set times each day
Ticket automations (dispatch, observer, time triggers)	Automations run on CRM events (leads, deals, forms, calls, appointments, replies), not on ticket events	Turn routing rules into team conventions plus saved views per queue. Use bulk assignment for triage
Round-robin ticket assignment	Manual and bulk assignment. Assignees get email notifications	Assign a triage owner for each shift who hands out the queue
Canned responses	No saved-reply library in ticketing	Turn the answers customers actually need into knowledge base articles, and keep internal macros in a shared document
CSAT surveys	No built-in satisfaction surveys	Archive past ratings, and send a short survey link by email if you still need the metric
Original ticket numbers and dates	New numbers and dates on import	"Freshdesk ID" and original-date custom fields, as in the mapping table
Time tracking	Not in ticketing	Archive past entries. Track billable time in the tool your invoicing already uses

If any row on this list is a hard requirement (a contractual SLA with penalties, for example), settle it before you set a cutover date, not after.

Step 6: The Day-by-Day Cutover Plan

The plan below assumes a cutover on a Monday, written as T. Tuesday through Thursday also work. Avoid Fridays and the day before a holiday, because the first 48 hours after cutover need full staffing. Stretch the earlier phases if the sample import shows your data needs more cleanup than expected. Don't shorten the parallel run.

When	Owner	Work	Exit check
T-21 (Monday, three weeks out)	Migration lead	Inventory signed off, gaps table agreed, cutover date announced to the team	Every object has an owner and a disposition
T-18 to T-15	Migration lead, admin	Full export, checksums recorded, raw files locked read-only	Source counts recorded for each object
T-14 to T-11	Admin	Create users, ticket custom fields and saved views. Import contacts and companies	Contact counts match after deduplication. Rejected rows logged
T-10 to T-8	Support lead	Sample import of about 50 tickets covering every status, type, private notes and attachments	Statuses, internal notes and contact links correct on every sample ticket
T-7 to T-5	Content owner	Knowledge base imported as drafts, links and images fixed, articles published	Every article in the approved list renders and its links work
T-4 to T-2	Support lead	Agent training on the five most common workflows. Dry run of the cutover steps	Every agent has logged in and closed a test ticket
T-1 (Friday before)	Migration lead	Freeze Freshdesk configuration changes. Import the open-ticket tier	Open-ticket count in PipeCrush matches Freshdesk
T (Monday)	Admin, mail owner	Switch intake: ticket form links, chatbot widget, help center links, support mailbox connection. Import the weekend delta	A test request through each channel lands where expected
T+1 to T+7	Support lead	Parallel run (see below). Daily count reconciliation	No request handled in both systems, none handled in neither
T+8	Acceptance owner	Go or no-go decision. Freshdesk set to read-only	Acceptance checklist passes
T+30	Migration lead	Final archive check, then cancel or downgrade Freshdesk	The archive is searchable without Freshdesk

Step 7: Run Both Systems in Parallel Without Double Replies

The biggest risk of a parallel run is two agents answering the same customer from two systems. One rule prevents it: a ticket is finished in the system where it is open.

• From T onward, every new request is created and worked in PipeCrush.
• Tickets that were open in Freshdesk at T-1 were imported, so they are worked in PipeCrush too. Close them in Freshdesk with an internal note saying "moved to PipeCrush #1234".
• If a customer replies to an old Freshdesk email thread during the week, the agent who sees it moves the reply into the matching PipeCrush ticket as a comment and answers from there.
• Each day, one person compares new requests across both systems and fixes any ticket that was missed or duplicated.

Keep your Freshdesk subscription active through T+30 even after you set it to read-only. That way the rollback stays cheap and agents can still look up anything the archive does not cover well.

Step 8: The Rollback Plan

Write the rollback down before cutover day, so nobody has to invent it under pressure. Roll back if any of these happen during the parallel run:

• Requests from any intake channel go missing for more than a few hours.
• Agents cannot see internal notes, or internal notes show up to customers.
• Open-ticket counts drift between the two systems and nobody can explain why.
• A customer-facing link (ticket form, help center, chatbot) is broken and cannot be fixed the same day.

The rollback itself has three steps. Point the intake channels back to Freshdesk, which means reversing exactly the T-day changes you logged. Export any tickets created in PipeCrush during the parallel run through the API and re-create them in Freshdesk. Then fix the cause and pick a new cutover date. Because Freshdesk stayed live and unchanged, rolling back takes hours, not a rebuild.

Acceptance Checklist

• Contact, company, ticket and article counts match the migration log, and every rejected row has a recorded reason.
• The sample of migrated tickets shows the right status, priority, type, contact link and internal notes.
• Every intake channel delivered a test request to the right place.
• Each row in the gaps table has a named owner and a working alternative.
• The archive is searchable, access is limited to the right people, and the retention period is written down.
• The acceptance owner has signed off, and only then does Freshdesk get cancelled.

Frequently Asked Questions

How long does a Freshdesk migration take?

With the plan above, about three weeks of preparation, one cutover day, a one-week parallel run, and a 30-day read-only period before you cancel. The things that stretch it are data cleanup (duplicate contacts, messy custom fields) and the number of automations you need to rebuild. Run the sample import before you promise anyone a date.

Can I keep my Freshdesk ticket numbers?

Not as the ticket number itself, because the new system numbers tickets in its own sequence. Store the original number in a "Freshdesk ID" custom field and add an import tag, so agents can search by the old number and cross-reference the archive.

Do I need to migrate all my closed tickets?

Usually not. Migrate open tickets and the recently closed ones agents actually look up, and archive the rest with controlled access. Re-created closed tickets get new dates, which makes old history look current and clutters your queue views.