Migrate from Freshservice to Zoho Desk

Freshservice Tickets map directly to Zoho Desk Tickets. We preserve the full conversation thread (agent replies, requester replies, public notes, private notes) using Zoho Desk's thread model, maintaining authorship attribution by resolving Freshservice agent email to Zoho Desk agent and Freshservice requester email to Zoho Desk contact. Custom fields on Freshservice tickets migrate to Zoho Desk custom fields on the Ticket module. Status, priority, type, and SLA timer fields map to their Zoho Desk equivalents. The Freshservice Display ID is stored as a custom field z_original_id__c for cross-reference.

Freshservice Agents map to Zoho Desk Agents. Resolution is by email address. We preserve agent role (Full Access, Agent, Config Admin) as Zoho Desk role assignments. Group membership in Freshservice maps to Department membership in Zoho Desk; we create Zoho Desk Departments that mirror Freshservice Groups before agent import so that department assignment is satisfied at the time of agent insert. If the destination Zoho Desk account has agents pre-provisioned, we match by email and update rather than duplicate.

Freshservice Requesters map to Zoho Desk Contacts. Requester organizations in Freshservice map to Zoho Desk Accounts (the CRM-level entity), preserving the organizational hierarchy where Freshservice uses multi-level requester organization. Contact fields (name, email, phone, mobile) migrate directly; custom fields on requesters migrate as Zoho Desk Contact custom fields.

Freshservice CI (Configuration Item) assets map to Zoho Desk Assets. We preserve CI type, serial number, IP address, assigned user, and the linked Asset Location. The Freshservice asset relationship to Tickets (which CI was affected by which ticket) is preserved as a Zoho Desk custom field asset_id__c on the ticket for reference. Note that Zoho Desk Assets are simpler than Freshservice's CMDB: we do not migrate Freshservice's full CMDB dependency graph (which CI relates to which CI) because Zoho Desk does not have a native CI relationship model.

Freshservice Changes have no native equivalent in Zoho Desk. We map Changes to Zoho Desk Tasks with a custom field change_type__c (Normal, Standard, Emergency), risk_assessment__c, approval_status__c, and CAB_date__c. If the customer requires a richer change record, we document the full Change schema for Zoho Creator to build a custom Change module post-migration. Change-to-Ticket linkage (which ticket was caused by which change) is stored as change_id__c on the related Tickets. Approval workflow configuration does not migrate; we document the approval chain as a written step in the Change rebuild guide.

Freshservice Problems track root cause behind one or more incidents. Zoho Desk has no native Problem object. We map Problems to Zoho Desk Tickets with a custom field problem_id__c and a tag problem_record. The Problem-to-Incident linkage is preserved as a custom field linked_incidents__c storing a comma-separated list of related ticket IDs. We tag these tickets with a Problem tag so that the customer's admin can create a Zoho Desk Saved Filter to surface all problem-root-cause tickets in a single view. The Problem description and root cause analysis text migrate as the ticket description.

Freshservice Releases group Changes and Assets into a deployable unit with a scheduled release date and approval workflow. Zoho Desk has no native Release object. We map Releases to Zoho Desk Tasks with release_date__c, release_status__c, and associated_change_ids__c fields. The release approval chain is documented in the rebuild guide for the customer's admin to re-implement in Zoho Desk's Blueprint or Zoho Creator.

Freshservice Solutions (knowledge base articles) map to Zoho Desk Articles. Article title, description, status, and category map directly. Freshservice article-to-ticket associations (which articles were linked to which tickets) are preserved as tags on the migrated Zoho Desk articles. Permissions (public, internal) map to Zoho Desk article visibility settings. We map the Freshservice category hierarchy to Zoho Desk section and category structure before article import so that the parent relationship is satisfied.

Freshservice SLA Policies (response and resolution time targets by priority or ticket type) do not migrate as reusable policy objects. We create Zoho Desk SLA configurations that mirror the Freshservice SLA targets, mapped by priority level. Response and resolution first-response SLA targets become Zoho Desk SLA Policy entries attached to the relevant Departments. We deliver a written SLA mapping table listing every Freshservice SLA Policy, its triggers, its time targets, and the corresponding Zoho Desk SLA configuration the admin must create post-migration.

Freshservice Service Catalog items with multi-step request forms and approval chains have no direct equivalent in Zoho Desk's standard modules. We map catalog item titles and descriptions to Zoho Desk Tasks as intake records, but the form logic, conditional fields, and approval routing require Zoho Creator or Blueprint to rebuild. We deliver a written catalog inventory with each item's fields, form logic, and approval chain documented for the customer's Zoho admin or a Zoho Creator partner to rebuild post-migration.

Freshservice Locations map to Zoho Desk Locations as reference data. We import Locations before Assets and Agents so that the location assignment is available as a dropdown on the Asset and Agent forms during migration. Location hierarchy in Freshservice (parent-child locations) maps to Zoho Desk Location hierarchy.

Freshservice Departments map to Zoho Desk Departments. We resolve the department hierarchy and map department-level settings (business hours, holiday list, department-specific SLA) from Freshservice to Zoho Desk Department configurations. This is a prerequisite step that runs before agent and ticket migration so that department assignment is valid on all incoming records.

Freshservice Custom Objects (Forest and Enterprise only) have no native equivalent in Zoho Desk. We extract Custom Object records and distribute their fields to the most relevant Zoho Desk standard module as custom fields. For example, a Freshservice Custom Object tracking hardware warranty information would become warranty_expiry__c and warranty_type__c custom fields on the Zoho Desk Asset module. We document every Custom Object, its fields, and its mapped Zoho Desk destination in the migration schema report. The limitation that Freshservice Custom Objects cannot reference native objects means we store the related Freshservice record ID as a text field in Zoho Desk rather than a native lookup relationship.