How to Migrate from LiveAgent to Freshdesk: The Complete Guide

Last verified: July 2025 against LiveAgent API v3 and Freshdesk API v2.

What Is a LiveAgent to Freshdesk Migration?

A LiveAgent to Freshdesk migration is the process of extracting tickets, messages, customers, companies, agents, departments, tags, custom fields, knowledge base articles, and attachments from LiveAgent and loading them into Freshdesk's ticket-centric data model while preserving full conversation history and relational integrity.

Teams typically move for three reasons:

1. Freshworks ecosystem breadth. Freshdesk connects to 1,000+ marketplace integrations and unifies with Freshchat, Freshcaller, and Freshsales. LiveAgent offers around 200 integrations with fewer native cross-product connections.
2. AI and automation maturity. Freshdesk's Freddy AI provides agent copilot, AI-powered triage, and customer-facing bots on Pro and Enterprise plans. LiveAgent's automation layer is rule-based with no native AI triage.
3. Structured ticket model. Freshdesk enforces strict parent-child relationships between Companies, Contacts, and Tickets. This rigid structure enables advanced reporting and granular access controls that scale better for enterprise teams.

The migration is non-trivial because LiveAgent and Freshdesk diverge in three structural ways. LiveAgent uses Departments for routing while Freshdesk uses Groups. LiveAgent stores messages as separate objects linked to tickets, while Freshdesk nests Conversations (replies and notes) directly under each ticket. And LiveAgent's knowledge base uses a flat Category-and-Article hierarchy, while Freshdesk's Solutions module uses a three-level Category > Folder > Article structure. You cannot push LiveAgent data straight into Freshdesk — you must reshape your entire historical dataset to fit the Freshdesk relational model.

How to Map LiveAgent Objects to Freshdesk

Map your data model before writing any code. Do not assume fields transfer directly. For a reusable worksheet and CSV templates, see our data mapping guide.

Status Mapping

A practical status map: LiveAgent New or Open maps to Freshdesk Open (2), Answered maps to Pending (3), Postponed maps to Pending (3) or a custom deferred status, Resolved maps to Resolved (4), and Closed maps to Closed (5). If you want to keep Answered and Postponed as distinct statuses, create custom Freshdesk statuses before loading data. (support.liveagent.com)

Field-Level Mapping Gotchas

• Picklist and enum handling. LiveAgent custom fields with dropdown values must be recreated with identical option labels in Freshdesk before import. Mismatched labels cause silent field-value drops — the API accepts the ticket but quietly discards the unrecognized value.
• Date and timezone formats. LiveAgent API v3 returns dates in the account's configured timezone. Freshdesk expects UTC. Apply timezone offset conversion during transformation. If your LiveAgent account timezone is not UTC, use Timezone-Offset during reconciliation because API results follow account timezone while filters operate in UTC. (support.liveagent.com)
• Required fields. Freshdesk ticket creation requires email or requester_id, subject, description, status, and priority. LiveAgent tickets missing any of these fields will fail on import.
• Custom field limits. Freshdesk limits the number of active custom fields based on your plan. If your LiveAgent instance has many custom fields, you may need to consolidate them or map legacy data into a single text block within the ticket description.
• Inactive picklist values. If a LiveAgent picklist has an obsolete or inactive value, the Freshdesk API will reject the ticket creation payload. Map obsolete values to a generic legacy field or recreate them in Freshdesk before import.

What Data Cannot Be Migrated from LiveAgent to Freshdesk?

LiveAgent's native CSV export does not include full ticket message history. The CSV export from the agent panel provides a preview of tickets (subject, status, owner) but drops the complete threaded conversation. This makes CSV export unsuitable for any migration that requires preserving agent replies, customer responses, and internal notes. (support.liveagent.com)

The following data types cannot be migrated programmatically and must be rebuilt:

• Automation Rules (LiveAgent "Rules")
• SLA Policies
• Canned Messages and Predefined Answers (exportable from LiveAgent via API v3, but must be manually recreated in Freshdesk)
• Agent Gamification data (badges, levels, rewards)
• Chat widget configurations
• Contact form designs
• Report configurations
• Department roles and queue rules (support.liveagent.com)

