Migrate from LiveAgent to Freshdesk

LiveAgent Tickets map directly to Freshdesk Tickets. We map LiveAgent's ticket status (open, pending, resolved, spam) to Freshdesk's status values (open, pending, resolved, closed) and preserve LiveAgent's priority field (low, normal, high) as Freshdesk priority (low, medium, high, urgent). The original LiveAgent ticket ID is stored in a custom field fd_source_id__c for audit and cross-reference.

LiveAgent Customer records map to Freshdesk Contacts. We match on email as the primary deduplication key and map name, phone, address, and custom field values. LiveAgent's Customer custom fields are discovered during scoping via the /customers/custom-fields endpoint, typed (string, boolean, date, number), and pre-created as Freshdesk contact custom fields before import begins.

LiveAgent Companies map to Freshdesk Organizations. The mapping is 1:1 with company name as the dedupe key. Freshdesk's Organizations are linked to Contacts and Tickets via lookups that we resolve at import time. If the source account does not use Companies, we skip this object and Contacts remain unorganized in Freshdesk.

LiveAgent stores threaded messages as a separate Conversations object linked to Tickets. Freshdesk nests conversations as a sub-object of the Ticket. We flatten each LiveAgent conversation thread into Freshdesk Ticket conversations at import time, preserving the message body, author type (agent or customer), timestamp, and attachment references. This is the most nuanced transform in the migration because Freshdesk's conversation API requires the parent ticket ID to be known before we can write conversations.

LiveAgent does not expose a standalone Agents API object; agent information is embedded in ticket assignments. We extract distinct agent names and emails from ticket assignment records and map them to Freshdesk Agent accounts by email match. The customer provisions Freshdesk agent accounts before migration; any LiveAgent agent without a matching Freshdesk agent account is held in a reconciliation queue.

Tags applied to LiveAgent Tickets migrate to Freshdesk Ticket tags using the same tag names. Freshdesk's tag API (POST /tickets/{id}/tags) accepts an array of tag names per ticket. We recreate tags in Freshdesk during scoping if they do not already exist.

LiveAgent Customer Groups (used for segmenting customers by tier or region) map to Freshdesk Groups. Group membership is preserved by writing the Freshdesk group ID back to the corresponding Contact records during import. Groups without a matching Freshdesk group are created in Freshdesk before the Contact migration phase.

LiveAgent Knowledgebase articles in categories map to Freshdesk Solution articles in categories. The category hierarchy is preserved as a Freshdesk folder structure. Article status (draft, published) maps to Freshdesk's visible and archived flags. ACL settings on LiveAgent articles require manual review because Freshdesk handles portal visibility differently through article permissions per category.

File attachments linked to LiveAgent Tickets and Conversations are downloaded via the /files endpoint, re-uploaded to Freshdesk, and attached to the corresponding Ticket conversation entry. Attachment file size limits on Freshdesk (capped at 15MB per file on most plans) are enforced during the re-upload step, and files exceeding the limit are flagged for the customer to handle manually or via an alternative storage approach.

Ticket custom fields in LiveAgent are account-specific schemas discovered via the /tickets/custom-fields endpoint. We enumerate all custom field names, types, and current values during scoping, create equivalent custom fields in Freshdesk via the /ticket_fields API (with type matching: string to text, boolean to checkbox, date to date picker, number to number), and map values at migration time. Any picklist or dropdown custom fields require manual value mapping if the option sets differ between platforms.