---
title: "LiveAgent to Richpanel Migration: A Technical Guide"
slug: liveagent-to-richpanel-migration-a-technical-guide
date: 2026-08-10
author: Raaj
categories: [Migration Guide, Help Desk, Ecommerce]
excerpt: "Technical guide to migrating from LiveAgent to Richpanel. Covers API extraction, data model mapping, status translation, rate limits, and step-by-step migration planning."
tldr: "LiveAgent to Richpanel is a structural migration from department-centric ticketing to e-commerce conversations. Use both APIs (180/100 RPM), map 10 statuses to 3, rebuild automations manually. Budget 1–5 weeks."
canonical: https://clonepartner.com/blog/liveagent-to-richpanel-migration-a-technical-guide/
---

# LiveAgent to Richpanel Migration: A Technical Guide


# LiveAgent to Richpanel Migration: A Technical Guide

> [!NOTE]
> **TL;DR:** A LiveAgent to Richpanel migration moves your helpdesk from a general-purpose, department-centric ticketing system to an e-commerce-focused, order-linked conversation platform. LiveAgent's built-in CSV export captures ticket metadata but not full message threads, internal notes, or attachments — you must use LiveAgent API v3 (`GET /tickets/{ticketId}/messages`) for complete extraction. The extraction bottleneck is LiveAgent's API rate limit of **180 requests per minute** per API key; the import bottleneck is Richpanel's API limit of **100 calls per minute** (492 status code on breach). LiveAgent's 10 ticket statuses must be collapsed into Richpanel's simpler Open/Resolved/Snoozed model. Automation rules, SLAs, canned messages, and knowledge base articles cannot be migrated programmatically. Realistic timeline: **1–3 weeks** for under 25K tickets, 3–5 weeks for larger or multi-brand setups. *Content validated against LiveAgent API v3 and Richpanel API as of Q2 2025.*

## The Architectural Shift: Ticketing System to E-commerce Platform

Migrating from LiveAgent to Richpanel is not a like-for-like vendor swap. It is a structural shift in how your support data is organized and accessed.

**LiveAgent** is a general-purpose, multi-channel helpdesk built around **Departments**. A ticket is a digital record of a customer request, containing contact details, issue details, and interaction history, originating from emails, phone calls, live chats, or social media messages. Departments route tickets, SLA rules enforce response times, and agents work from a unified inbox across email, chat, phone, social, and forums.

**Richpanel** is an e-commerce-native support platform built around **Orders**. In Richpanel, you don't have "tickets" — you have **Conversations**. A customer messages you, and that message is intrinsically linked to their most recent transaction. The platform assumes that Shopify, WooCommerce, or Magento order data is the primary lens for support.

This matters for migration because LiveAgent doesn't natively link tickets to e-commerce orders. Your extraction and transformation scripts must account for this shift. If you dump LiveAgent tickets into Richpanel without associating them with e-commerce customer profiles, you defeat the purpose of using Richpanel. The goal is to stitch historical LiveAgent interactions to the Shopify/Magento/WooCommerce customer records that Richpanel relies on.

### Why Teams Move from LiveAgent to Richpanel

Teams typically leave LiveAgent for Richpanel for three concrete reasons:

1. **E-commerce-native workflows.** Richpanel unifies email, live chat, social messaging, WhatsApp, SMS, and marketplace channels in one inbox, with deep integrations to Shopify, Loop, Recharge, TikTok Shop, and AfterShip. LiveAgent's ~220 native integrations are broader but shallower on e-commerce depth.
2. **AI-assisted resolution.** Teams handling repetitive order-tracking, return, and cancellation queries use Richpanel's AI layer to deflect these before they reach agents. LiveAgent offers rule-based automation but no AI resolution layer.
3. **Order-aware self-service.** Richpanel's self-service portal lets customers track orders, initiate returns, and manage subscriptions without contacting an agent — actions tied directly to the order record, not just a knowledge base article.

## Data Model Mapping: LiveAgent → Richpanel

Before writing a single line of migration code, map every LiveAgent object to its Richpanel equivalent.

