How to Migrate from Freshdesk to Salesforce Service Cloud

What actually moves: mapping Freshdesk to Salesforce objects

Freshdesk and Salesforce Service Cloud model support data differently, so the first thing to get straight is which Freshdesk entity becomes which Salesforce object. The two products don't share a schema — Freshdesk is a ticket-centric help desk, while Service Cloud sits on top of Salesforce's relational CRM data model, where a support interaction is a Case hanging off a Contact and, usually, an Account.

According to Help Desk Migration's Freshdesk-to-Salesforce mapping, the standard object mapping looks like this:

• Freshdesk Tickets → Salesforce Cases (the heart of the migration)
• Freshdesk Contacts → Salesforce Contacts
• Freshdesk Companies → Salesforce Accounts
• Freshdesk Agents → Salesforce Users
• Knowledge Base Categories → top-level categories/folders, and Articles → Salesforce Knowledge Articles

At the field level, a ticket carries more than its subject line. Per Help Desk Migration's Salesforce Service Cloud data-migration documentation, a migrated ticket can bring across its ID, subject, tags, status, source, priority, due date, created/updated/closed timestamps, and its full comment thread including public replies, internal notes, and attachments. Contacts carry name, email, phone, company, language, time zone, and any custom fields you've defined.

The status and audit-field problem

Two mapping details cause most of the post-migration surprises, and they're worth calling out before you start.

Statuses don't line up one-to-one. Freshdesk ships with Open, Pending, Resolved, and Closed; Salesforce Cases default to New, Working, Escalated, and Closed. You have to decide the translation explicitly — for example, Freshdesk Open and Pending mapping to Salesforce New and Working. Get this wrong and your reporting on "how many tickets are actively being worked" will be nonsense on day one.

Audit fields need special handling. By default, Salesforce stamps CreatedDate and CreatedById at the moment a record is inserted — which, during a migration, is today, not the day the ticket originally opened. To preserve real history you have to migrate the audit fields (CreatedDate, LastModifiedDate, CreatedById, CloseDate) deliberately, which usually means enabling Salesforce's "Set Audit Fields upon Record Creation" permission or handling it in your middleware's scripting layer. This is the single most common thing teams forget.

Your three routes across

There isn't one canonical way to move. There are three, and they trade cost against control.

1. A dedicated migration tool (SaaS wizard). Services like Help Desk Migration (built by Relokia) connect to your Freshdesk source and your Salesforce target, let you map fields in a UI, run a free demo/test migration on a data sample, and then execute the full run. This is the fastest path for a standard ticket-and-contact move. The HDM wizard itself lives behind a signup wall, but its public page shows the directional Freshdesk → Salesforce Service Cloud setup.
2. Middleware / ETL tooling. Tools like Dell Boomi, Talend, Dataloader.io, or Salesforce's own Data Loader give you low-level control over transformations and are the usual choice when you have heavy custom-field logic or need to reshape data mid-flight. Exalate is a common pick when you want bi-directional sync (running both systems in parallel during a phased cutover) rather than a one-time lift, and its scripting engine handles status and audit-field remapping.
3. A partner-led implementation. For enterprise moves with custom objects, complex routing, or regulated data, a Salesforce implementation partner runs the migration as part of a broader Service Cloud build-out. Slower and pricier, but appropriate when the migration is the small part of a large re-platforming.

For most mid-market teams, the SaaS-wizard route handles 90% of the volume, and you reserve middleware only for the fields it can't express. If you're weighing this move against staying in the Fresh ecosystem or going elsewhere, our Freshdesk-to-Zendesk migration guide covers the comparable lift for that target.

What moves vs what you rebuild

This is the table to internalise before you scope the project. Record data ports; operational logic does not. Every automation, SLA, and report you rely on has to be re-authored natively in Service Cloud, because the two platforms express those rules in completely different languages.

The reason none of the bottom half moves is structural, not a tool limitation: a Freshdesk automation rule is a Freshdesk object with no equivalent JSON to hand Salesforce. Even Exalate and the enterprise ETL tools can only reconstruct logic by re-authoring it — they don't teleport it. Budget real hours for this; it's where honest migration timelines double.

