How to Migrate from LiveAgent to Zendesk: The Complete Guide

What Is a LiveAgent to Zendesk Migration?

A LiveAgent to Zendesk migration is the process of moving tickets, messages, customers, companies, agents, departments, tags, custom fields, knowledge base articles, and attachments from LiveAgent's multi-channel helpdesk into Zendesk Support while preserving conversation history, timestamps, and relational integrity.

Why Teams Move from LiveAgent to Zendesk

Teams typically leave LiveAgent for three platform-specific reasons:

1. Integration ecosystem. Zendesk's marketplace lists over 1,500 pre-built integrations compared to LiveAgent's approximately 40 native integrations. Teams outgrow LiveAgent when they need deeper connections to CRMs, BI tools, and developer platforms.
2. Advanced automation and AI. Zendesk offers Intelligent Triage, AI Agents, and a mature trigger/automation engine that LiveAgent's Rules system cannot match at scale.
3. Enterprise compliance and reporting. Zendesk provides HIPAA-eligible configurations, SOC 2 Type II compliance, Explore analytics, and a sandbox environment for testing changes before production. LiveAgent's reporting is functional but less flexible for enterprise audit requirements.

For a broader comparison of Zendesk's capabilities and limitations, see our Zendesk guide.

What Makes This Migration Non-Trivial

Three architectural differences create the most friction:

• Ticket status mismatch. LiveAgent uses 7+ statuses (New, Open, Answered, Postponed, Resolved, Closed, Chatting, Calling) while Zendesk uses 6 (New, Open, Pending, On-hold, Solved, Closed). "Answered" and "Postponed" have no direct equivalent in Zendesk and require a mapping decision that the business team — not engineering — must own.
• Conversation threading model. LiveAgent stores messages as individual records under a ticket with a channel_type field (E for email, F for contact form, C for chat, W for call). Zendesk stores all interactions as ticket comments with a public boolean flag. Merging multi-channel threads into a single comment stream requires careful ordering by timestamp.
• Source-constrained extraction. LiveAgent's cloud API is capped at 180 requests per minute per API key, and the /tickets endpoint caps filter results at 10,000 records per query (support.liveagent.com). Large exports must be windowed by date range (support.liveagent.com).

How Do LiveAgent Objects Map to Zendesk Objects?

The object mapping table below is the foundation of every LiveAgent to Zendesk migration. Get this wrong and downstream relationships break silently.

Map the routing model first, then the people model, then the ticket thread. If you map Companies to Groups or Departments to Organizations, the import will look plausible and then fail operationally.

What Has No Clean Equivalent in Zendesk?

• LiveAgent Departments handle both agent assignment and SLA routing in one object. In Zendesk, you split this into Groups (for assignment) and SLA Policies (for response time rules).
• Predefined Answers and Canned Messages are exportable via LiveAgent API v3 but cannot be imported into Zendesk via API. They must be recreated manually as Macros.
• Call recordings stored in LiveAgent cannot be attached to Zendesk tickets natively. Store them in external storage (S3, Google Cloud Storage) and reference them via a custom URL field.
• LiveAgent forums, topics, and suggestion categories do not have a clean first-class destination in Zendesk Guide. Archive them, remodel them as articles, or move them to a community product outside Guide (support.liveagent.com).
• Gamification data (badges, levels, rewards) does not transfer.
• Agent performance reports stay in LiveAgent. Export reports as CSV before decommissioning.
• SSO configuration (SAML or OAuth for customer portal access) does not transfer. Zendesk SSO must be reconfigured from scratch, including identity provider metadata, attribute mappings, and certificate uploads. If LiveAgent used SSO for customer portal login, plan 1–2 days of additional configuration and testing in Zendesk.

Status Mapping Table

What Are the Migration Approaches for LiveAgent to Zendesk?

Several methods exist. The right choice depends on your ticket volume, engineering bandwidth, and tolerance for data loss.

1. Native CSV Export

How it works: Export tickets from LiveAgent's UI as CSV.

When to use it: Only for teams with fewer than 2,000 records who do not need conversation history.

Limitations:

• LiveAgent's CSV export captures ticket metadata (ID, subject, status, tags) but not full message threads or internal notes (support.liveagent.com)
• Large CSV exports from LiveAgent frequently truncate between 2,200 and 2,500 rows, returning a 500 Internal Server Error. This behavior has been reported across multiple LiveAgent support threads but is not formally documented as a hard limit.
• Zendesk's CSV import handles users and organizations only — you cannot import tickets via CSV into Zendesk
• Inline images from tickets are not included in the exported HTML

Complexity: Low | Scalability: Poor | Data Fidelity: Low

2. Custom API-Based Migration (DIY)

How it works: Write scripts to extract data via LiveAgent API v3 and load into Zendesk via the Ticket Import API.

When to use it: Teams with engineering resources, 5,000 to 100,000 tickets, and a need for full thread preservation.

Pros:

• Full control over field mapping and transformation logic
• Preserves complete conversation history with original timestamps
• Can handle attachments, custom fields, and complex relationships

Cons:

• LiveAgent API v3 is rate-limited to 180 requests per minute per API key (support.liveagent.com)
• Requires handling pagination (_page and _perPage parameters, max 1,000 rows per page). Some endpoints use cursor-based pagination instead
• /tickets filter results are capped at 10,000 records — large exports must be windowed by date range (support.liveagent.com)
• Attachment download URLs may be incorrect from LiveAgent version 5.25 onward — use download_url from the messages endpoint instead
• Typical development time: 2 to 4 weeks for an experienced engineer

Complexity: High | Scalability: Good | Data Fidelity: High

3. LiveAgent Database Dump + Custom ETL

LiveAgent offers database dumps to paying customers leaving the service, with data stored across SQL and AWS S3. Use this path only when API limits or unsupported edge cases make the API route impractical (support.liveagent.com).

Complexity: High | Scalability: Enterprise | Data Fidelity: High (with significant schema work)

4. Third-Party Self-Serve Migration Tool

Tools like Help Desk Migration provide a UI-based mapping and record-based pricing. Attachments, comments, and notes typically do not increase cost (help-desk-migration.com). Works well for standard helpdesk moves but custom logic costs extra when the source model is complex.

Complexity: Medium | Scalability: Mid-size | Data Fidelity: Medium

5. Managed Migration Service

A migration partner handles extraction, transformation, loading, and validation end to end. Best for teams with more than 10,000 tickets, complex custom field structures, compliance requirements (HIPAA, GDPR), or no available engineering bandwidth.

Complexity: Low (for your team) | Scalability: Excellent | Data Fidelity: High

Approach Comparison Table

How Does the Migration Architecture Work?

Extracting Data from LiveAgent

LiveAgent API v3 is the only reliable extraction method. API v1 is deprecated and will not receive new endpoints.

Key endpoints:

• GET /api/v3/tickets with _page and _perPage parameters (max 1,000 per page)
• GET /api/v3/tickets/{ticketId} for full ticket details including custom fields
• GET /api/v3/tickets/{ticketId}/messages for all messages, notes, and attachment URLs
• GET /api/v3/agents for agent records
• GET /api/v3/companies for company records
• GET /api/v3/tags for tag definitions

Rate limits: 180 requests per minute per API key on cloud accounts. This limit cannot be increased on cloud-hosted instances. Standalone (self-hosted) installations can override this limit in server configuration (support.liveagent.com).

10,000 record filter cap: The /tickets endpoint caps results at 10,000 records per filter query. For large datasets, split the backfill by date_created windows (by month or week) to stay under this limit. Use date_changed or m_datecreated for delta passes (support.liveagent.com).

Throughput math: For a dataset of 50,000 tickets with an average of 8 messages per ticket, you need approximately 450,000 API calls (50K ticket list calls + 50K detail calls + 350K message calls). At 180 requests per minute, that is roughly 42 hours of extraction time using a single API key.

Pagination gotcha: Some LiveAgent API v3 endpoints use _cursor instead of _page for pagination. The endpoints that use cursor-based pagination include GET /calls, GET /tickets/history, and GET /phone_numbers. The cursor value comes from the next_page_cursor response header.

