How to Migrate from Freshdesk to Salesforce Service Cloud (2026)

To successfully migrate Freshdesk to Salesforce Service Cloud, engineering and operations teams must treat the project as a full architectural translation. You are moving from a standalone, purpose-built helpdesk to an enterprise CRM platform with an integrated service layer. Every object, field, and automation in Salesforce exists within a programmable, multi-tenant context governed by strict execution limits and relational hierarchies.

This guide covers the exact data model mapping, API constraints, automation redesign strategies, cost considerations, and execution steps required to import Freshdesk data into Salesforce without breaking historical context or triggering governor limits.

For a detailed comparison of helpdesk architectures before committing to this move, see our Zendesk vs Salesforce Service Cloud architecture guide. If you are migrating from Zendesk instead, the Zendesk to Salesforce Service Cloud migration guide covers that path.

Why Teams Migrate from Freshdesk to Salesforce Service Cloud

Teams do not make this move because Freshdesk is broken — they make it because the organization has outgrown what a self-contained helpdesk can offer.

The triggers are specific:

• Platform consolidation. The organization is standardizing on Salesforce across sales, marketing, and service. One Account record connecting pipeline deals, support Cases, and marketing engagement eliminates the data silo between Freshdesk and the CRM.
• Enterprise service features. Salesforce offers Entitlements and Milestones for complex multi-tier SLA management, Omni-Channel for real-time presence-based routing with agent capacity management, and Einstein AI for predictive case classification and routing.
• Regulatory requirements. Salesforce's security model — Shield Platform Encryption, Event Monitoring, Field Audit Trail — satisfies compliance mandates (HIPAA, FedRAMP, SOX) that Freshdesk's security layer cannot.
• Programmability. The team needs Apex, Lightning Web Components, custom APIs, or governor-limit-aware automation that Freshdesk's configuration model cannot accommodate.

Three architectural differences make this migration non-trivial:

• Platform vs. Product: Freshdesk is a self-contained helpdesk. Salesforce is a fully programmable platform with its own database, automation engine (Flows), and deployment infrastructure (sandboxes, change sets, Salesforce CLI).
• Data Hierarchy: Freshdesk is ticket-centric and allows orphaned contacts. Salesforce enforces an Account → Contact → Case hierarchy — every Contact requires an AccountId.
• Execution Constraints: Salesforce enforces strict per-transaction governor limits (100 SOQL queries, 150 DML statements, 6 MB heap size, 10,000ms CPU time per transaction), requiring bulk-safe design for all automations. Freshdesk uses three simple automation engines (Dispatch'r, Supervisor, Observer); Salesforce uses one programmable platform (Flow) bound by these limits.

For a broader look at the business drivers behind this transition, read our analysis on why top-performing teams migrate to Salesforce.

Freshdesk vs. Salesforce Service Cloud: Cost Comparison

Cost is a primary planning variable. Salesforce licensing is significantly more expensive than Freshdesk and structured differently.

Freshdesk pricing (per agent/month, billed annually, as of 2025):

Salesforce Service Cloud pricing (per user/month, billed annually, as of 2025):

Critical cost factors beyond per-user licensing:

• File storage overage. Salesforce base storage is 10 GB + 2 GB per full user license. Overage pricing is approximately $5/month per additional GB for file storage, $125/month per additional GB for data storage. A Freshdesk instance with 50 GB of attachments will incur significant storage costs.
• Experience Cloud (customer portal). Requires separate licensing — Customer Community login-based licenses start at $2/member/month; Customer Community Plus starts at $6/member/month.
• Shield Platform Encryption. If regulatory compliance drove the migration, Shield is an add-on priced at approximately 30% of the base Salesforce license cost.
• Service Cloud Voice. Amazon Connect telephony integration requires additional per-minute telephony costs plus the Voice SKU.
• Sandbox allocation. Professional edition includes 1 developer sandbox only. Enterprise includes 1 partial copy + 25 developer sandboxes. Unlimited includes 1 full copy sandbox. Full copy sandboxes are required for realistic data-volume testing.

Example TCO comparison for a 30-agent team (annual):

This cost differential is the reason the migration decision must be driven by genuine platform requirements — consolidation, programmability, regulatory — not feature comparison alone.

Freshdesk to Salesforce Service Cloud Object and Field Mapping

The object mapping defines the migration scope. Every mapping decision below must be made before any data is loaded.

• Freshdesk Tickets → Salesforce Cases. Each ticket becomes one Case. Freshdesk statuses (Open, Pending, Resolved, Closed + custom) map to Salesforce Case Status picklist values. Freshdesk priority (1 Low, 2 Medium, 3 High, 4 Urgent) maps to Case Priority. Freshdesk ticket types (Question, Incident, Problem, Feature Request) map to Case Type or Record Type. Freshdesk ticket source (Email, Portal, Phone, Chat) maps to Case Origin — add any missing picklist values before data load. Be careful with status design: Salesforce distinguishes between "Closed" (IsClosed = true) and other statuses, and closed values in Lightning depend on Support Process configuration.
• Freshdesk Companies → Salesforce Accounts. Accounts sit at the top of the data hierarchy. Map core fields (Name, Domain, Description). Load these first.
• Freshdesk Contacts → Salesforce Contacts. Every Salesforce Contact must have an AccountId. Freshdesk contacts without a company association will fail to load. Audit for orphaned contacts and assign a default "Individual" Account or associate by email domain before migration.
• Freshdesk Agents → Salesforce Users. Not a data import — a configuration task. Each agent needs a Salesforce license, a Profile (defining object access), and Permission Sets.
• Freshdesk Groups → Salesforce Queues. Create Queues in Setup, assign agent members, and integrate with Omni-Channel for real-time routing. Queue-based Omni-Channel is the normal first implementation; skills-based routing is a second layer, not a default shortcut.
• Freshdesk Products → Salesforce Record Types or custom Product picklist. Freshdesk's multi-product support (available on Pro+) maps to either Case Record Types (if workflows differ per product) or a custom picklist field on Case (if only categorization is needed). Multi-product Freshdesk instances with separate portals per product will need multiple Experience Cloud sites in Salesforce — each with its own configuration and potentially separate licensing.
• Freshdesk Tags → Custom field on Case. Salesforce's native Tag feature is limited and rarely used. Migrate to a custom multi-select picklist (if values are enumerable, max 500 values) or a custom text field (if free-form). Define picklist values in Salesforce metadata before loading.
• Freshdesk Custom Ticket Fields → Salesforce Custom Fields on Case. Type matching is strict: Freshdesk dropdown → Salesforce Picklist (values must be defined in metadata first), Freshdesk dependent dropdown → Salesforce Dependent Picklist, Freshdesk multi-line text → Long Text Area (max 131,072 characters), Freshdesk number → Number, Freshdesk checkbox → Checkbox, Freshdesk date → Date. All custom fields must exist in Salesforce before the data load. Salesforce allows up to 500 custom fields per object on Enterprise edition.
• Freshdesk Ticket Forms (Pro+) → Salesforce Record Types + Page Layouts. A Freshdesk instance with 3 ticket forms maps to 3 Salesforce Case Record Types, each with its own page layout, picklist value set, and Support Process.
• Freshdesk Ticket Attachments → Salesforce Files (ContentVersion + ContentDocumentLink). Plan around ContentVersion and ContentDocumentLink in Lightning Experience, not legacy attachments. File size limit per ContentVersion is 2 GB via API. Check storage allocation before migrating large attachment volumes.
• Freshdesk Solutions (KB) → Salesforce Knowledge (Knowledge__kav). Freshdesk Categories → Data Category Groups (max 3 active groups by default), Folders → Data Categories (max 100 categories per group by default), Articles → Knowledge Articles. In Lightning Knowledge, record types replace article types. Check Salesforce's default data category limits early if your knowledge base is deeply nested.

Sample Field Mapping Template

Use this as a starting template. Export to CSV and extend with your custom fields:

freshdesk_field,freshdesk_type,salesforce_object,salesforce_field,salesforce_type,notes
ticket_id,integer,Case,Freshdesk_ID__c,Text(External ID),External ID - Unique
subject,string,Case,Subject,Text(255),Direct map
description,html,Case,Description,Rich Text Area,HTML preserved in Rich Text
status,integer,Case,Status,Picklist,"Map: 2=Open, 3=Pending, 4=Resolved, 5=Closed + custom"
priority,integer,Case,Priority,Picklist,"Map: 1=Low, 2=Medium, 3=High, 4=Urgent"
type,string,Case,Type,Picklist,Add missing values to picklist metadata
source,integer,Case,Origin,Picklist,"Map: 1=Email, 2=Portal, 3=Phone, 7=Chat + custom"
group_id,integer,Case,OwnerId,Lookup(Queue),Map Freshdesk group_id to Salesforce Queue ID
responder_id,integer,Case,OwnerId,Lookup(User),Agent assignment - overrides Queue if set
company_id,integer,Account,Freshdesk_ID__c,Text(External ID),Load Accounts first
contact_name,string,Contact,Name,Name,Split into FirstName/LastName
contact_email,string,Contact,Email,Email,Dedup key
created_at,datetime,Case,CreatedDate,DateTime,Requires Create Audit Fields enabled
updated_at,datetime,Case,LastModifiedDate,DateTime,Requires Create Audit Fields enabled

The Conversation Fidelity Decision

This is the single most consequential mapping decision in a Freshdesk to Salesforce migration. Freshdesk ticket conversations — replies and notes — are rich, threaded interactions with HTML formatting, timestamps, and author attribution. Salesforce offers three paths:

• Path A — CaseComment. Simple, flat text. CaseComment.CommentBody is plain text only — no HTML support, and the practical body limit is 4,000 characters. IsPublished controls public (true) vs. private (false). Fast to implement, but lossy for rich content.
• Path B — EmailMessage. Salesforce's EmailMessage object supports HtmlBody, FromAddress, ToAddress, MessageDate (settable — preserves original timestamps), and Status (Sent/Received). Requires Email-to-Case to be enabled. This path preserves HTML formatting, author attribution, and timestamps. More complex but higher fidelity.
• Path C — Hybrid. Freshdesk public email replies → EmailMessage (preserving HTML and timestamps). Freshdesk private notes → CaseComment (IsPublished = false) or Chatter FeedItem (for rich text and @mentions).

Migration Approaches for Freshdesk to Salesforce Service Cloud

No single tool handles this migration end-to-end. The right approach depends on volume, fidelity requirements, and internal Salesforce expertise.

a) Freshdesk CSV Export + Salesforce Data Loader. Freshdesk's Admin → Account → Export produces CSV files for tickets, contacts, and companies. Salesforce Data Loader or Data Import Wizard can ingest Accounts and Contacts from CSV. Limitation: Freshdesk's CSV export does not include threaded conversation history (individual replies and notes with timestamps and authors). Conversation data requires API extraction. Complexity: Low. Fidelity: Low.