How to Handle API Rate Limits During Migration

Rate limits are the primary throughput constraint. Both platforms enforce per-minute caps that directly determine how long your migration runs.

LiveAgent API Rate Limits

LiveAgent restricts API requests to 180 per minute per API key for cloud-hosted accounts. On-premise LiveAgent installations may have different or configurable rate limits depending on your server configuration — the 180/min cap applies specifically to cloud-hosted (ladesk.com) accounts. This limit is counted separately for each API key. LiveAgent's GET /tickets endpoint returns a maximum of 1,000 rows per request. Use the _page parameter to paginate. Some endpoints use cursor-based pagination via _cursor instead. (support.liveagent.com)

Generating a LiveAgent API key: Navigate to Configuration > System > API in your LiveAgent admin panel. Create a new API key and assign it read permissions for tickets, contacts, companies, and knowledge base. For migration purposes, the key needs read access across all departments. Store the key securely — LiveAgent does not display it again after creation.

A critical constraint: LiveAgent caps each v3 ticket filter at 10,000 records. If your account has more than 10,000 tickets, you must split extraction into date windows (week or month ranges) to retrieve the full dataset. (support.liveagent.com)

To extract a single ticket with its full message history, you need a minimum of 2 API calls: one GET /tickets/{ticketId} for the ticket metadata and one GET /tickets/{ticketId}/messages for all messages. For 50,000 tickets, that is at least 100,000 API calls — roughly 556 minutes (about 9.3 hours) at maximum throughput.

Freshdesk API Rate Limits

Freshdesk enforces plan-based, per-minute rate limits applied at the account level regardless of the number of agents or API keys. Verify current pricing on the Freshdesk pricing page as rates may change:

Freshdesk returns X-RateLimit-Total, X-RateLimit-Remaining, and X-RateLimit-Used-CurrentRequest headers on every response. When the limit is exceeded, the API returns HTTP 429 with a Retry-After header. (support.freshdesk.com)

Throughput Math

On a Freshdesk Growth plan (200 calls/min, ~80 ticket creates/min), if each migrated ticket requires 1 create call plus 4 note calls, the account limit caps you at roughly 40 fully loaded tickets per minute — about 2,400 per hour before retries and attachments. A 50,000-ticket migration at this rate takes over 20 hours of API runtime.

On a Pro plan (400 calls/min, ~160 creates/min), effective throughput rises to roughly 2,000 to 3,200 fully loaded tickets per hour, bringing a 50,000-ticket migration down to 16 to 25 hours.

Pre-audit attachment totals before running the migration. LiveAgent documents up to 25 MB overall ticket attachments, while Freshdesk enforces a 20 MB total attachment ceiling per ticket. (support.liveagent.com)

Common Freshdesk API Error Codes During Migration

Migration Approaches Compared

When to choose what:

• Under 5,000 tickets, no custom fields: Third-party tool or simple API script
• 5,000 to 50,000 tickets: Custom API script with a dedicated engineer, or a managed service
• 50,000+ tickets, custom fields, attachments, KB: Managed migration service

Integration platforms like Zapier or Make are unsuited for historical data migrations. They process records one by one, charge per task, and lack the endpoint configurations required for Freshdesk's Ticket Import API — meaning migrated tickets would lose their historical timestamps. Even third-party tools that feel automated still ride on LiveAgent and Freshdesk APIs, so rate limits, attachment ceilings, and schema gaps set the real pace.

Multi-Brand and Multi-Portal Considerations

Freshdesk supports multi-product configurations where a single account serves multiple brands with separate portals, email addresses, and customer-facing views. If your target Freshdesk instance uses multi-product, you must decide during mapping which LiveAgent department maps to which Freshdesk product. Each product has its own set of groups, and tickets must reference the correct product_id in the API payload. Failing to account for multi-product routing results in all tickets landing in the default product, requiring manual reclassification.

Step-by-Step Migration Architecture

The order of operations matters. Creating tickets before contacts exist in Freshdesk will fail because requester_id must resolve to a valid contact. Follow this sequence:

Step 1: Audit the LiveAgent source

Inventory LiveAgent tickets by status, channel, department, month, and attachment size. Split extraction into date windows before you code the export because LiveAgent caps each v3 ticket filter at 10,000 records. (support.liveagent.com)