Timezone gotcha: LiveAgent API v3 returns dates in the account's timezone, not UTC. You must include a Timezone-Offset header in your API calls or convert all timestamps to UTC before loading into Zendesk.

Cloud vs. self-hosted differences: Self-hosted (standalone) LiveAgent installations may have different database schemas depending on version, and API rate limits can be overridden in server config. The extraction approach is the same, but pagination behavior, available endpoints, and version-specific bugs may differ. Always verify your LiveAgent version number before starting extraction.

Loading Data into Zendesk

Use the Ticket Import API (POST /api/v2/imports/tickets) for all historical tickets. Do not use the standard Tickets API for migration — it overwrites created_at with the server's current time and fires triggers (developer.zendesk.com).

Key behaviors of the Ticket Import API:

• Preserves created_at, updated_at, and solved_at timestamps
• Supports multiple comments per ticket, each with its own created_at
• Supports archive_immediately: true for closed tickets, which bypasses the normal lifecycle and writes directly to the archive
• Does not fire triggers on import (triggers resume on subsequent updates)
• Does not send notifications to CC'd users
• SLAs and metrics are not computed for imported tickets

Critical constraints:

• Requesters and submitters must be active users in Zendesk. Suspended or deleted users will cause the import to fail
• Empty comment bodies are rejected by the API — add placeholder text like "(No message body)" during transformation
• Zendesk assigns new ticket IDs during import. Original LiveAgent ticket IDs cannot be preserved. Store the LiveAgent ticket code in external_id or a dedicated custom text field for cross-reference
• Attachments must be uploaded first via POST /api/v2/uploads, then referenced by token in the comment payload
• Bulk user imports are not enabled by default for all Zendesk accounts — confirm this capability before your dry run (developer.zendesk.com)
• Job-based bulk endpoints are capped at 30 queued or running jobs at once
• Comments can use value, body, or html_body — choose html_body when LiveAgent email formatting matters

Zendesk rate limits by plan:

For migration workloads, the Zendesk side is the bottleneck on Team and Growth plans. On a Growth plan (400 req/min), importing 50,000 tickets with an average of 3 comments each requires approximately 200,000 API calls. At 400 req/min, that is roughly 8 to 9 hours of load time (developer.zendesk.com).

For large datasets, batch Zendesk imports using /api/v2/imports/tickets/create_many, which accepts up to 100 tickets per request.

Sandbox behavior note: Zendesk sandbox environments may have lower rate limits than production and do not support all API features identically. The Ticket Import API works in sandbox, but bulk import throughput may be throttled more aggressively. Always validate sandbox results but do not use sandbox performance numbers to estimate production migration duration (support.zendesk.com).

Error Handling Patterns

Robust error handling is critical for migrations at scale. The LiveAgent API can return transient errors, and the Zendesk Ticket Import API can partially fail within a batch.

LiveAgent extraction errors:

• HTTP 429 (Rate Limited): Back off for 60 seconds, then retry. Implement exponential backoff with a cap of 5 retries.
• HTTP 500 (Server Error): Retry up to 3 times with 30-second delays. If persistent, skip the record, log it, and continue. Revisit skipped records in a cleanup pass.
• HTTP 503 (Service Unavailable): Pause extraction for 5 minutes. LiveAgent cloud instances occasionally return 503 during maintenance windows.
• Timeout / connection reset: Set a 30-second timeout per request. Log and retry.

Zendesk import errors:

• Partial batch failure: When using /api/v2/imports/tickets/create_many, the job status response includes per-record results. A batch of 100 tickets may succeed for 97 and fail for 3. Parse the results array, extract failed records, fix the issue (usually a missing user or invalid field value), and re-import only the failed records.
• HTTP 422 (Unprocessable Entity): Usually caused by a missing requester_id, invalid status, or a dropdown custom field value that does not match any option. Log the full response body — Zendesk returns a human-readable error message.
• Duplicate detection: Zendesk does not deduplicate on external_id by default. If a retry causes a duplicate import, you must clean up manually. Use idempotency keys in your staging database to track which records have been successfully imported.