b) API-Based ETL (Freshdesk REST API → Salesforce Bulk API 2.0). Extract from Freshdesk via GET /api/v2/tickets (paginated, 30 per page by default), GET /api/v2/tickets/{id}/conversations (paginated, 30 per page), GET /api/v2/contacts, GET /api/v2/companies. Freshdesk rate limits are plan-based and account-wide: Free 50 req/min, Growth 200 req/min, Pro 400 req/min, Enterprise 700 req/min (support.freshdesk.com). Avoid using ?include=conversations on the tickets list endpoint as your full-history strategy — Freshdesk documents that embedded conversations are capped at 10 entries and consume extra API credits; the dedicated /conversations endpoint provides the complete threaded history. Transform to Salesforce schema. Load via Bulk API 2.0. Salesforce creates internal batches of 10,000 records each and supports up to 15,000 batch submissions per rolling 24-hour period. Complexity: High. Fidelity: High.

c) Third-Party ETL Tools (MuleSoft, Jitterbit, Informatica). Visual mapping interfaces with enterprise middleware. High total cost of ownership — overkill for a one-time historical migration unless the team already owns the tool. More compelling for ongoing integration or bi-directional sync than for a one-time import.

d) Managed Data Migration Service. A provider handles extraction, transformation, load-order orchestration, and validation. Best fit when ticket volume exceeds 50K, conversation history fidelity is non-negotiable, or the team lacks Salesforce data architecture expertise. Often engaged alongside a Salesforce implementation partner (SI) — the SI builds the org, the migration service loads the historical data.

Best fit by scenario:

Migration Architecture: Load Order and Throughput

[For engineering] Salesforce enforces referential integrity. The load order is not optional:

1. Accounts (get Salesforce Account IDs)
2. Contacts (with AccountId referencing Accounts from step 1)
3. Cases (with ContactId and AccountId referencing steps 1–2)
4. CaseComments or EmailMessages (with ParentId referencing Cases from step 3)
5. ContentVersions + ContentDocumentLinks (files attached to Cases)
6. Knowledge Articles (if migrating via Knowledge API)

Create a custom external ID field (Freshdesk_ID__c, External ID, Unique) on Account, Contact, and Case. Use upsert for all parent object loads — this enables idempotent re-runs and lets Salesforce resolve lookup references automatically (e.g., set Case.ContactId by referencing Contact.Freshdesk_ID__c). For child records like CaseComment and EmailMessage, maintain an external manifest mapping Freshdesk conversation IDs to Salesforce parent Case IDs so you can resolve parent references and rerun insert-only loads cleanly when audit fields are involved.

// Salesforce Bulk API 2.0 — Create upsert job for Cases
POST /services/data/v62.0/jobs/ingest
{
  "object": "Case",
  "operation": "upsert",
  "externalIdFieldName": "Freshdesk_ID__c",
  "contentType": "CSV",
  "lineEnding": "LF"
}
// Then PUT CSV data to the job's contentUrl
// Monitor job status via GET /services/data/v62.0/jobs/ingest/{jobId}
// Retrieve failed records via GET /services/data/v62.0/jobs/ingest/{jobId}/failedResults

Sample Bulk API error response for failed records:

"sf__Id","sf__Error","Subject","Freshdesk_ID__c","Status","Priority"
"","REQUIRED_FIELD_MISSING:Required fields are missing: [ContactId]:ContactId --","Billing inquiry","FD-98234","Open","Medium"
"","INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST:Status: bad value for restricted picklist field: Waiting on Customer:Status --","Login issue","FD-98235","Waiting on Customer","High"

Common Bulk API error codes and fixes:

Throughput math: Bulk API 2.0 processes 10,000 records per internal batch asynchronously. A 200K-Case migration loads in roughly 20 batches. CaseComment/EmailMessage creation via REST API is slower — at Salesforce's concurrent limit of 25 requests, expect ~500–1,000 records/min. For a 200K-ticket migration with an average of 8 messages per ticket (1.6M records), plan for 1–3 days of comment loading. Freshdesk extraction at 400 req/min (Pro plan) is the extraction bottleneck — 50K tickets with conversations takes ~4–6 hours minimum (1 call per ticket for conversations + 1 call per 30 tickets for list pagination).

API limit awareness by Salesforce edition:

A REST-only migration burns through this fast — 100K CaseComments equals 100K API calls. Use Bulk API 2.0 wherever possible (each Bulk API job counts as 1 API call regardless of record count). For smaller control operations, Salesforce Composite API can pack up to 25 subrequests into one request. If the daily API limit constrains your load, request a temporary limit increase from Salesforce support — they typically grant this for data migrations with 48 hours' notice.

Sandbox Strategy for Test Loads

[For engineering] Salesforce offers four sandbox types. The right choice for migration testing depends on your data volume:

Recommendation: Use a Developer Pro sandbox for initial mapping validation (1K records). Use a Partial Copy sandbox for the 5K-record test load in Step 5. If your production load exceeds 200K records, run at least one full-volume dress rehearsal in a Full Copy sandbox to validate throughput, governor limit behavior, and load timing before the production cutover.

Enterprise edition includes 1 Partial Copy + 25 Developer sandboxes. Full Copy sandboxes require Unlimited or Performance edition, or can be purchased as an add-on ($7,500–$15,000/year depending on the contract).

Step-by-Step Freshdesk to Salesforce Service Cloud Migration Process

Build the org first, then move the data. Salesforce configuration is the critical path, not the raw record load.