Step 2: Pre-create the Freshdesk schema

Create Freshdesk groups, custom ticket fields, custom statuses, companies, and Solutions folders before loading any records. Custom ticket and contact fields must be created manually in the Freshdesk admin UI — there is no API endpoint to programmatically create custom field definitions. Freshdesk validates against the destination schema, so missing fields and groups create avoidable rework. (support.freshdesk.com)

Step 3: Extract and load contacts and companies

Extract all customers and companies from LiveAgent via API v3. Load companies into Freshdesk first, then contacts, so company_id is available when you create contacts. Deduplicate contacts by email before creating to avoid HTTP 409 conflicts. Freshdesk requires at least one identifier (email, phone, mobile) per contact.

import requests, time
 
LA_URL = "https://youraccount.ladesk.com/api/v3"
HEADERS = {"apikey": "YOUR_LA_API_KEY"}
 
def extract_customers():
    customers = []
    page = 1
    while True:
        resp = requests.get(
            f"{LA_URL}/contacts",
            headers=HEADERS,
            params={"_perPage": 100, "_page": page}
        )
        if resp.status_code == 200:
            batch = resp.json()
            if not batch:
                break
            customers.extend(batch)
            page += 1
            time.sleep(0.34)  # respect 180 req/min
        elif resp.status_code == 429:
            time.sleep(60)
        else:
            raise Exception(f"Error {resp.status_code}: {resp.text}")
    return customers

Step 4: Create agents and groups in Freshdesk

Map LiveAgent Departments to Freshdesk Groups. Create agents and assign them to groups. Each agent consumes a paid seat. Agents must be active in Freshdesk before importing tickets to preserve assignment — if you send a payload containing an unrecognized Agent ID, Freshdesk will default the ticket to the administrator running the API key, permanently losing the original ownership context.

Step 5: Extract tickets and messages from LiveAgent

For each ticket, call GET /api/v3/tickets/{ticketId}/messages to retrieve the full message thread including agent replies, customer responses, internal notes, and attachment URLs. Extract tickets using date windows, not one broad range.

Step 6: Transform and load tickets into Freshdesk

Map LiveAgent status values to Freshdesk numeric status codes. Maintain a local ID mapping table that caches old LiveAgent IDs and maps them to newly generated Freshdesk IDs. Every ticket payload must reference this mapping table before dispatching the POST request.

To preserve original timestamps, use the Freshdesk Ticket Import API (POST /api/v2/import/tickets) instead of the standard ticket create endpoint. The standard create endpoint sets created_at to the current date. The Import API accepts created_at and updated_at as writable fields in ISO 8601 format. Example payload with timestamp preservation:

{
  "subject": "Original ticket subject",
  "description": "Ticket body HTML",
  "email": "customer@example.com",
  "status": 4,
  "priority": 2,
  "created_at": "2023-06-15T14:30:00Z",
  "updated_at": "2023-07-01T09:15:00Z",
  "tags": ["migrated", "legacy"]
}

Verify this payload structure against your Freshdesk sandbox before running a full migration. The Import API endpoint may have different availability or behavior across plan tiers. (developers.freshdesk.com)

Create ticket shells first, then replay history in chronological order:

for window in split_into_date_windows(start, end):
    tickets = liveagent.get("/api/v3/tickets", params=window_filter(window))
 
    for ticket in tickets:
        messages = liveagent.get(f"/api/v3/tickets/{ticket['id']}/messages")
        company_id = ensure_company(ticket)
        contact_id = ensure_contact(ticket, company_id)
        fd_ticket = freshdesk.post("/api/v2/import/tickets", map_ticket(ticket, contact_id, company_id))
 
        for msg in sort_by_created_at(messages):
            freshdesk.post(
                f"/api/v2/tickets/{fd_ticket['id']}/notes",
                {
                    "body": render_html(msg),
                    "private": is_internal_note(msg),
                    "incoming": is_customer_event(msg)
                }
            )

Implement retry logic with exponential backoff for HTTP 429 responses:

FD_URL = "https://yourdomain.freshdesk.com/api/v2"
FD_AUTH = ("YOUR_FD_API_KEY", "X")
 