Downtime, testing, and the honest limits

Reputable migration tools advertise zero downtime, and for the data move itself that's largely true: they run a staged background sync from your live Freshdesk into Salesforce while both systems keep serving customers, then you cut over. Help Desk Migration also offers unlimited free test migrations on a data sample and a Delta migration to catch records that changed after the full run started — which is exactly what saves you from losing the tickets created during a multi-day migration.

But be clear-eyed about a few things. First, timelines: a small migration can finish inside 24 hours, while larger volumes commonly run one to five business days, and enterprise moves with heavy customisation stretch to a week or two. Second, the real downtime isn't the data — it's the cutover of operations: the window where automations, SLAs, and routing exist in Salesforce but haven't been fully tested, so tickets can fall through gaps. Third, cost is quote-based, scaling with record volume and the options you enable, so a "free" tool still carries a real bill on large datasets. Native Freshdesk export (CSV) is genuinely free but gives you flat files with none of the object relationships intact — fine for archival, useless for a working Service Cloud instance. Weigh the paid tool's relationship-preserving import against the DIY spreadsheet slog before you assume free means cheaper.

Where an AI agent layer fits — before and after

A re-platforming is a natural moment to rethink automation, and it's worth separating two decisions: which help desk you run on, and what does the reasoning-heavy work on top of it. The category of AI agents for customer service exists to handle the triage-and-draft work that neither Freshdesk nor Service Cloud does natively, and there's a real build-versus-buy tradeoff in how you add it.

Here's the part teams miss: you don't have to wait for the migration to finish to get value from automation. Macha runs as an AI agent layer on top of the Freshdesk you already use — it connects to Freshdesk as a native connector (with your subdomain and API key), reads and writes the same tickets, and can automate your Freshdesk queue with AI while you're still on it. That means you can deflect volume and clean up your ticket data before you move, so you're migrating a leaner, tidier dataset into Service Cloud rather than dragging years of noise across. Macha connects to Freshdesk specifically — not Freshchat, Freshservice, or Freshcaller — and it looks up order or account status through a custom tool that turns a REST API into something an agent can call, so replies are grounded in your real systems. Credits are consumed per AI action, not per resolution — the pricing page breaks that down.

Macha is a layer on top of your help desk, never a replacement for it: it doesn't compete with Freshdesk or Salesforce, it does the work the ticket engine can't. Whichever platform wins your migration, the automation layer travels with the workflow, not the vendor.

FAQ

What do Freshdesk tickets become in Salesforce Service Cloud? Tickets map to Salesforce Cases. Contacts map to Contacts, Companies map to Accounts, and Agents map to Salesforce Users. Knowledge base categories become folders/top-level categories and articles become Salesforce Knowledge articles.

Does a migration move my Freshdesk automations, SLAs, and reports? No. Migration tools move record data — tickets, contacts, companies, articles, attachments — but automations, SLA policies, macros, routing rules, business hours, and reports do not port. You re-author them natively in Service Cloud (Flows, Entitlements/Milestones, Omni-Channel routing, and Salesforce Reports).

Will I have downtime during the migration? The data move itself is typically zero-downtime — tools run a staged background sync while both systems stay live, with a Delta migration to catch records changed mid-run. The riskier window is the operational cutover, when your rebuilt automations and SLAs go live and need testing.

How long does a Freshdesk to Salesforce migration take? Small migrations can finish inside a day; most run one to five business days depending on volume, and large or heavily customised enterprise moves can take one to two weeks. Rebuilding automations and reports is usually the longer half of the project.

Can I automate Freshdesk with AI before I even migrate? Yes. An AI agent layer like Macha connects to your existing Freshdesk and can triage and draft replies while you're still on it — so you migrate a cleaner, lower-volume dataset into Service Cloud. It's a layer on top of your help desk, not a replacement for Freshdesk or Salesforce.

Planning your move and want the automation to travel with you? Start a free trial of Macha and connect it to your Freshdesk in minutes.