Helpdesk migration
Field-level mapping, validation, and rollback between OneDesk and Freshdesk. We move data and schema; workflows are rebuilt natively in Freshdesk.
OneDesk
Source
Freshdesk
Destination
Compatibility
7 of 9
objects map 1:1 between OneDesk and Freshdesk.
Complexity
CModerate
Timeline
2-4 weeks
Overview
Moving from OneDesk to Freshdesk is a cross-schema migration that requires resolving OneDesk's shared custom field architecture against Freshdesk's per-object custom field system. OneDesk's dual-mode Item model (Tickets and Tasks sharing one schema) splits across Freshdesk's Tickets and a separate Projects-to-Groups mapping. We sequence the migration by first extracting the complete active custom field definition set, then mapping Tickets and their conversation threads to Freshdesk Tickets with the requester as Contact, assigning Users to Freshdesk Agents, and linking Projects to Freshdesk Groups. Time entries, KB Articles, and attachments migrate with their relationships intact. OneDesk workflow automations and SLA configurations reference record IDs that change after migration; we export these as a written inventory and do not attempt automated rewrite. Freshdesk's Sprout tier (free) does not support API access, so API-based migration requires Blossom or above on the destination.
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 OneDesk 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.
OneDesk
Ticket
Freshdesk
Ticket
1:1OneDesk Tickets map to Freshdesk Tickets with subject, description, status, priority, assignee (agent), and requester preserved. The OneDesk requester (Customer record) maps to Freshdesk Contact by email match. Conversation messages on the Ticket migrate as Conversation records in chronological order. OneDesk Item custom fields (shared across all types) map to Freshdesk Ticket custom fields, which must be pre-created on Freshdesk before migration because Freshdesk uses per-object field definitions rather than OneDesk's shared field set.
OneDesk
Task
Freshdesk
Ticket or Project Task
1:manyOneDesk Tasks share the same Item schema as Tickets with a type discriminator. We migrate Tasks as Freshdesk Tickets with a custom field task_type__c set to 'internal' so they are distinguishable from customer-facing tickets. If the customer uses Projects for internal work management, we map Tasks to Freshdesk Projects with the task data preserved in the project description or a custom field for admin visibility. The customer chooses the internal-work strategy during scoping.
OneDesk
Customer
Freshdesk
Contact
1:1OneDesk Customers (external contacts) map directly to Freshdesk Contacts by email match. Name, email, phone, company, and language migrate as standard fields. Custom properties on Customer records require field-level mapping because OneDesk's shared custom field model means these properties appear on both Tickets and Customers. We extract the full active custom field schema during scoping to identify which fields are Contact-level versus Ticket-level in Freshdesk.
OneDesk
User
Freshdesk
Agent
1:1OneDesk Users (billable agents) map to Freshdesk Agents. We resolve by email match and map the OneDesk role (Admin, Agent) to Freshdesk Agent role. Groups from OneDesk Projects map to Freshdesk Groups; agent group memberships migrate as Freshdesk Group memberships. Any OneDesk User without a matching Freshdesk Agent must be provisioned by the customer's admin before record import because Freshdesk requires an Agent to exist before a Ticket can be assigned to them.
OneDesk
Project
Freshdesk
Group
1:1OneDesk Projects serve as container objects that group related Tickets and Tasks with assigned members. We map Projects to Freshdesk Groups, preserving the project name as the group name and project members as group members. Child Items linked to the Project are resolved to Freshdesk Tickets during migration with a group_id reference. OneDesk's unlimited-project model maps cleanly to Freshdesk's unlimited-groups model without tier constraints.
OneDesk
Knowledge Base Article
Freshdesk
Knowledge Base Article
1:1OneDesk KB Articles with title, body content, category assignments, and publish status migrate to Freshdesk Knowledge Base articles. We map article-to-category relationships to Freshdesk's category and folder structure. Pair-specific gotcha: Freshdesk migrations without guarded category mapping have been documented to duplicate articles 4x in the destination. We validate unique article IDs during import to prevent duplication.
OneDesk
Conversation
Freshdesk
Conversation
1:1OneDesk conversation messages on Tickets include author, timestamp, message body, and an internal/external flag. We preserve the full thread in chronological order, map author references to migrated Agent records by email, and set the public/private visibility in Freshdesk based on the original internal/external flag. Reply order is preserved by setting the Freshdesk conversation created_at timestamp to the original OneDesk timestamp.
OneDesk
Custom Field
Freshdesk
Custom Field
lossyOneDesk custom fields are shared across all ticket types (Ticket and Task share one schema). We extract the complete active custom field definition during scoping, including field type, required flag, and picklist values. These map to Freshdesk Ticket custom fields and Contact custom fields depending on which objects carry the field in OneDesk. Freshdesk requires pre-creation of custom fields before import; we deliver the field creation checklist as part of the migration package so the customer's Freshdesk admin provisions fields before data import begins.
OneDesk
Attachment
Freshdesk
Attachment
1:1File attachments on Tickets and Tasks are downloaded from OneDesk storage, mapped to the corresponding Ticket in Freshdesk, and uploaded preserving original filenames. Large attachment sets are chunked to stay within API rate limits. We flag any attachment exceeding Freshdesk's 25 MB per-file limit for the customer's admin to handle as a link reference rather than an inline upload.
| OneDesk | Freshdesk | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Task | Ticket or Project Task1:many | Fully supported | |
| Customer | Contact1:1 | Fully supported | |
| User | Agent1:1 | Fully supported | |
| Project | Group1:1 | Fully supported | |
| Knowledge Base Article | Knowledge Base Article1:1 | Fully supported | |
| Conversation | Conversation1:1 | Fully supported | |
| Custom Field | Custom Fieldlossy | Fully supported | |
| Attachment | Attachment1: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.
OneDesk gotchas
User vs Customer billing model is migration-critical
Custom fields shared across all ticket types require schema discovery
Workflow automations reference migrated record IDs
Export via data view CSV may hit pagination limits on large datasets
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 schema extraction
We audit the source OneDesk tenant for record counts across Tickets, Tasks, Projects, Customers, Users, KB Articles, and Attachments. We extract the complete active custom field definition set (field name, type, required flag, picklist values) to identify which fields apply to Customers versus Items. We inventory active workflow automations and SLA policies, flagging any that contain record ID references. We confirm the destination Freshdesk plan (must be Blossom or above for API access) and the current User-to-Agent mapping. The discovery output is a written migration scope with record counts, a custom field pre-creation checklist, and the automation handoff inventory.
Destination setup and custom field pre-creation
The customer's Freshdesk admin creates the custom fields identified in discovery on the Ticket and Contact objects before any data import begins. We provide the exact field names, types, and picklist values. Groups corresponding to OneDesk Projects are created in Freshdesk, and agents are provisioned with matching roles. This step is the customer's responsibility; migration cannot insert records with custom field values referencing fields that do not yet exist in Freshdesk.
Record export and transformation
We export OneDesk records in dependency order: Users first (for agent resolution), then Customers (for contact resolution), then Projects (for group creation), then Tickets and Tasks (with Item IDs preserved for relationship mapping), then Conversations (linked to parent Tickets), then KB Articles (with category assignments), then Attachments (downloaded and staged for re-upload). Custom field values are extracted from the shared OneDesk Item schema and routed to the correct Freshdesk Ticket or Contact custom field based on the field's applied scope. We run a transformation pass to apply the Lifecycle Stage mapping (if applicable), status normalization, and priority mapping before any data is loaded.
Destination import with relationship resolution
We load records into Freshdesk using the REST API with batch chunking and exponential backoff on rate limit responses. Customers load first (to resolve contact IDs), then Agents are matched by email, then Groups are created from Projects, then Tickets are imported with requester_id resolved to the migrated Contact, assignee_id resolved to the matched Agent, and group_id resolved to the mapped Group. Conversation records are imported linked to their parent Ticket with author_id resolved to the matched Agent. KB Articles are imported with category assignments validated against the Freshdesk category tree to prevent duplication. Each phase emits a row-count reconciliation report.
Attachment migration and KB validation
We download file attachments from OneDesk storage in batches, preserving original filenames and upload them to the corresponding Freshdesk Ticket using the Attachments API. We validate article counts after the KB migration phase: if the Freshdesk article count exceeds the source article count by more than 5 percent, we investigate category mapping before proceeding. We do not re-run KB migration without clearing the existing imported articles first to prevent duplication.
Cutover, validation, and automation handoff
We freeze OneDesk writes during cutover, run a delta migration of any records modified during the migration window, then enable Freshdesk as the system of record. We deliver the automation and SLA inventory document to the customer's admin team with every automation's trigger, conditions, actions, and recommended Freshdesk Scenario Automation equivalent. We support a one-week hypercare window for reconciliation issues. Workflow automations, SLA policies, and reporting configurations are not rebuilt as part of the migration scope; they are documented for the customer's admin to configure post-migration.
Platform deep dives
OneDesk
Source
Strengths
Weaknesses
Freshdesk
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 3 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across OneDesk and Freshdesk.
Object compatibility
3 of 7 objects need a mapping; the rest are 1:1.
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
OneDesk: Not publicly documented.
Data volume sensitivity
OneDesk doesn't expose a bulk API — REST + parallelization used for high-volume runs.
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 OneDesk to Freshdesk migration scoping. Not seeing yours? Book a call.
Walk through your OneDesk 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 OneDesk
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.