| LiveAgent Object | Richpanel Object | Notes |
|---|---|---|
| Ticket | Conversation | 1:1 mapping. Store the original LiveAgent Ticket ID in a custom field for auditability. |
| Ticket Messages | Conversation Messages | Agent replies, customer replies, and system messages. Preserve chronological order. |
| Internal Notes | Internal Messages | Richpanel supports internal notes within conversations. Verify visibility settings post-migration. |
| Contact | Customer | Name, email, phone. Match `customer_email` exactly to your Shopify/WooCommerce records so Richpanel links the conversation to the correct order history. |
| Company | — | Richpanel has no native company/organization object. Flatten into customer custom fields or tags. |
| Department | Team | Not 1:1. LiveAgent Departments have email routing and SLA rules attached. Richpanel Teams are assignment groups only. |
| Tags | Tags | Direct transfer. Note: Richpanel sanitizes tag names into lowercase hyphenated values. |
| Custom Fields (Ticket) | Custom Fields | Check field type compatibility before import. |
| Custom Fields (Contact) | Customer Properties | LiveAgent enables custom contact fields for unique information like billing address, account number, or birthday. These map to Richpanel customer properties. |
| Knowledge Base Articles | Help Center Articles | No reliable API migration path. Must be recreated manually or via content extraction scripts. |
| Automation Rules | Automation Rules | Cannot be migrated. Must be rebuilt in Richpanel. |
| SLA Rules | — | Richpanel does not expose SLA configuration the same way. Must be redesigned. |
| Canned Messages | Macros / AI SOPs | Must be recreated manually in Richpanel. |
| Agents | Agents/Users | Agent profiles are recreated; passwords don't transfer. |

> [!WARNING]
> **Company data gap:** LiveAgent has a dedicated Companies feature that groups contacts under an organization. Richpanel is designed for D2C e-commerce and has no native company/organization object. If your support workflow relies on company-level views, you'll need to flatten this into customer-level custom fields or accept a structural loss.

## Extraction: Getting Data Out of LiveAgent

### Why CSV Export Isn't Enough

LiveAgent's CSV export includes ticket metadata columns — ticket ID, subject, status, department, tags, and dates — **but not full message threads, internal notes, or attachments**.

LiveAgent allows you to export individual tickets to HTML or PDF, but provides no built-in option to bulk-export all tickets with their complete message history. For a proper migration, you must use the **LiveAgent API v3**.

### LiveAgent API v3 Extraction Strategy

LiveAgent API v3 documentation is available within your account at `https://YOURDOMAIN.ladesk.com/docs/api/v3/#/`.

Key endpoints for extraction:

- `GET /tickets` — List all tickets (paginated)
- `GET /tickets/{ticketId}/messages` — Full message thread per ticket
- `GET /contacts` — Customer records
- `GET /companies` — Company records
- `GET /departments` — Department list
- `GET /tags` — Tag list
- `GET /agents` — Agent list

**Rate limit:** The API rate limit is 180 requests per minute, counted per API key separately. A 429 response indicates breach; implement exponential backoff (2s, 4s, 8s) on retry.

**Pagination quirk:** Some endpoints use `_cursor` instead of `_page` for pagination. Endpoints using `_cursor` include `GET /calls`, `GET /grid/reports/time`, `GET /phone_numbers`, and `GET /tickets/history`. Using `_page` on these endpoints will silently return incomplete results.

**10,000-ticket filter limit:** Since LiveAgent version 5.51, `GET /tickets` returns a maximum of 10,000 tickets per filter. You must shard your extraction by date range using `date_created` filters. A single unfiltered export will silently truncate results above 10,000.

**Timezone handling:** The LiveAgent panel recalculates dates according to the user's PC timezone, but API v3 returns data according to the account's timezone. Add a `Timezone-Offset` header to align dates. Missing this causes all migrated timestamps to be off by your account's UTC offset.

> [!TIP]
> **Extraction math:** At 180 RPM, extracting 20,000 tickets requires ~20,000 list calls + ~20,000 message-thread calls = ~40,000 API calls. At 180/min, that's ~222 minutes (~3.7 hours) of pure extraction time, excluding retries and attachment downloads. For 50K+ tickets, budget a full day.

### Extraction Script Pattern

Your extraction script should shard by date range and fetch messages per ticket:

```python
import time
import requests

BASE_URL = "https://YOURDOMAIN.ladesk.com/api/v3"
HEADERS = {"apikey": "YOUR_API_KEY"}

def extract_tickets(date_from, date_to):
    page = 1
    all_tickets = []
    filters = f'[["date_created","D>=","{date_from}"],["date_created","D<","{date_to}"]]'
    while True:
        resp = requests.get(
            f"{BASE_URL}/tickets",
            headers=HEADERS,
            params={"_page": page, "_perPage": 50, "_filters": filters}
        )
        if resp.status_code == 429:
            time.sleep(60)
            continue
        data = resp.json()
        if not data:
            break
        all_tickets.extend(data)
        page += 1
        time.sleep(0.35)  # Stay under 180 RPM
    return all_tickets

def extract_messages(ticket_id):
    resp = requests.get(
        f"{BASE_URL}/tickets/{ticket_id}/messages",
        headers=HEADERS
    )
    return resp.json()
```

