Helpdesk migration
Field-level mapping, validation, and rollback between Dynamics 365 Customer Service and Freshdesk. We move data and schema; workflows are rebuilt natively in Freshdesk.
Dynamics 365 Customer Service
Source
Freshdesk
Destination
Compatibility
6 of 10
objects map 1:1 between Dynamics 365 Customer Service and Freshdesk.
Complexity
BStandard
Timeline
3-5 weeks
Overview
Migrating from Dynamics 365 Customer Service to Freshdesk reduces per-seat licensing from a $50-$195/month Microsoft stack to Freshdesk's $0-$79/month model and eliminates the Power Platform overhead that drives implementation costs. The migration is a data move, not a platform lift: Cases become Tickets, Accounts and Contacts migrate as Companies and Contacts, Knowledge Articles transfer with their category taxonomy, and Activities attach to their parent Ticket conversation thread. We read from the Dataverse OData v4 API with 5,000-record pagination pages, throttle against Microsoft's Service Protection limits, and write into Freshdesk through its REST API with field-type mapping. Power Automate flows, routing rules, entitlements, and SLA KPI definitions do not migrate as code; we inventory every active flow and SLA configuration and deliver a written handoff so your team can rebuild them in Freshdesk's automation engine post-migration.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Dynamics 365 Customer Service object lands in Freshdesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Dynamics 365 Customer Service
Case (Incident)
Freshdesk
Ticket
1:1Cases from the incident table in Dataverse map to Freshdesk Tickets. title becomes subject, incidentid becomes external_id for reconciliation, statecode and statuscode map to Freshdesk status values (Open, Pending, Resolved, Closed) via a status crosswalk, and priority maps directly. The regardingobjectid Contact reference resolves to a Freshdesk requester lookup. Resolution fields (resolvebyslaset, resolvedon) migrate as custom ticket fields since Freshdesk tracks SLA status separately in the SLA policy engine.
Dynamics 365 Customer Service
Contact
Freshdesk
Contact (Requester)
1:1Dataverse Contact records map to Freshdesk Contact objects. email address is the dedupe key for upsert. We migrate full name, email, phone, job title, address, and language preference. The original incidentid linkage is preserved by cross-referencing the Case mapping so that Ticket creation references an already-created Contact. Active and inactive status migrates with a custom active flag so that reassignment to an active agent can happen in Freshdesk if the original Contact is a former employee.
Dynamics 365 Customer Service
Account
Freshdesk
Company
1:1Dataverse Account records map to Freshdesk Company objects. accountid becomes external_id, name becomes company_name, and address fields map to Freshdesk address fields. Account-Contact relationships preserve via Freshdesk's company_id field on Contact so agents see the full account context inside a Ticket. Parent Account hierarchies flatten to top-level companies with child accounts noted in a custom field since Freshdesk's Company model is flat.
Dynamics 365 Customer Service
Knowledge Articles
Freshdesk
Articles
1:1Knowledge Articles stored in Dataverse (article table with title, body, language, status, and category linkage) map to Freshdesk Articles. Article body migrates as HTML content. The Dataverse article category taxonomy maps to Freshdesk's folder structure and tags. Published articles migrate to Freshdesk Published status; draft articles migrate as Draft. Version history is collapsed to the latest published version for the initial migration unless the customer requests version preservation. The Freshdesk Article portal URL is stored back on the Dataverse article record as a reference field for post-migration admin linking.
Dynamics 365 Customer Service
Queue
Freshdesk
Group
1:1Dataverse Queue records map to Freshdesk Groups. queueid becomes external_id, and the queuename maps to group_name. Unified Routing decision tables and skill-based assignment rules that govern how Cases enter queues are documented as a routing logic inventory rather than migrated as code, because Freshdesk's routing model (product-based, group-based, or round-robin) is configured within the platform. Queue members migrate as Group members by matching Dataverse systemuser email to Freshdesk agent email.
Dynamics 365 Customer Service
Activities (Email, Phone Call, Task, Appointment)
Freshdesk
Ticket Conversations
1:manyDataverse Activities linked to a Case via regardingobjectid — Email, Phone Call, Task, and Appointment records — merge into Freshdesk Ticket conversations. Each Activity type maps to a conversation note with a type indicator (Incoming Email, Outgoing Email, Phone Call, Note, Meeting). activityid is preserved as external_id on the conversation record. The Activity's actualtime or scheduledstart and scheduledend timestamps preserve the original timeline ordering. Because Freshdesk represents conversations as a flat list per Ticket, we collapse multiple Activity types into a unified chronological thread rather than preserving the Activity type as a separate object.
Dynamics 365 Customer Service
Entitlements and Entitlement Templates
Freshdesk
Custom Ticket Fields
lossyEntitlements represent support contract terms with allocated hours, case count limits, and channel restrictions. Freshdesk does not have a native Entitlement object, so we migrate entitlement terms as custom fields on the Ticket: contract_type, allocated_hours_remaining, and channel_restriction flags. The customer's admin creates these custom fields in Freshdesk before migration. A written entitlement inventory report is delivered separately for the admin to configure as SLA policy conditions in Freshdesk if the team uses contract-based SLA policies.
Dynamics 365 Customer Service
SLA Definitions and SLA Instances
Freshdesk
SLA Policies
lossyDataverse SLA definitions (first response time, resolution time, business hours, pause conditions, warning thresholds) map to Freshdesk SLA Policies at the group and ticket priority level. We export the SLA definition and active SLA instances on open Cases; the target mapping depends on whether Freshdesk's SLA Policy engine (available on Pro and Enterprise plans) covers the same pause and business-hour logic. Many customers find that Freshdesk's SLA Policy model requires reconfiguration of business hours calendars and pause conditions, so we deliver a written SLA inventory rather than automating the rebuild inside Freshdesk.
Dynamics 365 Customer Service
Custom Dataverse Tables and Columns
Freshdesk
Custom Objects or Custom Ticket Fields
lossyCustom tables extended on the incident, contact, or account Dataverse tables migrate as Freshdesk Custom Objects (Forest/Enterprise plan) or as custom ticket fields on the Ticket object. We inventory the full source schema, classify each custom column by type (string, integer, datetime, option-set, lookup), and pre-create the destination field before migration. Option-set values in Dataverse map to Freshdesk dropdown fields. Lookup relationships that reference other Dataverse tables are mapped as custom fields in Freshdesk with a text representation of the referenced record name; the migration user resolves the target object before import.
Dynamics 365 Customer Service
Omnichannel Conversations
Freshdesk
Ticket Conversations
1:1Omnichannel chat, voice, SMS, and social session transcripts from the msdyn_ocliveworkitem and msdyn_ocsession tables in Dataverse migrate as conversation entries on the linked Ticket. The session transcript text and metadata (channel type, agent, start time, end time) append to the Freshdesk Ticket conversation thread. Channel-specific assets — voice recordings, chat file attachments, social media media URLs — are flagged in a separate report because Freshdesk supports file attachments but channel-specific media URLs require manual re-linking or re-upload to the destination's storage.
| Dynamics 365 Customer Service | Freshdesk | Compatibility | |
|---|---|---|---|
| Case (Incident) | Ticket1:1 | Fully supported | |
| Contact | Contact (Requester)1:1 | Fully supported | |
| Account | Company1:1 | Fully supported | |
| Knowledge Articles | Articles1:1 | Fully supported | |
| Queue | Group1:1 | Fully supported | |
| Activities (Email, Phone Call, Task, Appointment) | Ticket Conversations1:many | Fully supported | |
| Entitlements and Entitlement Templates | Custom Ticket Fieldslossy | Mapping required | |
| SLA Definitions and SLA Instances | SLA Policieslossy | Mapping required | |
| Custom Dataverse Tables and Columns | Custom Objects or Custom Ticket Fieldslossy | Fully supported | |
| Omnichannel Conversations | Ticket Conversations1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Dynamics 365 Customer Service gotchas
Service Protection API limits will throttle bulk migration loads
OData v4 paging caps reads at 5,000 records per page
Power Automate flows do not migrate as data
Licensing tier gates which capabilities migrate cleanly
Omnichannel conversation history is fragmented across channels
Freshdesk gotchas
API access is blocked on the free plan
Per-minute rate limits are account-wide and endpoint-specific
Multi-channel source types do not map 1:1 to all destinations
Custom objects created in-product cannot be accessed by other apps
Contact import requires at least 10 existing tickets in the account
Pair-specific challenges
Migration approach
Discovery and source audit
We audit the Dynamics 365 Customer Service organisation: Dataverse tier (Professional, Enterprise, or Premium), active incident table schema including any custom columns, Knowledge Article library size and taxonomy depth, active Queue definitions, Entitlement and SLA configurations, Power Automate cloud flow inventory, and Omnichannel session volume. We also identify the Dataverse application user credentials and confirm that the Service Protection API will permit a bulk extraction run. The discovery output is a written migration scope, a custom field inventory, and an SLA and automation handoff template.
Freshdesk destination setup
We create the Freshdesk destination schema before any data moves. This includes provisioning custom fields on the Ticket object (status crosswalk fields, SLA reminder fields, entitlement contract fields), creating Custom Objects (Forest/Enterprise plan) to mirror any Dataverse custom tables, setting up the Knowledge Article folder taxonomy, configuring Groups from the Dataverse Queue definitions, and defining SLA Policies based on the documented SLA inventory. We work from a Freshdesk sandbox or trial environment first for validation, then replicate the configuration in the production account. Freshdesk admin credentials and an API key are required at this stage.
Sandbox migration and field mapping validation
We run a sandbox migration with production-like record volumes to validate field mapping, status crosswalk logic, parent record resolution (Account-Contact-Ticket chain), and Knowledge Article taxonomy mapping. The customer's helpdesk lead spot-checks 25-50 Tickets against the Dataverse source, confirms that conversation threads render in the correct chronological order, and reviews Knowledge Article content. Mapping corrections and any Freshdesk field creation that was missed in Step 2 are resolved before the production migration window opens.
Parent record migration (Accounts and Contacts first)
We migrate in strict dependency order. Accounts (from the account table) import first as Freshdesk Companies. Contacts (from the contact table) follow, with the resolved company_id linking each Contact to its Company. We use email as the dedupe key for upsert so that re-migration runs do not create duplicates. Any Contact without a resolved Company receives a default company association and a reconciliation flag. Owner resolution matches Dataverse systemuser email to Freshdesk agent email for group assignment.
Case migration with conversation threading
Cases (incidents) migrate as Tickets in dependency order after Accounts and Contacts are confirmed. The Case's Customer (Contact) lookup resolves to the migrated Freshdesk Contact ID. Activities attached to the Case via regardingobjectid — emails, phone calls, tasks, appointments — append to the Ticket conversation thread in chronological order. The Dataverse statuscode crosswalk maps each Case state to the equivalent Freshdesk status. External IDs from Dataverse incidentid and activityid are stored on the migrated records for reconciliation and re-run capability.
Knowledge Articles and custom object migration
Knowledge Articles migrate after Ticket migration completes, with the taxonomy mapping from Dataverse article categories to Freshdesk folder structure and tags. Custom Dataverse tables migrate as Freshdesk Custom Objects (or custom fields if the destination is on a plan below Forest). We resolve lookup references between custom tables by ordering the migrations so that parent objects import before their dependent child records. Each custom object import emits a row-count reconciliation report.
Cutover, validation, and automation handoff
We freeze Dataverse writes during the cutover window, run a final delta migration of any Cases modified during the migration run, then hand Freshdesk as the active system of record. We deliver the Power Automate flow inventory, SLA definition documentation, Entitlement inventory, and Omnichannel attachment report to the customer's admin team with Freshdesk Scenario rule and SLA Policy configuration guidance. We support a five-business-day hypercare window for reconciliation issues raised by the support team. Rebuilding Power Automate flows, routing rules, and SLA monitoring inside Freshdesk is outside the migration scope.
Platform deep dives
Dynamics 365 Customer Service
Source
Strengths
Weaknesses
Freshdesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. All 7 core objects map 1:1 between Dynamics 365 Customer Service and Freshdesk.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Dynamics 365 Customer Service and Freshdesk.
Object compatibility
All 7 core objects map 1:1 between Dynamics 365 Customer Service and Freshdesk.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Dynamics 365 Customer Service: Service Protection API limits — roughly 6,000 requests per user per rolling 5-minute window per web server; 429 responses include Retry-After header.
Data volume sensitivity
Dynamics 365 Customer Service exposes a bulk API — large-volume migrations stream efficiently.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Dynamics 365 Customer Service to Freshdesk migration scoping. Not seeing yours? Book a call.
Walk through your Dynamics 365 Customer Service to Freshdesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Dynamics 365 Customer Service
Other ways to arrive at Freshdesk
Same-Helpdesk migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.