def create_ticket(ticket_data, retries=0, max_retries=5):
    resp = requests.post(
        f"{FD_URL}/import/tickets",
        auth=FD_AUTH,
        json=ticket_data
    )
    if resp.status_code == 201:
        return resp.json()["id"]
    elif resp.status_code == 429:
        wait = int(resp.headers.get("Retry-After", 60))
        backoff = min(wait * (2 ** retries), 300)  # cap at 5 minutes
        time.sleep(backoff)
        if retries < max_retries:
            return create_ticket(ticket_data, retries + 1, max_retries)
        else:
            log_error("Max retries exceeded", ticket_data)
            return None
    elif resp.status_code == 409:
        log_duplicate(ticket_data)
        return None
    elif resp.status_code == 422:
        log_validation_error(resp.text, ticket_data)
        return None
    else:
        log_error(resp.status_code, resp.text, ticket_data)
        return None

Sanitize the HTML bodies of your messages during transformation. Freshdesk rejects payloads with malformed HTML. LiveAgent often embeds images directly into the HTML body using base64 encoding — your transformation script must parse the HTML, extract base64 images, upload each as a standard Freshdesk attachment, and rewrite the <img> tag src attribute to reference the new attachment URL. Failing to handle this results in broken image icons across your historical archive and potentially rejected payloads due to Freshdesk's request size limits.

Step 7: Migrate the knowledge base

Extract KB entries from LiveAgent via GET /api/knowledgebase/entries. Transform the two-level hierarchy (Category > Article) into Freshdesk's three-level structure (Category > Folder > Article) by creating an intermediate folder for each category. Use Freshdesk's Solutions API (POST /api/v2/solutions/categories, POST /api/v2/solutions/folders/{folder_id}/articles) to create the hierarchy programmatically. LiveAgent KB categories can also contain forums and suggestions — these need a separate decision on whether to archive, migrate as tickets, or discard. (support.liveagent.com)

Step 8: Validate, delta sync, and cut over

Compare record counts between source and target. Spot-check conversation threading and attachment accessibility. Run a final delta sync to capture tickets created during the migration window, then cut over. For deeper QA, use the dedicated conversations endpoint (GET /api/v2/tickets/{id}/conversations) rather than the embedded ticket view, which returns only up to ten conversations.

Persist source IDs, destination IDs, payload hashes, and response codes throughout the migration. This audit trail is essential for debugging and rollback.

How Long Does a LiveAgent to Freshdesk Migration Take?

A realistic timeline depends on ticket volume, schema complexity, and whether you run the migration in-house or use a managed service. Here is a phased breakdown for a typical 25,000 to 50,000 ticket migration:

Small, clean datasets move faster. Large helpdesks with years of attachments, custom fields, or knowledge base restructuring typically push into the 2 to 4 week range. For broader planning context, see our help desk migration timeline guide.

For a zero-downtime migration, run the historical migration while LiveAgent remains active, execute a final delta sync to capture new tickets, validate in Freshdesk, and only then cut over.

Risk Register

What Do Customers Notice During the Migration?

In a well-executed migration, end users notice very little. Here is what to plan for:

• Ticket history. If messages are migrated correctly via the API, agents in Freshdesk see the full conversation thread for every historical ticket. Customers who access the portal see their past tickets.
• Ticket IDs change. Freshdesk assigns new ticket IDs. If your team references ticket IDs in external communications, prepare a mapping table and update any active references.
• SLA timers reset. Freshdesk SLA policies are recreated from scratch. Historical SLA compliance data from LiveAgent does not transfer. Export SLA reports from LiveAgent before cutover for compliance records.
• Customer portal URL changes. The support portal URL changes from your LiveAgent domain to your Freshdesk domain. Set up redirects and update all customer-facing links.
• Note visibility matters. Freshdesk public notes are customer-visible when private=false, while private notes stay agent-only. History replay choices directly affect customer trust — make sure internal communications stay private.

Communicate the cutover date to your agents two weeks in advance. Provide documentation on how LiveAgent Departments translate to Freshdesk Groups so agents know where to find their queues. Explain how Freshdesk handles SLA timers differently — the pause logic on pending tickets varies between the two platforms. Conduct training sessions focused on the Freshdesk interface so productivity does not dip during the first week.