For each ticket, call the messages endpoint separately. There is no bulk message export endpoint.

> [!CAUTION]
> **Note extraction trap:** From LiveAgent version 5.62 onward, internal notes can be stored with message type `M` and a different message group type. If you care about internal notes, your extractor must handle both the pre-5.62 and post-5.62 note patterns, or you'll silently miss notes in the extraction. Verify the note type field against the changelog for your specific LiveAgent instance version.

### Attachments

Attachments in LiveAgent are stored per message. Each message response includes attachment metadata with download URLs.

To migrate attachments:

1. Parse the LiveAgent message payload for attachment references.
2. Use the `download_url` field returned by the messages endpoint — not the older `downloadUrl` field, which can return incorrect values for ticket attachments from version 5.25 onward.
3. Download each file and stage it in temporary secure storage (AWS S3 or equivalent).
4. Pass the temporary URL to Richpanel during the injection phase.

LiveAgent stores recent data in its primary database; older data moves to AWS S3-backed storage. If your account has older ticket data, attachment URLs may point to S3 — verify they are still accessible before starting extraction, particularly for tickets older than 12 months.

LiveAgent enforces a 25 MB overall ticket attachment limit. Richpanel can return `413 Payload Too Large` on oversized uploads but does not publish a specific threshold in public documentation. Test files at the 20–25 MB range early in your sandbox validation phase.

> [!WARNING]
> **Inline images:** For security reasons, inline images from tickets are not added to exported HTML in LiveAgent. If your tickets contain inline screenshots or product images, these must be extracted via the API message endpoint and re-uploaded as attachments to Richpanel conversations. This is easy to miss and difficult to remediate after migration is complete.

### Alternative: Database Dump

Beyond the CSV export and API, you can request a database dump from LiveAgent's administration team by contacting `support@liveagent.com` from your account owner email address. This gives you raw database tables — faster to retrieve for large datasets but requires SQL knowledge to parse and transform into the format needed for Richpanel import. This is the appropriate fallback when API extraction becomes too fragmented for very large accounts (100K+ tickets) or when attachment retrieval is bottlenecked.

## Loading: Getting Data Into Richpanel

### Richpanel API Overview

Richpanel's API is organized around key objects: Conversations, Customers, Orders, Subscriptions, Tags, Teams, and Agents. Richpanel uses the same REST API internally to power its own web and mobile applications.

Authentication uses an API key passed in the `x-richpanel-key` header:

```bash
curl -X GET "https://api.richpanel.com/v1/users" \
  -H "accept: application/json" \
  -H "x-richpanel-key: YOUR_API_KEY"
```

**Rate limit:** Richpanel's API has a rate limit of 100 calls per minute. After crossing the limit, the API responds with a **492 status code**. `X-RateLimit-Limit` and `X-RateLimit-Remaining` headers are sent on all responses; `Retry-After` headers indicate wait time after a 492 is returned. These headers should drive your retry logic rather than a fixed sleep interval.

**appClientId requirement:** Many Richpanel endpoints require an `appClientId` parameter — a unique identifier representing a specific store or brand in your Richpanel account. Find your app client IDs in Richpanel Settings → Connected Apps. If you run multiple brands, each brand has its own `appClientId` and conversations must be routed to the correct one. Mixing brand data into a single `appClientId` will contaminate analytics and AI training data.

> [!WARNING]
> **Confirm API access before planning your migration.** Richpanel's API reference states that Developer API Access is only available on the Enterprise plan. Confirm API access for your specific workspace and plan before committing to a self-serve migration. Also confirm your **message history entitlement**: Richpanel's pricing structure limits historical conversation visibility by plan tier. There is no value in importing years of legacy conversations into a plan that won't expose them to your agents. Verify both constraints in writing with your Richpanel account contact.

### Sample Richpanel Conversation POST Payload

The following is a representative POST body for creating a backfilled conversation. Verify field availability against the current Richpanel API reference for your account version, as field names and writability can change between API releases:

```json
{
  "appClientId": "YOUR_APP_CLIENT_ID",
  "channel": "email",
  "subject": "Order #1234 - Where is my package?",
  "created_at": "2024-03-15T09:23:11Z",
  "status": "resolved",
  "customer": {
    "email": "customer@example.com",
    "name": "Jane Smith"
  },
  "assignee": {
    "agentId": "RICHPANEL_AGENT_ID"
  },
  "tags": ["order-inquiry", "shipping"],
  "customFields": {
    "liveagent_ticket_id": "LA-98765",
    "original_status": "Resolved",
    "source_channel": "email"
  },
  "messages": [
    {
      "type": "customer",
      "body": "Hi, I haven't received my order yet.",
      "created_at": "2024-03-15T09:23:11Z"
    },
    {
      "type": "agent",
      "body": "Hi Jane, I can see your order is in transit. Expected delivery is March 18.",
      "created_at": "2024-03-15T10:05:44Z",
      "agentId": "RICHPANEL_AGENT_ID"
    }
  ]
}
```

Key notes on this payload:
- `created_at` at the conversation level sets the original creation timestamp. Verify whether this field is writable or system-generated for your API version — if system-generated, all migrated conversations will carry the import date instead of the original date.
- `liveagent_ticket_id` stored as a custom field enables direct lookup and deduplication in subsequent runs.
- `source_channel` as a custom field preserves the original LiveAgent channel type (email, chat, call, social) since Richpanel's channel model doesn't map 1:1.

### Import Sequence

Load data into Richpanel in this order:

1. **Customers** — Create or update customer profiles first. Richpanel needs a customer record before you can attach conversations. Ensure `customer_email` exactly matches the email on file in your Shopify/WooCommerce instance.
2. **Tags** — Ensure all tags exist in Richpanel before assigning them to conversations.
3. **Teams** — Map LiveAgent Departments to Richpanel Teams. Create teams in Richpanel's admin panel.
4. **Conversations** — Create conversations with original timestamps, linked to customers and teams.
5. **Messages** — Add messages to each conversation in chronological order.
6. **Attachments** — Upload files and link them to the correct messages.

If your store runs on Shopify, Magento, or WooCommerce, connect it to Richpanel before importing conversations. Let Richpanel build order context natively before injecting historical conversation data.

### Import Throughput Math

At 100 calls per minute, Richpanel's rate limit is the primary import bottleneck. Consider a dataset of 50,000 LiveAgent tickets, each with an average of 3 messages:

- Creating the conversation: 1 API call
- Appending 3 messages: 3 API calls
- Total per ticket: 4 API calls (excluding customer creation)
- Total API calls: ~200,000

At 100 calls per minute, that's a minimum of **33.3 hours** of continuous, perfectly optimized API execution.

Your injection script must use a queueing system (Redis/Celery, AWS SQS, or RabbitMQ) with strict concurrency control and exponential backoff. A simple synchronous `for` loop will fail unpredictably as network latency and 492 errors compound.

For datasets above 50K records, contact Richpanel's team (`tech@richpanel.com`) to request a temporary rate limit increase during migration. Confirm this in writing before starting the import phase.

### Deduplication Strategy

If you run multiple extraction passes or a historical load followed by a delta sync, you must detect and skip records already imported. The recommended approach:

1. Store the original LiveAgent ticket ID in a Richpanel custom field (e.g., `liveagent_ticket_id`) during every conversation creation.
2. Before each import, query Richpanel for existing conversations with that custom field value. If a match exists, skip creation and log the duplicate.
3. Maintain a local manifest (CSV or database table) mapping `liveagent_ticket_id` → `richpanel_conversation_id` throughout the migration. This manifest is your ground truth for deduplication and gap analysis.

Without this, running a delta sync after a historical load will create duplicate conversations for any ticket touched between the two runs.

### Contact Matching Failure Handling

The migration assumes `customer_email` in LiveAgent matches an email in your Shopify/WooCommerce instance. In practice, this breaks in several common scenarios:

- Customer used a different email at checkout vs. when opening a support ticket
- Guest checkout with no registered account
- Email typos or legacy email addresses that were later changed

**Recommended fallback procedure:**
1. Attempt match on email. On success, proceed normally.
2. On no match, attempt match on phone number if available in the LiveAgent contact record.
3. On continued no match, create the conversation and customer record in Richpanel with the available data, but tag it `unmatched-order-profile` for manual review.
4. Log all unmatched records to a separate file. Post-migration, a support team member can manually link these conversations to the correct customer profiles in Richpanel.

Do not silently drop unmatched records. A failed email match is an addressable data quality issue, not a reason to discard the conversation history.

### API Error Reference

Common Richpanel API error codes during import and their remediation:

| HTTP Status | Meaning | Remediation |
|---|---|---|
| 400 | Malformed payload | Log the full request body; check required fields and data types |
| 401 | Invalid API key | Verify `x-richpanel-key` header; check key hasn't been rotated |
| 404 | Referenced object not found | Customer or agent ID doesn't exist; ensure import sequence order |
| 409 | Conflict / duplicate | Conversation with this external ID already exists; skip or update |
| 413 | Payload too large | Attachment exceeds size limit; compress or split before retry |
| 422 | Unprocessable entity | Field value fails validation; check enum values and field types |
| 492 | Rate limit exceeded | Read `Retry-After` header; pause and retry with exponential backoff |
| 500 | Server error | Log and retry after 30s; escalate to Richpanel support if persistent |

Always log the full request payload alongside the response for any non-2xx status. You will need this for debugging and for support escalation.

### Preserving Timestamps and Authorship

When POSTing to Richpanel, explicitly set the original timestamps:

- Pass the original LiveAgent ticket creation date to Richpanel's `created_at` field.
- Pass the original message timestamps to each message payload.

For agent mapping, convert LiveAgent `userid` values to the corresponding Richpanel agent IDs. If a LiveAgent agent no longer exists at your company and won't have a Richpanel seat, map their historical tickets to a generic "Former Employee" placeholder account to preserve data integrity without leaving unassigned conversations.

> [!NOTE]
> **Timestamp field writability:** Verify whether Richpanel's `created_at` field is writable or system-generated for your specific API version. If system-generated, migrated conversations will carry the import date instead of the original date — a common failure mode across helpdesk migrations. Test this with a single record before running the full import.

## Status Mapping: 10 States to 3

This is where most migration plans break down. LiveAgent has **10 ticket statuses**. Richpanel uses a simpler conversation model.

### LiveAgent Ticket Statuses (Complete List)

| Status | Description |
|---|---|
| **New** | Newly created from email, contact form, social media, unanswered call, or missed chat |
| **Answered** | Replied by an agent, or post-chat/call (configurable) |
| **Open** | Customer replied to an answered, postponed, or resolved ticket |
| **Postponed** | Manually postponed; reverts to Open (or New) when time elapses |
| **Resolved** | Agent resolved manually, or post-chat/call (configurable) |
| **Closed** | Permanently closed; no further actions allowed except tag/custom field edits |
| **Deleted** | Manually deleted or auto-deleted from missed chats |
| **Spam** | Marked as spam manually or by SpamAssassin |
| **Chatting** | Active live chat in progress |
| **Calling** | Active phone call in progress |

### Recommended Status Mapping

| LiveAgent Status | Richpanel Status | Rationale |
|---|---|---|
| New | Open | Unhandled ticket → open conversation |
| Answered | Open | Still active unless explicitly resolved |
| Open | Open | Customer replied → active conversation |
| Postponed | Snoozed | Waiting on timer or follow-up |
| Resolved | Resolved | Direct map |
| Closed | Resolved | Richpanel doesn't distinguish closed vs. resolved for historical data |
| Deleted | **Do not migrate** | Exclude from extraction scope |
| Spam | **Do not migrate** | Exclude from extraction scope |
| Chatting | Open | Active session → open conversation |
| Calling | Open | Active session → open conversation |

Preserve the original LiveAgent status in a custom field (e.g., `original_la_status`) on each Richpanel conversation. This enables post-migration filtering and reporting on the original status granularity without forcing it into Richpanel's simpler model.

> [!NOTE]
> **Should you migrate Deleted and Spam tickets?** In most migrations, no. They inflate your Richpanel conversation count, pollute analytics, and carry no operational value. Apply a status exclusion filter during extraction: `_filters=[["status","N!=","D"], ["status","N!=","SP"]]`

## Edge Cases and Failure Modes

### Merged and Split Tickets

LiveAgent supports ticket merging and splitting. Merged tickets create a parent-child relationship that doesn't exist in Richpanel.

- **Merged Tickets:** LiveAgent's API typically outputs merged tickets as a single thread, but the metadata may reference old, deprecated ticket IDs. Extract only the final surviving ticket ID to avoid duplicating data in Richpanel.
- **Split Tickets:** These appear as two distinct tickets in LiveAgent. The split ticket often lacks the initial customer context. Verify that chronological order makes sense when injected into Richpanel, and tag both resulting conversations with a shared `split-from-[original-ticket-id]` tag for traceability.

### Multi-Brand LiveAgent Setups

If you use LiveAgent's multi-knowledge-base feature with separate customer portals per brand, each brand's data needs to route to the correct Richpanel `appClientId`. Mixing brand data into a single `appClientId` will contaminate your analytics and AI training data. Build your extraction manifest with a `brand_identifier` column and enforce routing at the injection layer, not as a post-import cleanup task.