Step 1: Audit the Freshdesk Instance (Week 1) Count tickets, contacts, companies, custom fields, ticket forms, groups, automations (count each Dispatch'r, Supervisor, and Observer rule separately), attachments (total size in GB), knowledge articles, canned responses, and CSAT survey configuration. Document chat and phone usage. Use the Freshdesk API to get exact counts: GET /api/v2/tickets?per_page=1 returns total count in the Link header. Decide how much history agents actually need in Salesforce — common cutoffs are 12 months, 24 months, or all history. For deciding what historical data needs to move, see the Help Desk Data Migration Playbook.

Step 2: Design and Configure the Salesforce Org (Weeks 2–8) Create custom fields, picklist values, Record Types, Page Layouts, Support Processes, Profiles, Permission Sets, Queues, Omni-Channel routing (Service Channels, Routing Configurations, Presence Statuses), Entitlement Processes, Email-to-Case, and the Lightning Service Console — all in a Salesforce sandbox. Data migration cannot begin until the target schema exists. This phase takes 3–8 weeks and is the primary reason this project has a 3–10x timeline multiplier compared to helpdesk-to-helpdesk migrations.

Step 3: Make the Conversation Fidelity Decision (Week 1–2) Choose between CaseComment, EmailMessage, or hybrid for migrating Freshdesk ticket conversations. Test with 50–100 sample tickets in week 1. Do not defer this.

Step 4: Establish the External ID Strategy (Week 2) Create a Freshdesk_ID__c field (External ID, Unique, Text) on Account, Contact, and Case. Use the upsert operation for parent object loads. Plan insert-only child loads if you need audit-field preservation via the Create Audit Fields feature.

Step 5: Run a Sandbox Test Load (Weeks 4–6) Extract a representative sample (1,000–5,000 records) from Freshdesk. Transform and load into the Salesforce sandbox (Developer Pro or Partial Copy). Validate: field mapping completeness, conversation fidelity (HTML rendering, timestamps, author attribution), Flow behavior under bulk (200+ records), referential integrity (no orphaned Cases or Comments), closed-status/Support Process behavior, and picklist value coverage. If Record-Triggered Flows are not bulkified, they will fail during this test. Use our QA checklist here.

Step 6: Deploy Configuration to Production (Week 7–8) Deploy the validated configuration from the sandbox to the production org using change sets, the Salesforce CLI (sf project deploy start), or an unlocked package. Verify all custom fields, picklist values, Record Types, and Flows are present in production before proceeding.

Step 7: Execute the Production Data Load (Weeks 8–10) Use Salesforce Bulk API 2.0 to load Accounts, Contacts, and Cases sequentially. Use the REST API or Composite API for objects like EmailMessage and ContentVersion. Schedule off-hours loads (evenings/weekends reduce contention with user activity), and temporarily deactivate non-critical Flows or implement a "Bypass Automation" custom setting (a Custom Setting or Custom Metadata Type checked at the start of each Flow) during data load. Keep Freshdesk live until validation is complete.

Step 8: Handle Errors and Retries (Ongoing during Step 7) Parse the per-record success/failure results returned by the Bulk API via GET /services/data/v62.0/jobs/ingest/{jobId}/failedResults. Identify and resolve errors — see the error code table above. Salesforce rejects records with picklist values not defined in metadata, and these appear as failed records in the batch results rather than throwing a top-level error — making them easy to miss if you only check job-level status.

Step 9: Validate and Cut Over (Weeks 10–12) Reconcile record counts (Freshdesk export totals vs. Salesforce SOQL COUNT() queries), test Email-to-Case threading, queue routing, macros, Knowledge article visibility, and Omni-Channel presence routing. Run agent UAT for 2–3 days. Keep Freshdesk accessible as a read-only archive during stabilization. Make Salesforce the system of record only after validation is complete.

Rollback Plan

If critical issues surface post-cutover:

1. Immediate (Day 1–3): Revert Email-to-Case routing back to Freshdesk by changing MX records or email forwarding rules. Agents return to Freshdesk for new tickets. Salesforce retains the migrated data but is not the active system.
2. Short-term (Week 1–2): Fix the identified issues in the Salesforce sandbox, redeploy, and reload any data that was corrupted. Because external IDs enable idempotent upserts on parent records, re-running the load is safe.
3. Abandon (rare): If the Salesforce org design is fundamentally wrong, the team continues using Freshdesk while the SI redesigns. Migrated data in Salesforce can be deleted via Bulk API hard-delete.

The key enabler for rollback is keeping Freshdesk active (even in read-only mode) for at least 2–4 weeks post-cutover. Do not cancel the Freshdesk subscription until the Salesforce org has been stable for a full billing cycle.

How to Redesign Freshdesk Automations for Salesforce

Freshdesk has three named, single-purpose automation engines. Salesforce has one programmable platform. You cannot migrate automations — you must redesign them.

• Dispatch'r (on-create rules) → Simple assignment rules map to Salesforce Case Assignment Rules. Complex on-create logic maps to Record-Triggered Flow (runs on Case create, "After Save" type). Auto-replies map to Case Auto-Response Rules.
• Supervisor (time-based rules) → SLA-driven escalation maps to Salesforce Entitlements + Milestones (define Entitlement Processes with First Response and Resolution Milestones, configure Milestone Actions for warn/violation). Non-SLA time-based rules map to Scheduled-Triggered Flow. Plan 3–5 days for Entitlement design alone.
• Observer (on-update rules) → Record-Triggered Flow (runs on Case update). Field change detection is native — use Entry Conditions to specify which field changes trigger the Flow.
• Scenario Automations → Salesforce Macros (Lightning Service Console). Multi-step agent-triggered actions: insert text, update fields, send email. Canned replies map to Quick Text (max 4,096 characters per Quick Text record).
• SLA Policies → Salesforce Entitlement Management. Entitlements define service levels per Account/Contact/Asset. Milestones define targets (First Response Time, Resolution Time). Business Hours define operating schedules per timezone. Milestone Tracker component on the Case page layout provides visual SLA status.

How to Migrate Freshdesk Solutions to Salesforce Knowledge

Salesforce Knowledge offers data categories, record types (replacing article types in Lightning), versioning, and approval workflows.

Extract content via the Freshdesk Solutions API (GET /api/v2/solutions/categories, GET /api/v2/solutions/folders/{folder_id}/articles, GET /api/v2/solutions/articles/{id}). Map Freshdesk Categories to Salesforce Data Category Groups (default limit: 3 active groups), Folders to Data Categories (default limit: 100 per group, 5 hierarchy levels deep), and Articles to Knowledge Articles (Knowledge__kav). Request a limit increase from Salesforce support if your Freshdesk knowledge base exceeds these defaults.

Load content using the Salesforce Knowledge REST API to create draft articles (POST /services/data/v62.0/sobjects/Knowledge__kav), then publish them (PATCH with PublishStatus = 'Online'). Freshdesk articles use HTML, while Salesforce Knowledge uses rich text fields that support a subset of HTML. Complex CSS, embedded scripts, <style> blocks, and iframes will be stripped. Download embedded images from the Freshdesk CDN and re-upload them as Salesforce Files or to an external host, updating the <img> URLs in the article bodies — after migration, Freshdesk-hosted image URLs will break when the Freshdesk subscription is cancelled.

How Long Does a Freshdesk to Salesforce Service Cloud Migration Take?

[For PMs] This migration has three overlapping phases:

• Phase 1 — Salesforce Org Design & Configuration: 3–8 weeks. Define custom fields, record types, page layouts, profiles, queues, Omni-Channel, Entitlements, Flows, Email-to-Case, Lightning Console. Build everything in a sandbox first. This phase does not exist in simpler helpdesk migrations and is the primary driver of the 3–10x timeline multiplier.
• Phase 2 — Data Migration: 2–4 weeks. Freshdesk extraction, transformation, sandbox test load, production load (Accounts → Contacts → Cases → Comments → Attachments → KB Articles), validation.
• Phase 3 — Testing, Training & Go-Live: 2–4 weeks. Agent UAT in Lightning Service Console, training, channel cutover, 2–3 weeks hypercare.

Typical timeline for a 30-agent, 200K-ticket migration: 10–12 weeks. Complex enterprise orgs with multiple Record Types, Entitlements, and Omni-Channel routing: 14–16 weeks.

Agent Training Plan

Salesforce Lightning Service Console is architecturally different from Freshdesk. Plan a minimum of two half-day training sessions:

Session 1 — Core Workflow (3 hours):

• Lightning Console navigation (split view, subtabs, utility bar)
• Case lifecycle: creation, assignment, escalation, closure
• Working with the Case Feed (publisher actions, email, log a call)
• Quick Text and Macros (replacing Freshdesk canned responses and scenarios)
• Finding historical Cases and Contact records

Session 2 — Advanced Features (3 hours):

• Omni-Channel presence: setting status, accepting routed work, capacity management
• Knowledge article search and attachment to Cases
• Entitlement and Milestone Tracker interpretation
• Creating and managing reports and list views
• Common troubleshooting (locked records, validation rule errors)

Record both sessions. Create a Salesforce-specific runbook documenting the top 20 agent workflows mapped from their Freshdesk equivalents.

Key risks and mitigations:

What Happens to Customers During Migration?

[For customer success] End-users experience minimal disruption if email channels are cut over correctly at go-live. Chat customers will see a new Salesforce Embedded Service widget replace the Freshchat widget — coordinate widget swap with the frontend team to minimize the gap.

If full conversation history is imported via EmailMessage, agents retain deep historical context. If customers reply to old email threads, Salesforce Email-to-Case will create a new Case rather than reopening the migrated Case, unless the email threading exactly matches a Case's Thread-Id header (ref:_XXXXX._XXXXX:ref format). Test this behavior extensively in the sandbox with real email threads from Freshdesk.

Freshdesk SLA policies do not transfer. Historical SLA compliance data stays in Freshdesk. Salesforce Entitlements will track SLAs moving forward only. If historical SLA metrics are needed for reporting, export them from Freshdesk and store in a custom object or external data warehouse.

Edge Cases and Known Challenges

The painful failures usually come from details that looked minor during discovery. Test these early, not during cutover week.

• CaseComment timestamp loss. By default, CaseComment.CreatedDate cannot be set via standard API — all migrated comments show the migration date. Salesforce's Create Audit Fields feature can override this on insert (available in Enterprise, Unlimited, and Performance editions) (help.salesforce.com), but it must be enabled per org and does not work with upsert — only insert. If unavailable, use EmailMessage where MessageDate is settable without any special feature enablement.
• Account-Contact hierarchy enforcement. Freshdesk contacts without a company association fail Salesforce Contact insert. Options: create a default "Individual" Account, or pre-process contacts by email domain matching against existing Accounts during transformation.
• Rich HTML stripping. CaseComment.CommentBody is plain text only. Inline images, links, tables, and text formatting from Freshdesk replies will be stripped. Use EmailMessage.HtmlBody to preserve formatting.
• Picklist value mismatches. Salesforce rejects records with picklist values not defined in metadata. Every Freshdesk dropdown value must exist as a Salesforce picklist value before data load. Missing values cause silent batch failures (records appear in failedResults but the job itself may show as "Completed").
• Attachment storage limits. Check current Salesforce storage allocation via Setup → Storage Usage. A Freshdesk instance with 50 GB of attachments against a Salesforce org with 70 GB allocated may appear safe until you account for existing Salesforce data consumption.
• Duplicate contacts. Freshdesk may have duplicate contacts (same email, different records). Salesforce Duplicate Management rules can block inserts. Dedup in the transformation layer or temporarily set Duplicate Rules to "Allow" with an alert during migration, then re-enable blocking rules post-cutover.
• Closed status mapping. Closed values need Support Process alignment and the IsClosed flag in the Status picklist metadata. Without this configuration, agents will not see the expected status lifecycle in the Lightning Console — even if the data loaded successfully.
• Email threading on old threads. Once you switch from Freshdesk to Salesforce, customer replies only attach to the correct Case if Salesforce can match the inbound message using its Thread-Id header format. Otherwise a new Case is created. There is no way to retroactively inject Freshdesk email thread IDs into Salesforce's threading mechanism.
• Freshdesk Mint vs. Classic. If your Freshdesk instance is still on Classic (pre-2019), some API endpoints and export formats may differ. Verify API responses against current documentation before building extraction scripts.
• Telephony is a separate project. Freshcaller configuration does not transfer. Salesforce documents Open CTI as maintenance-mode with retirement scheduled for February 28, 2028; Service Cloud Voice with Amazon Connect is the native direction (help.salesforce.com).
• Customer portal is a separate project. The Freshdesk portal does not migrate. The Salesforce equivalent is Experience Cloud — a distinct build with separate licensing (Customer Community or Customer Community Plus) and configuration that typically adds 4–8 weeks to the project.
• Omni-Channel requires upfront configuration. Freshdesk assigns tickets via Dispatch'r or round-robin. Salesforce Omni-Channel provides real-time, capacity-based routing but requires Service Channels, Presence Statuses, Routing Configurations, and Presence Status assignments to Profiles before agents can receive work.

What Can't Be Migrated from Freshdesk to Salesforce?

• Automation rules (Dispatch'r, Supervisor, Observer) — must be redesigned as Flows, Assignment Rules, and Entitlement Processes. Different paradigm entirely.
• Analytics dashboards — must be rebuilt in Salesforce Reports & Dashboards. No migration path exists.
• Freddy AI configuration — must be rebuilt using Einstein Case Classification, Case Routing, and Agentforce.
• Marketplace app configurations — reconfigured via AppExchange equivalents (identify replacements during discovery).
• CSAT survey configuration — rebuilt using Salesforce Surveys or AppExchange tools (e.g., SurveyMonkey, GetFeedback). Historical CSAT scores can be preserved as custom Case field values.
• CaseComment original timestamps — cannot be set via standard API unless Create Audit Fields is enabled on the org (Enterprise+ editions only).
• Freshdesk's configuration simplicity — there is no equivalent to Freshdesk's "configure in 30 minutes" experience. Salesforce requires dedicated administration and platform-specific expertise. Plan for ongoing admin overhead of 0.25–0.5 FTE for a 30-agent deployment.

For context on why DIY scripts often fail when hitting these constraints, see Why DIY AI Migration Scripts Fail.

Validation and Testing After Migration

Post-migration validation ensures agents can trust the data on day one.

• Record-count reconciliation. Compare Freshdesk export counts against Salesforce SOQL COUNT() queries for Cases, Contacts, Accounts, CaseComments/EmailMessages, ContentVersions, and Knowledge Articles. Accept ≤0.1% variance; investigate any variance above that.
• Referential integrity verification. Run Salesforce reports or SOQL queries to identify orphaned records: SELECT Id FROM Case WHERE ContactId = null, SELECT Id FROM CaseComment WHERE ParentId NOT IN (SELECT Id FROM Case).
• Conversation fidelity verification. Sample 50+ Cases across different channels (email, portal, phone, chat) and date ranges. Verify that HTML is preserved (if using EmailMessage), author attribution is correct, and timestamps match Freshdesk source data within 1 second.
• Flow validation. Create 200+ Cases in a single batch to confirm that Record-Triggered Flows execute successfully without hitting governor limits. Check debug logs for any flow errors.
• Closed-status behavior. Verify that migrated closed Cases display correctly in the Lightning Service Console with the expected Support Process lifecycle. Open a closed Case to confirm the status picklist shows the correct available transitions.
• Email-to-Case threading. Send test replies to migrated Cases from external email accounts to verify threading behavior. Test with both recent and old migrated Cases.
• Omni-Channel routing. Create test Cases assigned to Queues and verify they route to available agents based on presence status and capacity configuration.
• UAT with agents. Have 3–5 agents work in the Lightning Service Console for 2–3 days handling real or simulated cases. Collect feedback on macro functionality, Omni-Channel routing, Quick Text, Knowledge search, and layout usability.

For a complete testing framework, review our Help Desk Data Migration QA Checklist.

Should You Migrate In-House or Use a Service?

In-house makes sense when: the team has existing Salesforce admins and developers (at least 1 admin + 1 developer), the Freshdesk instance is small (<10K tickets), conversation fidelity requirements are low (CaseComment is acceptable), and the Salesforce org is already configured for another team.

Engage a Salesforce SI when: the team has no Salesforce expertise, the migration is part of a broader Salesforce rollout (Sales Cloud + Service Cloud), or Entitlement/Omni-Channel design is complex. Typical SI engagement cost: $30,000–$150,000 for a mid-market Service Cloud implementation.

Engage a dedicated data migration service when: ticket volume exceeds 50K, conversation history fidelity is non-negotiable (EmailMessage path with HTML, timestamps, and author attribution), or the SI does not specialize in historical data transfer.

The lowest-risk model is often a split: let an SI or internal Salesforce team own org design and configuration, and let a migration specialist own extraction, transformation, loading, and validation.

ClonePartner has completed 1,500+ data migrations with SOC 2 Type II and ISO 27001 certification. For Freshdesk-to-Salesforce Service Cloud migrations, we handle the conversation fidelity challenge (Freshdesk replies/notes → EmailMessages with correct HtmlBody, MessageDate, and author attribution), Account-Contact hierarchy orchestration, external ID strategy for idempotent loading, and the full Accounts → Contacts → Cases → Comments → Attachments load sequence. For deciding what historical data actually needs to move, see the Help Desk Data Migration Playbook.