# Example: Robust error handling for LiveAgent extraction
import requests, time, logging
 
def safe_get(url, headers, max_retries=5):
    for attempt in range(max_retries):
        try:
            resp = requests.get(url, headers=headers, timeout=30)
            if resp.status_code == 200:
                return resp.json()
            elif resp.status_code == 429:
                wait = 60 * (2 ** attempt)
                logging.warning(f"Rate limited. Waiting {wait}s. Attempt {attempt+1}")
                time.sleep(wait)
            elif resp.status_code in (500, 503):
                logging.warning(f"Server error {resp.status_code}. Retry {attempt+1}")
                time.sleep(30 * (attempt + 1))
            else:
                logging.error(f"Unexpected {resp.status_code}: {resp.text}")
                return None
        except requests.exceptions.Timeout:
            logging.warning(f"Timeout on attempt {attempt+1}")
            time.sleep(10)
    logging.error(f"Failed after {max_retries} attempts: {url}")
    return None

What Is the Step-by-Step Migration Process?

The order of operations matters. Creating tickets before users exist in Zendesk will fail. Loading attachments after tickets are imported will orphan them.

Step 1: Audit and Extract LiveAgent Data

Inventory tickets, messages, note types, departments, companies, custom fields, KB entries, rules, and SLAs. Decide which objects are live data and which should be archived. For guidance on what to migrate versus archive, see our help desk migration playbook.

Pull all records using LiveAgent API v3. Store everything in a local staging database (PostgreSQL or SQLite) or as structured JSON files. Window your extraction by date_created to stay under the 10,000 record filter cap.

# Example: Extract tickets from LiveAgent API v3
import requests, time
 
API_URL = "https://youraccount.ladesk.com/api/v3"
API_KEY = "your_api_key"
headers = {"apikey": API_KEY}
 
def get_tickets(page=1, per_page=100):
    params = {"_page": page, "_perPage": per_page, "_sortDir": "ASC"}
    resp = requests.get(f"{API_URL}/tickets", headers=headers, params=params)
    if resp.status_code == 429:
        time.sleep(60)
        return get_tickets(page, per_page)
    return resp.json()

For date-windowed extraction on large datasets:

GET /api/v3/tickets?_page=1&_perPage=100&_filters=[[date_created,D>=,2025-01-01 00:00:00],[date_created,D<,2025-02-01 00:00:00]]&_sortField=date_created
Host: your.ladesk.com
apikey: LIVEAGENT_KEY
Content-Type: application/json

Clean the data by identifying users with missing email addresses, removing duplicate tags, and deduplicating customers by email. Zendesk requires unique email addresses for all users and will reject any user creation payload that lacks a valid email or phone number.

GDPR and data residency considerations: During migration, extracted data is staged locally or in cloud storage before loading into Zendesk. For GDPR-regulated teams, document where staging data resides, ensure it is encrypted at rest and in transit, and delete staging copies within a defined retention window (typically 30 days post-cutover). LiveAgent's API calls originate from your infrastructure to LiveAgent's servers; Zendesk allows you to select data center region (US or EU) at account creation but not after. Confirm your Zendesk data center region before starting the migration. If you are migrating from a LiveAgent EU instance to Zendesk, ensure your Zendesk account is provisioned in the EU data center to maintain data residency compliance.

Step 2: Create Zendesk Infrastructure

Before importing any records, create the following in Zendesk:

• Custom ticket fields (matching LiveAgent field codes and types)
• Custom user fields
• Groups (mapped from LiveAgent Departments)
• Organizations (mapped from LiveAgent Companies)
• Agent accounts
• Any custom ticket statuses you need
• SSO/SAML configuration if LiveAgent used SSO for customer or agent portal access

Dropdown fields must match the exact tag values of Zendesk dropdown options or the import will fail. If you plan bulk user creation, confirm bulk imports are enabled on your Zendesk account.