Finish active chats and calls in LiveAgent before cutover. Chatting and Calling are live session states, not clean archived data — they do not migrate gracefully.

Edge Cases and Known Limitations

• Attachment size mismatch. Freshdesk enforces a strict 20 MB limit for incoming attachments. LiveAgent allows up to 25 MB. If a LiveAgent ticket contains oversized files, the Freshdesk API will reject the payload with HTTP 422. Compress the file, host it externally (e.g., S3 with a signed URL), or append a download link to the ticket body.
• Inline images in ticket bodies. LiveAgent often embeds images using base64 encoding in the HTML body. Freshdesk has strict request payload size limits and may reject messages with massive base64 strings. Parse the HTML, extract base64 images, upload each to Freshdesk as a standard attachment, and rewrite the <img> tag to point to the new URL.
• Duplicate contacts. LiveAgent allows multiple contacts with the same email across different customer groups. Freshdesk enforces email uniqueness across the entire account. Deduplicate before import or merge records. Use Freshdesk's GET /api/v2/contacts?email={email} to check for existing contacts before creation.
• Multiple requesters per ticket. LiveAgent allows multiple customers on a single ticket in certain routing scenarios. Freshdesk requires a single primary requester. Designate one customer as the primary requester and add the others as CCs using the cc_emails field.
• Multi-knowledge-base setups. LiveAgent supports multiple knowledge bases per account. Freshdesk supports multiple Solution portals on certain plans, but the mapping is not 1:1. Plan the folder hierarchy carefully and verify your Freshdesk plan supports the number of portals you need.
• Chat and call transcripts. LiveAgent stores chat sessions and call recordings as separate objects. Freshdesk does not have a native historical import for chat transcripts. Attach them as text files or notes on associated tickets.
• Freshdesk pagination ceiling. Freshdesk's filter endpoint (/api/v2/search/tickets) is capped at 10 pages of 30 results each (300 results total). For large datasets, use the List All Tickets endpoint (GET /api/v2/tickets) with updated_since filters instead.
• Custom field creation. Freshdesk custom fields must be pre-created in the admin UI before API writes. There is no API endpoint to programmatically create custom field definitions.
• Freshdesk per-agent pricing. Freshdesk charges per agent per month. For large teams on LiveAgent's flat-rate plans (e.g., Large plan at $59/month for unlimited agents), moving to Freshdesk can increase agent seat costs significantly. A 20-agent team on Freshdesk Pro costs $980/month versus LiveAgent's flat rate. Factor this into your total cost of ownership before migrating.

How to Validate a LiveAgent to Freshdesk Migration

Never execute a final cutover without a completed validation phase. Cover four layers:

1. Record-count reconciliation. Compare total tickets, contacts, companies, and KB articles between source and target. The numbers must match exactly. Use LiveAgent's GET /api/v3/tickets?_perPage=1 with the total count header and Freshdesk's GET /api/v2/tickets?per_page=1 with the X-Total-Count response header.
2. Field-level spot checks. Sample 2% to 5% of migrated tickets (minimum 100 tickets for datasets over 5,000). Verify subject, status, priority, assignee, tags, custom field values, and conversation thread completeness.
3. Attachment verification. Confirm that attachments are downloadable from Freshdesk. Check file sizes match the originals. Verify at least 20 tickets with attachments across different size ranges.
4. User acceptance testing (UAT). Have 2 to 3 agents work in Freshdesk for 1 to 2 days using real workflows. Check that ticket search, filters, and reporting function as expected.

Do not rely solely on visual spot checks. Write a validation script that queries the Freshdesk API for a random sample of migrated tickets. Have the script compare created_at timestamps, message counts, and custom field values against the original LiveAgent data. For deep thread validation, use the dedicated conversations endpoint (GET /api/v2/tickets/{id}/conversations) rather than include=conversations, because the embedded ticket view returns only up to ten conversations.

For a comprehensive post-migration testing framework, see our post-migration QA checklist.

Rollback Plan