### Chat and Call Transcripts

LiveAgent stores chat transcripts and call metadata as ticket messages. When these migrate to Richpanel, they become regular conversation messages. The original channel context ("this was a live chat" vs. "this was a phone call") is lost unless you tag conversations with their source channel during migration. Use a `source_channel` custom field populated from the LiveAgent ticket's `channel_type` attribute.

### Channel Parity Gaps

LiveAgent supports channels that Richpanel may not natively match. LiveAgent's channel list includes phone, WhatsApp, Viber, and Telegram. Richpanel's native channels include email, Facebook, Instagram, WhatsApp, SMS, and certain phone providers (Aircall, Dialpad, JustCall) as third-party integrations.

If your LiveAgent history includes Viber, Telegram, or a custom telephony flow, decide upfront whether those records should land as generic email-channel conversations with a `source_channel` tag, or remain searchable only in the archived LiveAgent instance. Document this decision before extraction begins.

### Richpanel Webhook vs. Polling During Delta Sync

The delta sync phase assumes polling LiveAgent for tickets created or modified after the cutover timestamp. Richpanel supports inbound webhooks for real-time event ingestion, but these apply to new conversations created in Richpanel — they do not help with ingesting historical data. For the delta catch-up window, use the LiveAgent API with a `date_modified` filter rather than relying on webhooks. Set the filter to the exact timestamp your historical load completed, not your planned cutover time, to avoid gaps.

## What Doesn't Transfer

No API migration can move platform-specific configurations. You must manually rebuild the following in Richpanel:

- **Automation Rules and Time Rules** — LiveAgent's rule engine (conditions + actions) must be rebuilt using Richpanel's automation features. Fully document every rule before starting migration; LiveAgent exports rules as readable summaries in the admin panel.
- **SLA Configurations** — LiveAgent SLA rules are tied to departments and priorities. Richpanel handles SLAs differently. Redesign from scratch rather than trying to replicate the exact structure.
- **Canned Messages / Predefined Answers** — Must be recreated as Richpanel macros. In Richpanel, macros can be enhanced with AI SOPs that add dynamic order context to templated responses.
- **Knowledge Base Articles** — LiveAgent KB articles (including internal articles, forums, and feedback boards) must be recreated in Richpanel's Help Center. Export content as HTML or Markdown, then reformat for Richpanel's editor.
- **Chat Widget Settings** — LiveAgent's chat widgets, animations, and button styles don't transfer. Replace with Richpanel's widget snippet.
- **Call Recordings** — LiveAgent stores call recordings tied to tickets. Richpanel does not natively import call recordings from external platforms. Archive these separately in cloud storage and link to conversations via a custom field URL reference if auditability is required.
- **IVR Trees** — LiveAgent's built-in call center IVR configurations are platform-specific and non-transferable.
- **Contact Groups** — LiveAgent groups contacts into segments. Richpanel doesn't have an equivalent grouping mechanism — use tags or custom properties instead.

> [!NOTE]
> **Richpanel's migration wizard does not list LiveAgent** as a named supported source. Richpanel's documentation names Zendesk, Gorgias, Help Scout, and Kustomer. If your source platform is not listed, assume a custom API migration path and confirm the approach directly with Richpanel before starting technical work.

## Step-by-Step Migration Plan

### Phase 1: Audit and Scope (Days 1–3)

- Export LiveAgent ticket counts by status, department, and date range
- Identify which tickets to migrate (active only? last 12 months? all time?)
- Map LiveAgent Departments to Richpanel Teams
- Map custom fields and verify type compatibility
- Document all automation rules, SLAs, and canned messages
- Identify multi-brand routing needs and confirm `appClientId` per brand
- Confirm Richpanel API access level and message history entitlement for your plan
- Identify tickets with Viber, Telegram, or custom telephony channels and decide handling

### Phase 2: Build Extraction Scripts (Days 3–5)

- Write API extraction scripts for tickets, messages, contacts, companies, tags
- Shard extraction by date range to stay under the 10,000-ticket per-filter limit
- Handle pagination: `_cursor` for `GET /tickets/history`, `_page` for standard ticket list
- Add rate-limit handling at 180 RPM with exponential backoff on 429
- Include `Timezone-Offset` headers on all requests
- Handle both pre-5.62 and post-5.62 internal note formats
- Use `download_url` (not `downloadUrl`) for attachment extraction from version 5.25 onward
- Test on a small batch (100–500 tickets) before full run

### Phase 3: Transform Data (Days 5–7)