For teams with complex relational custom data in LiveAgent (e.g., multi-entity relationships, lookup tables, or structured records that don't fit into flat custom fields), evaluate Zendesk Sunshine Custom Objects as the target instead of custom ticket fields. Sunshine Custom Objects support relationships between records and are accessible via the Zendesk API (developer.zendesk.com).

Step 3: Import Users and Organizations

Import organizations before users so you can link users to their organization during creation. Use POST /api/v2/users/create_or_update to import customers, matching on email address to prevent duplicates. Store the mapping of LiveAgent User IDs to Zendesk User IDs in a lookup table.

Step 4: Upload Attachments

Download all attachments from LiveAgent using the download_url from the messages endpoint. Do not use the downloadUrl from the files endpoint — from LiveAgent version 5.25 onward, this URL may be incorrect. Upload each file to Zendesk via POST /api/v2/uploads and store the returned token for use in ticket import.

Zendesk enforces a 50MB limit per ticket attachment. Any LiveAgent attachment exceeding this size must be logged as an exception. Zendesk Guide article attachments have a separate 20MB limit (developer.zendesk.com). Attachment-heavy tickets slow the migration twice — once on download and once on re-upload. Budget time for checksum and open-file validation, not just count validation.

Step 5: Import Tickets with Full History

Use POST /api/v2/imports/tickets with all comments, attachment tokens, custom field values, tags, and mapped statuses. Include archive_immediately: true for closed tickets. If you set assignee_id, also set group_id.

Replace all LiveAgent author IDs with the new Zendesk User IDs from your lookup table. Format LiveAgent messages as Zendesk comments, setting public: false for internal notes. Store the original LiveAgent ticket code in external_id for traceability.

# Example: Import a ticket into Zendesk with preserved timestamps
import requests
 
ZD_URL = "https://yourinstance.zendesk.com/api/v2/imports/tickets"
auth = ("[email protected]/token", "your_api_token")
 
payload = {
    "ticket": {
        "subject": "Original ticket subject",
        "external_id": "LA-12345",
        "created_at": "2024-03-15T10:30:00Z",
        "updated_at": "2024-03-16T14:22:00Z",
        "status": "solved",
        "requester_id": 12345,
        "assignee_id": 67890,
        "group_id": 111,
        "tags": ["migrated", "liveagent-import"],
        "comments": [
            {
                "author_id": 12345,
                "created_at": "2024-03-15T10:30:00Z",
                "html_body": "<p>Original customer message</p>",
                "public": True
            },
            {
                "author_id": 67890,
                "created_at": "2024-03-15T11:45:00Z",
                "value": "Agent response with reset link",
                "public": True
            },
            {
                "author_id": 67890,
                "created_at": "2024-03-15T12:00:00Z",
                "value": "Internal follow-up note",
                "public": False
            }
        ]
    }
}
 
resp = requests.post(ZD_URL, json=payload, auth=auth)

Step 6: Run Delta Sync

After the initial backfill, use date_changed and m_datecreated filters on the LiveAgent API to capture tickets or messages created or modified while LiveAgent stayed live. Repeat until the final cutover window is small enough to manage. This is the cleanest path to a low-downtime cutover (support.liveagent.com).

For post-migration verification or ongoing sync scenarios, Zendesk's Incremental Export API (GET /api/v2/incremental/tickets) can be used to verify that all records landed correctly by comparing counts and timestamps against your staging database (developer.zendesk.com).

Step 7: Validate and Reconcile

Do not trust the API's HTTP 200 response. A migration is done when the data has been verified, not when the last API call succeeds.

Record-count reconciliation:

• Compare total ticket count in LiveAgent against total imported tickets in Zendesk
• Compare total user count (customers) against end-users in Zendesk
• Compare total organization count
• Use Zendesk's Incremental Export API to pull all tickets created during the import window and compare against your staging database

Field-level spot checks:

• Sample 50 to 100 tickets across different statuses, departments, and date ranges
• Verify that all comments appear in correct chronological order
• Confirm custom field values match source data
• Check that attachments are downloadable from the Zendesk agent view — not just through API metadata

Functional testing:

• Verify that agents can open and respond to migrated tickets
• Confirm that new tickets route correctly to the right groups
• Test that triggers and automations do not fire incorrectly on imported tickets
• Run business-rule UAT on new tickets because imported historical tickets do not behave like freshly created tickets

For a detailed QA checklist, see our post-migration QA guide.

How Long Does a LiveAgent to Zendesk Migration Take?

A typical LiveAgent to Zendesk migration takes 1 to 3 weeks from kickoff to go-live. The actual data transfer is rarely the bottleneck. Planning, field mapping decisions, and validation consume most of the timeline.

Sample Timeline

Phased vs. Big-Bang Cutover

Big-bang works best for teams with fewer than 50,000 tickets. Run a full migration over a weekend and cut over Monday morning.

Phased works better for teams with 100,000+ tickets or strict uptime requirements. Migrate historical data first (closed tickets), then run a delta sync for tickets created during the migration window.

For a detailed breakdown of help desk migration timelines, see our timeline guide.

Cost Considerations

Migration costs vary significantly by approach:

• DIY API scripting: Engineering time only (80–160 hours at your loaded engineer cost). No external fees, but opportunity cost of pulling an engineer off product work.
• Third-party self-serve tools (e.g., Help Desk Migration): Record-based pricing. Typical cost ranges from $1 to $3 per 100 records for tickets. Attachments and comments usually do not increase cost. A 50,000-ticket migration typically costs $500–$1,500 for the tool license.
• Managed migration services: Fixed-fee or time-and-materials. Typical range: $3,000–$15,000+ depending on volume, complexity, and compliance requirements.
• Overlap period: Budget for 2–4 weeks of running both LiveAgent and Zendesk simultaneously. Zendesk Suite plans range from $55/agent/month (Team) to $169/agent/month (Enterprise) as of 2025. LiveAgent plans range from $15/agent/month (Small) to $69/agent/month (Enterprise).

Risk Register

Rollback plan: Keep LiveAgent as the active write system until the final delta passes validation. If cutover fails, revert MX records and email routing back to LiveAgent — this should be achievable within 15 minutes. Fix the transform and rerun the target import from the last clean batch.

What Do Customers and Agents Notice During Migration?

Customers should notice nothing if the migration is executed correctly. The goal is zero visible disruption.

Downtime: A well-planned migration requires zero downtime. Both LiveAgent and Zendesk can run in parallel during the transition. New tickets flow into LiveAgent until the cutover moment, then DNS or email routing switches to Zendesk.

Ticket history: All conversation history — customer messages, agent replies, and internal notes — is preserved with original timestamps when using the Ticket Import API. Customers who search for old tickets in the Zendesk portal will find their complete history.

What changes for customers:

• Ticket IDs change. Zendesk assigns new IDs during import. If customers reference ticket numbers, communicate this proactively. Store the original LiveAgent ID in external_id or a visible custom field so agents can cross-reference.
• Portal URL changes from youraccount.ladesk.com to youraccount.zendesk.com.
• Satisfaction survey workflows reset. LiveAgent's CSAT surveys do not transfer. Configure Zendesk's built-in satisfaction ratings before go-live.
• SSO login flow may change. If customers used SSO to access the LiveAgent portal, they will need to authenticate against the new Zendesk-configured identity provider. Test the SSO flow end-to-end before go-live.

What changes for agents:

• LiveAgent uses separate interfaces for chat versus email. Zendesk unifies these into the Agent Workspace.
• Agents need training on the new status behavior and interface. Schedule training at least one week before the go-live date.
• Provide agents with a LiveAgent-to-Zendesk ticket ID lookup sheet for the first 48 hours post-cutover.

What changes for chat and messaging channels:

• LiveAgent's chat widget must be replaced with Zendesk Messaging (or legacy Zendesk Chat, though Zendesk is actively migrating customers to Messaging). Zendesk Messaging is architecturally different from LiveAgent's chat: it supports asynchronous conversations, bot builders, and proactive messaging, but requires reconfiguring pre-chat forms, triggers, and routing from scratch.
• Chat widget embed codes change. Update all pages where the LiveAgent chat widget is embedded.
• If you used LiveAgent's chat-to-ticket escalation, configure equivalent behavior in Zendesk Messaging using the conversation bot and handoff triggers.

Change management checklist:

1. Send a customer-facing email 1 week before cutover explaining the new portal URL
2. Update documentation and email templates that reference the old portal
3. Brief all agents on Zendesk's interface before go-live (see our help desk migration training plan)
4. Monitor first-response times for 72 hours post-cutover to catch routing issues
5. Replace chat widget embed codes on all web properties
6. Test SSO login flow for both agents and customers if applicable

What Data Cannot Be Migrated from LiveAgent to Zendesk?

Some LiveAgent data has no API-accessible equivalent in Zendesk or requires manual recreation. Data usually moves. Behavior usually does not.

• Rules, Time Rules, and SLA Rules: LiveAgent's rule engine is structurally different from Zendesk's trigger/automation system. Rules must be audited and rebuilt manually. See our guide on migrating automations, macros, and workflows for a structured approach.
• Canned Messages and Predefined Answers: Exportable via LiveAgent API v3 but not importable into Zendesk. Recreate as Macros.
• Call recordings: Cannot be linked to imported tickets without custom field workarounds. Store in external storage and reference via a custom URL field.
• Chat widget configuration: Button placement, colors, pre-chat forms, and offline messages must be reconfigured in Zendesk Messaging.
• IVR and phone routing: Must be rebuilt in Zendesk Talk.
• Gamification data: Badges, levels, and rewards do not transfer.
• Agent performance reports: Historical reporting data stays in LiveAgent. Export reports as CSV before decommissioning.
• Forums and suggestion categories: No clean destination in Zendesk Guide. Archive, remodel as articles, or move to a separate community product.
• SSO/SAML configuration: Identity provider settings, attribute mappings, and certificates must be reconfigured in Zendesk.

Attachment Edge Cases

• LiveAgent inline images (embedded in ticket HTML) are not included in CSV or HTML exports. They must be extracted via the API messages endpoint.
• From LiveAgent version 5.25 onward, the downloadUrl returned by the files endpoint may be incorrect. Always use download_url from GET /api/v3/tickets/{ticketId}/messages instead.
• Zendesk requires attachments to be uploaded first via the Upload API, then referenced by token in the ticket comment. You cannot pass a URL and have Zendesk fetch the file.

CCs and BCCs

LiveAgent stores CCs and BCCs inside message headers. Zendesk requires you to map these users to the collaborator_ids array on the ticket object. If the CC email does not exist as a user in Zendesk, the API will drop the CC entirely — create the user first or accept the data loss.

Knowledge Base Migration

If migrating Knowledge Base content to Zendesk Guide:

• Zendesk Guide article attachments have a 20MB size limit (developer.zendesk.com). Heavier files should be moved to external storage and linked.
• Multi-brand Zendesk requires brand-specific subdomains for Help Center API requests. Decide brand splits before article import (developer.zendesk.com).
• Inline images in KB articles must be downloaded from LiveAgent and rehosted in Zendesk Guide.

Should You Build In-House or Use a Managed Service?

Build in-house when:

• You have fewer than 5,000 tickets with simple custom fields
• You have an engineer with API integration experience who can dedicate 2 to 4 weeks
• Your data model is straightforward (mostly email tickets, few custom fields, no call recordings)
• You are comfortable accepting the risk of data issues discovered post-cutover

Use a managed service when:

• You have more than 10,000 tickets or complex custom field structures
• You need zero downtime and cannot afford a re-migration
• Your team has no available engineering bandwidth
• You have compliance requirements (HIPAA, GDPR) that require documented chain of custody for data
• You need to preserve inline attachments, chat transcripts, and call metadata
• Your LiveAgent instance uses SSO, IVR, or multi-department SLA routing that requires parallel Zendesk configuration

The hidden cost of DIY is not the initial build. It is the 2 to 3 weeks of post-migration debugging when an engineer discovers that 12% of tickets have broken comment ordering, or that 400 customer records were duplicated because LiveAgent allowed multiple contacts with the same email. When scripts hit the LiveAgent 180 requests per minute limit, poorly written retry logic without idempotency tracking can cause duplicate ticket creation in Zendesk.