Create a rollback plan before starting the migration. Keep LiveAgent active and accessible for a minimum of 30 days after cutover. Do not cancel your LiveAgent subscription until validation is fully complete.

If the migration fails on go-live day:

1. Re-route inbound email. Change your support email forwarding rules (in your email provider or MX records) back to LiveAgent's inbound address. This typically takes 5 to 15 minutes for forwarding rule changes, or up to 24 hours for MX record propagation.
2. Update customer portal links. Revert any DNS CNAME changes pointing your support subdomain from Freshdesk back to LiveAgent.
3. Handle tickets created in Freshdesk during the failed window. Export any new Freshdesk tickets via GET /api/v2/tickets?updated_since={cutover_timestamp} and manually recreate them in LiveAgent, or forward them via email.
4. Communicate to agents. Send an immediate notification that the team is reverting to LiveAgent, with instructions to resume work in the original system.

Build In-House or Use a Managed Service

Build in-house when:

• Your dataset is small (under 5,000 tickets)
• You have no custom fields or only basic ones
• You have an available engineer with API experience and 2 to 3 weeks of bandwidth
• You do not need zero-downtime cutover

Use a managed service when:

• Your dataset exceeds 20,000 tickets
• You have complex custom fields, multi-department routing, or a large knowledge base
• You need zero downtime and a delta sync
• Engineering bandwidth is better spent on product work
• You cannot afford a re-migration if something breaks

The hidden cost of a DIY migration is not the initial script. It is the debugging: broken requester associations, silently dropped custom field values, attachment re-hosting failures, inline image parsing, matching AWS S3 attachments to ticket IDs, and the 15 to 20 hours of validation that follows every test run. A failed first attempt typically doubles the total engineering investment.

ClonePartner bypasses native export limitations by interacting directly with the LiveAgent API to extract full message history and attachments. We programmatically manage Freshdesk plan-based rate limits to ensure zero failed ticket creations during high-volume transfers. Our engineers handle the Department-to-Group mapping, custom field pre-creation, inline image re-hosting, and delta sync to guarantee zero downtime.

Frequently Asked Questions

Can I migrate LiveAgent to Freshdesk without losing data? Yes, but only if you extract data via the LiveAgent API v3. The native CSV export drops full message history and only provides a ticket preview. API-based extraction preserves all messages, notes, attachments, and metadata. (support.liveagent.com)

How much does a LiveAgent to Freshdesk migration cost? A DIY API migration costs 80 to 120 engineer-hours for a mid-size dataset (5,000 to 50,000 tickets). Third-party migration tools charge based on record volume, typically $500 to $3,000 for small datasets. Managed migration services range from $3,000 to $15,000+ for 10,000 to 100,000 tickets depending on complexity, custom fields, and attachment volume.

Can LiveAgent ticket timestamps be preserved in Freshdesk? Yes, using the Freshdesk Ticket Import API (/api/v2/import/tickets), which accepts writable created_at and updated_at fields. The standard ticket create endpoint (/api/v2/tickets) does not support writable timestamps. Verify behavior in your Freshdesk sandbox before committing to a plan. (developers.freshdesk.com)

Does Freshdesk have a native LiveAgent import tool? No. Freshdesk does not offer a built-in import wizard for LiveAgent. The migration must be done via API scripts, third-party tools, or a managed service.

Can LiveAgent private notes be preserved in Freshdesk? Yes, as Freshdesk private notes using private=true on the notes endpoint. The extraction trap is that since LiveAgent 5.62, notes can share message type M with regular messages and can carry UUID group IDs instead of integer IDs. Your extraction logic must handle both old and new note markers. (support.liveagent.com)

What happens to LiveAgent chat and call data? LiveAgent chat transcripts and call recordings are stored as separate objects and have no native import path into Freshdesk. The recommended approach is to attach chat transcripts as text file attachments on associated tickets, and link call recordings as external URLs in ticket notes.

Should I migrate LiveAgent forums to Freshdesk? LiveAgent forums have no direct Freshdesk equivalent. Forum topics that created tickets in LiveAgent can migrate as tickets. Standalone forum discussions are typically archived as HTML exports or migrated to a dedicated community platform like Discourse or Freshdesk's community portal (available on Pro and Enterprise plans).