- Map LiveAgent's 10 ticket statuses to Richpanel's 3 conversation statuses per the table above
- Flatten Company data into Customer custom properties
- Map Department IDs to Richpanel Team IDs
- Convert LiveAgent agent `userid` values to Richpanel agent references; create "Former Employee" placeholder for departed agents
- Download attachments and stage in temporary S3 storage
- Tag conversations with source channel (email, chat, call, social) using `source_channel` custom field
- Store original LiveAgent ticket ID in `liveagent_ticket_id` custom field on every conversation
- Normalize all timestamps to UTC
- Build the local manifest: `liveagent_ticket_id` → expected Richpanel conversation ID

### Phase 4: Sandbox Validation (Days 7–9)

Inject a sample of 500 tickets spanning different departments, statuses, attachment types, and channels into a Richpanel sandbox environment.

Verify:
- HTML formatting of email bodies survived
- Attachments are clickable and downloadable
- Customer email correctly links to the Shopify/Magento/WooCommerce profile
- Timestamps are accurate (not set to import date)
- Internal notes are visible with correct agent-only permissions
- Tags and custom fields populated correctly
- `liveagent_ticket_id` custom field present on all records
- Conversations tagged `unmatched-order-profile` are logged and reviewable

### Phase 5: Historical Load (Days 9–14)

- Create Customers in Richpanel (match to e-commerce platform; handle mismatches per the fallback procedure above)
- Create Tags
- Create Conversations with original timestamps, linked to customers and teams
- Add Messages in chronological order
- Upload and link Attachments
- Monitor `X-RateLimit-Remaining` on every response; back off when remaining < 10
- Log every non-2xx response with the full request payload for retry
- Use a queueing system with exponential backoff; do not use a synchronous for loop
- Update the local manifest with confirmed `richpanel_conversation_id` for each created record

### Phase 6: Delta Sync and Cutover (Days 14–17)

Because a large migration can take 30+ hours of API execution, you cannot freeze support operations. Use a **delta migration** approach:

1. **Historical Load:** Extract and inject all LiveAgent tickets up to a specific cutover timestamp (e.g., Friday 11:59 PM). Your team continues working in LiveAgent during this period.
2. **DNS Cutover:** Switch email forwarding, chat widget DNS, and social integrations to point to Richpanel.
3. **Delta Catch-up:** Query LiveAgent for tickets created or modified after the historical cutover timestamp using `date_modified` as the filter key. Run deduplication check against your local manifest before injecting. Inject the delta batch into Richpanel.

By Monday morning, agents log into Richpanel with all historical data present and weekend activity caught up.

Keep your current LiveAgent instance live in read-only mode until the Richpanel setup is fully verified.

For more on zero-downtime cutover strategies, see our guide on [Zero-Downtime Help Desk Data Migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/).

### Phase 7: QA and Decommission (Days 17–20+)

- **Count comparison:** Run a query against your local manifest. Total extracted LiveAgent tickets (excluding Deleted and Spam) should equal total created Richpanel conversations. Any gap means records were dropped — investigate before proceeding.
- Sample 5–10% of migrated conversations across status types and verify completeness
- Spot-check tickets with heavy PDF or image attachments
- Verify open tickets are assigned to the correct active agents
- Verify all `unmatched-order-profile` tagged conversations have been resolved or accepted as-is
- Confirm no records appear in Richpanel twice (deduplication check on `liveagent_ticket_id` custom field)

In parallel:
- Recreate automation rules in Richpanel
- Rebuild canned messages as Richpanel macros
- Recreate knowledge base articles in Richpanel's Help Center
- Configure Richpanel chat widget and channels
- Confirm Shopify/WooCommerce store integration is active and syncing

Keep LiveAgent in read-only state for at least 30 days before decommissioning. Do not delete the LiveAgent instance until the count comparison and QA sampling pass.

## Timeline and Complexity Estimates

| Scenario | Ticket Volume | Estimated Timeline |
|---|---|---|
| Small / simple | < 5,000 tickets, few custom fields | 1–2 weeks |
| Mid-size | 5,000–25,000 tickets, moderate customization | 2–3 weeks |
| Large | 25,000–100,000 tickets, multi-brand, heavy attachments | 3–5 weeks |
| Enterprise | 100,000+ tickets, complex custom fields, call recordings | 5–8 weeks |

These timelines assume a dedicated engineering resource. The primary constraint at scale is Richpanel's 100 RPM API limit, which drives 33+ hours of import execution for 50K tickets. Managed migration services (from either Richpanel or a migration partner) may use elevated rate limits that compress these timelines.

## When Richpanel Is Not the Right Destination

