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.
Migrating from LiveAgent to Richpanel is a structural platform shift, not a like-for-like vendor swap: LiveAgent is a general-purpose, department-centric ticketing system while Richpanel is an e-commerce-native platform that organizes support around orders and transactions. No native migration path exists between the two platforms; a complete migration requires custom extraction scripts using LiveAgent API v3, a transformation layer to remap data models, and programmatic injection into Richpanel's REST API. LiveAgent's built-in CSV export captures only ticket metadata and omits full message threads, internal notes, and attachments, making API-based extraction mandatory. Key custom work includes sharding extractions to bypass the 10,000-ticket filter cap, collapsing LiveAgent's 10 ticket statuses into Richpanel's simplified Open/Resolved/Snoozed model, stitching historical tickets to e-commerce customer records, and manually rebuilding automation rules, SLAs, canned messages, and knowledge base articles which cannot be migrated programmatically.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
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 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.
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.
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.
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.
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.
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"]]
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.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of LiveAgent
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Richpanel can hold your support model
Walk your current workflow through Richpanel: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated LiveAgent → Richpanel timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
LiveAgent → Richpanel specifics
- 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.
- 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.
- 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.
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full LiveAgent export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the LiveAgent export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in LiveAgent where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass LiveAgent → Richpanel field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the LiveAgent → Richpanel field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Richpanel has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Richpanel sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Richpanel sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Richpanel's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Richpanel, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while LiveAgent stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Richpanel's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze LiveAgent and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep LiveAgent read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
LiveAgent → Richpanel specifics
- 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.
- DNS Cutover
- Switch email forwarding, chat widget DNS, and social integrations to point to Richpanel.
- 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.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile LiveAgent and Richpanel record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Richpanel, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep LiveAgent read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
LiveAgent Richpanel
| LiveAgent field | Richpanel field | 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. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets / Conversations | medium | A 1:1 mapping exists between LiveAgent tickets and Richpanel conversations, but the 10,000-ticket per filter extraction cap and the need to shard by date range introduce a meaningful risk of silent data truncation if extraction scripts are not properly implemented. |
| Message Threads | high | Full message threads are entirely absent from LiveAgent's CSV export and require individual API calls to GET /tickets/{ticketId}/messages per ticket, making message completeness entirely dependent on extraction script reliability and rate limit handling. |
| Internal Notes | high | Internal notes are at high risk of silent loss due to a breaking change in note storage format introduced in LiveAgent version 5.62, requiring version-aware extraction logic to capture both legacy and current note structures. |
| Attachments | high | Attachments require per-message parsing, staged re-upload to temporary storage, and re-injection into Richpanel, with additional risk from deprecated downloadUrl fields, S3-backed storage for older tickets, and potential 413 errors near the 25 MB size boundary. |
| Inline Images | high | Inline images are explicitly excluded from LiveAgent's HTML export for security reasons and must be extracted via the API message endpoint and re-uploaded as discrete attachments, making them easy to miss and difficult to remediate after migration completes. |
| Contacts / Customers | medium | Contact records map to Richpanel customers with reasonable fidelity, but exact email matching against e-commerce platform records is critical; any mismatch breaks the order-linkage that is Richpanel's core value proposition. |
| Companies | high | Richpanel has no native company or organization object, so all LiveAgent company-level data must be flattened into customer-level custom fields or tags, representing a structural data loss for any workflow that relies on company-level support views. |
| Tags | low | Tags transfer directly between platforms, though Richpanel automatically sanitizes all tag names into lowercase hyphenated format, which may cause minor display discrepancies but does not result in data loss. |
| Custom Fields | medium | Ticket-level custom fields and contact-level custom fields both have target objects in Richpanel, but field type compatibility must be verified before import as incompatible types will cause import failures or silent data truncation. |
| Automation Rules / SLAs / Canned Messages | high | None of these configuration objects can be migrated programmatically; all automation rules, SLA policies, and canned messages must be manually rebuilt in Richpanel, and knowledge base articles require either manual recreation or a custom content extraction and reformatting script. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
API Rate Limit Bottlenecks
LiveAgent enforces a 180-requests-per-minute API cap per key while Richpanel enforces a 100-calls-per-minute import limit, meaning a 20,000-ticket migration requires approximately 40,000 API calls and roughly 3.7 hours of pure extraction time before any transformation or loading begins.
Ticket Volume Extraction Sharding
Since LiveAgent version 5.51, the GET /tickets endpoint silently truncates results above 10,000 records per filter, requiring extraction scripts to shard all requests by date range using date_created filters to ensure complete data retrieval.
Status Model Collapse
LiveAgent's 10 distinct ticket statuses must be mapped and collapsed into Richpanel's three-state model of Open, Resolved, and Snoozed, requiring a deliberate transformation decision for each intermediate status that has no direct equivalent.
E-commerce Record Stitching
LiveAgent tickets carry no native order linkage, so the transformation layer must match every migrated conversation to the correct Shopify, WooCommerce, or Magento customer record in Richpanel using exact email matching, or the core value of the platform is lost.
Internal Note Version Discrepancy
From LiveAgent version 5.62 onward, internal notes can be stored under message type M with a different group type than earlier versions, meaning extractors must handle both pre- and post-5.62 note patterns or silently lose internal note history.
Non-Migratable Configuration Objects
Automation rules, SLA policies, canned messages, and knowledge base articles have no programmatic migration path into Richpanel and must be fully rebuilt manually, representing significant post-migration configuration effort outside the data pipeline.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
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.