Richpanel is purpose-built for e-commerce. If your use case doesn't fit that model, reconsider the destination:

- **B2B / SaaS support** — Richpanel lacks native company-level organization and multi-tier account structures. Consider [migrating to Zendesk](https://clonepartner.com/blog/blog/how-to-migrate-from-liveagent-to-zendesk-the-complete-guide/), [Freshservice](https://clonepartner.com/blog/blog/liveagent-to-freshservice-migration-a-technical-guide/), or [Unthread](https://clonepartner.com/blog/blog/liveagent-to-unthread-migration-a-technical-guide/) instead.
- **IT service management** — No ITIL alignment, no asset management, no change management workflows.
- **Call-center-heavy operations** — LiveAgent's built-in VoIP and IVR are more mature than Richpanel's third-party voice integrations (Aircall, Dialpad, JustCall). If voice is a primary channel, evaluate Richpanel's telephony depth before committing.
- **Budget-constrained small teams** — Richpanel's pricing is positioned for growth-stage and enterprise e-commerce. LiveAgent starts at $15/agent/month. Verify Richpanel's current pricing for your team size before using cost as a migration justification.

## Making the Call

A LiveAgent to Richpanel migration is a platform architecture change, not a data copy. You're moving from a department-routed ticket queue to an order-aware, AI-assisted conversation platform. The data migration itself is moderate complexity — two rate-limited APIs, a 10-to-3 status model collapse, no bulk import path, and a set of version-specific extraction edge cases. The harder work is rebuilding automations, retraining agent workflows, and connecting your e-commerce stack correctly.

The migration is technically well-defined if you follow the extraction order, implement deduplication from the start, handle contact-matching failures explicitly, and monitor rate limits on both sides. The failure modes that cause migrations to go wrong — silently truncated exports, inline image loss, timestamp drift, and unmatched customer profiles — are all avoidable with the preparation steps above.

If your team is primarily supporting D2C e-commerce customers and wants AI-assisted resolution tied to order context, Richpanel is a technically coherent destination. If your support is general-purpose, B2B, or call-center-heavy, the architectural mismatch will create more friction than the migration solves.

For a broader view of migration targets from LiveAgent, see our guides on [LiveAgent to Zendesk](https://clonepartner.com/blog/blog/how-to-migrate-from-liveagent-to-zendesk-the-complete-guide/), [LiveAgent to Freshservice](https://clonepartner.com/blog/blog/liveagent-to-freshservice-migration-a-technical-guide/), [LiveAgent to Intercom](https://clonepartner.com/blog/blog/liveagent-to-intercom-migration-the-technical-guide/), and [LiveAgent to Unthread](https://clonepartner.com/blog/blog/liveagent-to-unthread-migration-a-technical-guide/).

> Migrating from LiveAgent to Richpanel and want to get it right the first time? ClonePartner specializes in helpdesk data migrations. We handle the API extraction, data transformation, status mapping, deduplication, and validation — so your team can keep supporting customers while we move the data. Book a 30-minute technical scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### Can I use LiveAgent's CSV export to migrate to Richpanel?

No. LiveAgent's CSV export captures ticket metadata (ID, subject, status, tags) but not full message threads, internal notes, or attachments. You must use the LiveAgent API v3 GET /tickets/{ticketId}/messages endpoint to extract complete conversation history for migration.

### What are the API rate limits for LiveAgent and Richpanel?

LiveAgent's API v3 is rate-limited to 180 requests per minute per API key. Richpanel's API allows 100 calls per minute and returns a 492 status code when exceeded. Both APIs include rate-limit headers in responses. For large migrations (50K+ records), contact Richpanel at tech@richpanel.com to request a temporary rate limit increase.

### How long does a LiveAgent to Richpanel migration take?

For under 5,000 tickets with simple custom fields, expect 1–2 weeks. Mid-size migrations (5K–25K tickets) take 2–3 weeks. Large or multi-brand migrations with heavy attachments can take 3–5 weeks. Most time is spent rebuilding automations, not transferring data.

### Do LiveAgent automation rules transfer to Richpanel?

No. Automation rules, SLA configurations, time rules, canned messages, and predefined answers cannot be migrated programmatically. They must be documented in LiveAgent and manually recreated in Richpanel. Macros can be rebuilt as Richpanel AI SOPs.

### Do I need Richpanel Enterprise for an API-based migration?

Richpanel's API reference states that Developer API Access is Enterprise-only, though public pricing pages also mention API Access and a Help Desk Importer on other plans. Confirm your actual workspace entitlement with Richpanel before planning an API-led migration.