LiveChat to SurveySparrow Ticket Management Migration Guide

Migrating from LiveChat to SurveySparrow Ticket Management means translating a conversation-centric chat platform into a feedback-first ticket system. LiveChat stores data as chats composed of threads and events — messages, files, system actions — organized by agents, groups, and customers. SurveySparrow's Ticket Management is built around a simpler schema: tickets with subject, description, priority, status, assignee, and comments, typically generated from survey responses, NPS detractors, or form submissions.

There is no native migration path between these two platforms. No built-in importer exists on either side, and no third-party migration tool currently offers a verified, pre-built LiveChat-to-SurveySparrow connector. Every migration requires extracting data via LiveChat's Agent Chat API (v3.5), transforming it to match SurveySparrow's ticket and contact schema, and loading it through SurveySparrow's REST API (v3). (platform.text.com)

This guide covers the full technical path: API constraints on both sides, object-level and field-level mapping, every viable migration method, architecture decisions, and the edge cases that cause silent data loss.

If you're evaluating SurveySparrow's ticketing against other platforms, our SurveySparrow Ticket Management to Front Migration Guide covers the reverse direction and highlights SurveySparrow's data model constraints in detail.

LiveChat vs SurveySparrow Ticket Management: Architecture Differences

Before mapping fields, understand how these two data models differ.

LiveChat (by Text, Inc.) is a real-time messaging platform. Its data model is built around:

• Chats — top-level containers that persist across sessions
• Threads — individual conversation sessions within a chat
• Events — messages, files, filled forms, system events within each thread
• Customers — visitor profiles with email, name, custom properties
• Agents — support staff organized into Groups
• Tags — chat-level labels for categorization

SurveySparrow Ticket Management is a feedback-loop closer. Its data model includes:

• Tickets — subject, description, priority, status, source (usually a survey response)
• Contacts — email, full name, phone, job title, contact type
• Ticket Comments — internal notes and updates on tickets
• Ticket Fields — custom fields attached to tickets
• Users — internal team members (agents/assignees)

The core translation problem: LiveChat's threaded chat conversations (potentially dozens of messages per session across multiple threads) must be flattened into SurveySparrow's ticket + description + comments structure. There is no 1:1 mapping for chat transcripts.

Decide early whether the target unit is one ticket per chat, one ticket per thread, or one ticket per business issue. This choice controls deduplication, subject generation, and comment structure for the entire migration.

Why Companies Migrate from LiveChat to SurveySparrow

Teams typically make this move for specific operational reasons:

• Unified feedback and support. SurveySparrow ties customer complaints directly to survey data — NPS scores, CSAT ratings — in one platform instead of correlating across two separate tools. Teams can auto-create tickets from low NPS scores (e.g., detractor responses ≤ 6) and route them to the same agents handling existing cases.
• Workflow consolidation. Organizations already using SurveySparrow for surveys want tickets auto-created from low scores rather than maintaining a separate LiveChat instance with its own agent roster and routing rules.
• Cost reduction. Running a dedicated chat platform alongside a survey tool creates overlapping per-agent costs. SurveySparrow's ticket management is included in Business and Enterprise plans, eliminating the separate LiveChat per-agent fee.
• Simpler support needs. Teams that handle fewer than 500 conversations per month and prefer async ticket-based workflows find SurveySparrow's lighter model sufficient.

Migration Approaches: Every Viable Method

Decision Tree: Choosing Your Migration Method

Use this decision tree to select the right approach:

1. Is the total chat count under 1,000 and you don't need full transcript fidelity? → Method 1 (CSV Export + API Load)
2. Do you have development resources (Python/Node.js) and 1,000–50,000 chats? → Method 2 (API-to-API)
3. No dev resources and a third-party vendor confirms SurveySparrow Ticket Management as a supported destination in writing? → Method 3 (Third-Party Tool)
4. More than 50,000 chats, complex transformations, multi-brand consolidation, or need audit trails? → Method 4 (Custom ETL Pipeline)
5. Already completed historical migration and need forward-looking sync during phased rollout? → Method 5 (Middleware)

Method 1: CSV Export from LiveChat → Manual Import

How it works: Use LiveChat's marketplace apps (like Chats Transcripts Exporter) to export chat history to CSV or JSON files. Normalize the data in a script or spreadsheet, import contacts via SurveySparrow's CSV contact import, and feed ticket data through the API.

When to use it: Small datasets under 1,000 chats where preserving every message isn't critical. Also useful for pre-loading contacts before an API-based migration.

Limitations: LiveChat's Chats raw-data export is limited to the latest 100,000 records unless you slice by date. SurveySparrow can import contacts from CSV, but the public Ticket Management docs do not document a ticket CSV import wizard — you still need the API for loading tickets. (livechat.com)

Complexity: Low | Scalability: Small datasets only | Data integrity: Low — destroys relational data, flattens transcripts, loses attachments

Method 2: API-to-API Migration (LiveChat v3.5 → SurveySparrow v3)

How it works: Extract data using LiveChat's Agent Chat API (list_archives, list_customers, agent/group configuration endpoints). Transform the data in a middleware layer. Load into SurveySparrow using the Tickets API (POST /v3/tickets or batch endpoint POST /v3/tickets/batch), Contacts API, and Ticket Comments API. (platform.text.com)

When to use it: Any migration between 1,000 and 50,000 records, or when you need to preserve chat content as ticket descriptions and comments with contact relationships intact.

Pros:

• Full control over data transformation logic
• Can preserve chat transcripts as structured ticket descriptions and comments
• Handles contact deduplication programmatically
• Supports incremental migration and validation

Cons:

• Requires development time (estimate 40–80 hours for a mid-complexity migration)
• Must handle rate limits on both sides
• LiveChat's list_archives defaults to 10 records per page with a max of 100 — pagination required for large datasets

Complexity: Medium–High | Scalability: Enterprise-ready with proper batching

Method 3: Third-Party Migration Tools

How it works: SaaS platforms that map fields and execute API calls on your behalf.

When to use it: Mid-sized migrations with standard data models and no custom objects, if the vendor confirms SurveySparrow Ticket Management as a supported destination.

Critical caveat: Public materials from tools like Help Desk Migration confirm LiveChat source support, but a first-class SurveySparrow Ticket Management destination connector could not be verified from public documentation as of June 2025. Treat these tools as source-side accelerators unless the vendor confirms the exact target mapping in writing. (help-desk-migration.com)

Complexity: Low–Medium | Scalability: Small to medium | Risks: Black-box transforms, silent data corruption on edge cases, and you may still need to build the target load yourself

Method 4: Custom ETL Pipeline

How it works: Build a dedicated Extract-Transform-Load pipeline using Python + Pandas, Node.js, or a data pipeline framework (Airflow, Dagster). Extract from LiveChat API, transform in a staging database (PostgreSQL or SQLite), load into SurveySparrow API.

When to use it: Large migrations (50,000+ chats), complex transformation requirements, multi-brand consolidations, or when you need audit trails and idempotent retry logic.

Pros:

• Full control over every step
• Can implement deduplication, validation, and rollback
• Supports staging environments and dry runs
• Enables idempotent reruns via source-to-target ID mapping table

Cons:

• Highest engineering investment (estimate 80–160 hours)
• Must build monitoring, logging, and error handling from scratch
• Risk of over-engineering a one-time data movement

Complexity: High | Scalability: Enterprise-grade

Method 5: Middleware (Zapier, Make, Pipedream)

How it works: Trigger-based synchronization between the two platforms. Zapier's LiveChat + SurveySparrow integration is trigger/action oriented. Pipedream has pre-built SurveySparrow components for contact creation and survey triggers.

When to use it: Ongoing delta sync during a phased rollout, not for historical bulk migrations.

Limitations: Per-task pricing makes large-volume migrations expensive (Zapier charges per task; 10,000 chats × ~5 tasks each = 50,000 tasks). Limited transformation logic — can't flatten multi-message threads into structured ticket descriptions. Make's published SurveySparrow app docs focus on survey/contact modules plus a generic API call; verify ticket operations before committing. SurveySparrow webhooks cap each unique event payload at 5,000 deliveries per day per webhook. (zapier.com)

Complexity: Low | Scalability: New data only; not for historical backfill

Migration Approach Comparison

Scenario guidance:

• Small business (<5,000 chats): API-based migration. Use CSV only if archive-quality data is acceptable.
• Mid-market (5,000–50,000 chats): API-to-API with date-windowed extraction. Expect 2–5 days of development plus 1–3 days of execution.
• Enterprise (>50,000 chats): Custom ETL pipeline. Use date windows because LiveChat's raw Chats export caps at 100,000 records. At 60 requests/minute to SurveySparrow, a 100,000-ticket migration takes approximately 28 hours of continuous API loading (excluding comments). (livechat.com)
• Ongoing sync: Middleware after the historical load finishes. Shut it off immediately post-cutover.

When to Use a Managed Migration Service

Build in-house when you have a dedicated engineer with API experience, the dataset is straightforward (under 5,000 records, standard fields), and your timeline is flexible.

Consider external help when:

• The data model gap is large. LiveChat's threaded conversation model doesn't map cleanly to SurveySparrow's flat ticket structure. Flattening logic is where most DIY migrations introduce data loss — specifically, losing speaker attribution, timestamp ordering, and thread boundaries.
• Custom fields and relationships are involved. LiveChat chat properties, pre-chat survey data, and customer custom variables all need manual mapping. Each custom property requires pre-creation in SurveySparrow before any data loads.
• You can't afford extended downtime. A botched migration means agents can't reference historical conversations. That's a support continuity risk.
• Engineering time costs more than the migration. Two weeks of a senior engineer's time on migration scripting often exceeds the cost of a managed service. The cost isn't only developer time — Text charges for private API usage, so repeated extraction runs and failed load tests can create direct platform cost. (platform.text.com)

Pre-Migration Planning Checklist

Before writing any code or engaging a provider, complete this audit.

Data Inventory

• Chat archives: Total count, date range, average messages per chat (obtain from LiveChat's Reports → Chats section)
• Customers: Count, fields used (email, name, custom properties)
• Agents: Count, group assignments, roles
• Tags: Full list, usage frequency (export via list_archives and aggregate)
• Pre-chat survey data: Fields collected, format
• Post-chat survey data: Ratings, comments
• File attachments: Count, total size, file types (note: SurveySparrow comments support PDF, PNG, JPEG, MP3, CSV, WAV up to 15 MB)
• Custom properties: Chat-level and customer-level properties (list all keys)

Scope Decisions

• Which date range of chats to migrate? (All history vs. last 12 months)
• Which chat statuses? (All vs. only chats that resulted in tickets)
• Migrate agent data as SurveySparrow users, or map to existing users?
• Migrate file attachments or just text content?
• Migrate tags as custom ticket fields or drop them?
• Does satisfaction/rating history belong in ticket custom fields, or as a separate SurveySparrow survey import?
• One ticket per chat, one ticket per thread, or one ticket per business issue?

Cutover Strategy

• Big bang: Migrate everything in one cutover window. Fastest, but highest risk. Suitable when total migration execution time is under 8 hours.
• Phased: Migrate by date range or group. Reduces risk but extends timeline. Recommended for datasets spanning multiple years.
• Incremental: Migrate historical data first, then sync new data via middleware until cutover. Best for large datasets with ongoing operations that can't pause.

Data Model and Object Mapping

This is where migrations succeed or fail. The mapping below reflects the architectural mismatch between the two platforms.

Object-Level Mapping

Field-Level Mapping: Contacts

Field-Level Mapping: Chats → Tickets

Migration Architecture

Data Flow

LiveChat API (v3.5)          Staging Layer           SurveySparrow API (v3)
┌─────────────────┐     ┌──────────────────┐     ┌─────────────────────┐
│ list_archives   │────▶│ Transform &      │────▶│ POST /v3/contacts   │
│ list_customers  │     │ Validate         │     │ POST /v3/tickets    │
│ list_threads    │     │ (JSON/DB staging) │     │ POST /v3/tickets/   │
│ agent configs   │     │                  │     │   batch             │
│ (webhooks for   │     │ Dedup by chat.id │     │ POST /v3/tickets/   │
│  ongoing sync)  │     │ ID mapping table │     │   {id}/comments     │
└─────────────────┘     └──────────────────┘     └─────────────────────┘

LiveChat API: Extraction Details

Base URL: https://api.livechatinc.com/v3.5/agent/action/

Authentication: OAuth 2.1 with Personal Access Tokens (PAT). Generate in Developer Console → Tools → Personal Access Tokens. Required scopes: chats--all:ro, chats--access:ro, customers--all:ro, agents--all:ro. (platform.text.com)

Key endpoints:

• POST /list_archives — Returns closed chats with threads and events. Defaults to 10 records per page, max 100 per request. Returns next_page_id for cursor-based pagination.
• POST /list_threads — Returns threads for a specific chat. Defaults to 3, max 100.
• POST /list_customers — Returns customer profiles with custom properties.
• GET /agents — Returns agent list with group assignments.

Rate limits: 1,000 requests per 10-minute window per license, shared across all tokens and integrations. Monitor via X-RateLimit-Remaining and Retry-After headers. If other integrations (chatbots, analytics tools) are running against the same account during extraction, you'll compete for the same quota. Schedule extraction during low-traffic periods (nights/weekends).

Webhook alternative for ongoing sync: For phased migrations needing near-real-time extraction of new chats during the transition period, LiveChat supports push webhooks (chat_deactivated, incoming_event). Register via the Configuration API. This avoids polling list_archives repeatedly. (platform.text.com)

SurveySparrow API: Loading Details

Base URL: https://api.surveysparrow.com/v3/ (varies by data center — US, EU, AP. Confirm your data center in Settings → Account Details or with SurveySparrow support.)

Authentication: OAuth 2.0 or Bearer token. Generate access token via Settings → Apps & Integrations → Custom Apps. Required permissions: Ticket (Read/Write), Contact (Read/Write), Ticket Comment (Read/Write).

Key endpoints:

• POST /v3/contacts — Create a contact. Required field: email. Optional: full_name, phone, job_title, contact_type.
• POST /v3/tickets — Create a single ticket. Returns 201 Created with the ticket object including id.
• POST /v3/tickets/batch — Create tickets in batch. Returns 202 Accepted plus a status token. Maximum batch size is not explicitly documented; test with batches of 50 and scale up.
• GET /v3/tickets/batch/status/{token} — Check batch creation status. Poll until status is completed or failed.
• POST /v3/tickets/{id}/comments — Add comments to a specific ticket (for chat transcript messages). Supports body (text), private (boolean), and file attachments.

Rate limits: Not publicly documented with exact numbers per plan tier. Empirical testing suggests starting with conservative throttling at 60 requests per minute (1 request/second). Monitor for 429 Too Many Requests responses and implement exponential backoff. If you observe consistent 429s, reduce to 30 requests/minute and contact SurveySparrow support for your plan's specific limits. (developers.surveysparrow.com)

Common error responses:

• 422 Unprocessable Entity — Typically returned when required fields are missing (e.g., email on contacts, subject on tickets) or when a custom field internal_name doesn't exist. Response body includes { "error": "validation_error", "message": "..." }.
• 409 Conflict — Returned on duplicate contact creation (same email). Handle by fetching the existing contact ID and proceeding.
• 401 Unauthorized — Token expired or insufficient permissions.

Step-by-Step Migration Process

Step 1: Extract Data from LiveChat

Use date windows for extraction so reruns stay small and the 100,000-record raw export ceiling doesn't block you.

import requests
import time
import json
from datetime import datetime
 
LIVECHAT_BASE = "https://api.livechatinc.com/v3.5/agent/action"
HEADERS = {
    "Authorization": "Bearer <YOUR_PAT>",
    "Content-Type": "application/json"
}
 
def extract_archives(date_from, date_to, limit=100):
    """
    Extract closed chats from LiveChat within a date window.
    Returns deduplicated chats (by chat.id).
    """
    all_chats = []
    seen_chat_ids = set()
    page_id = None
    request_count = 0
    
    while True:
        payload = {
            "filters": {"from": date_from, "to": date_to},
            "limit": limit
        }
        if page_id:
            payload["page_id"] = page_id
        
        resp = requests.post(
            f"{LIVECHAT_BASE}/list_archives",
            headers=HEADERS, json=payload
        )
        request_count += 1
        
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            print(f"Rate limited. Waiting {retry_after}s...")
            time.sleep(retry_after)
            continue
        
        if resp.status_code != 200:
            print(f"Error {resp.status_code}: {resp.text}")
            break
            
        data = resp.json()
        chats = data.get("chats", [])
        
        for chat in chats:
            chat_id = chat.get("id")
            if chat_id not in seen_chat_ids:
                seen_chat_ids.add(chat_id)
                all_chats.append(chat)
        
        page_id = data.get("next_page_id")
        if not page_id:
            break
        
        # Stay under rate limits: 1000 req / 10 min = ~1.67 req/sec
        time.sleep(0.7)
    
    print(f"Extracted {len(all_chats)} unique chats from {request_count} API calls")
    return all_chats

Critical: list_archives returns thread-level rows. The same chat can appear multiple times. The script above deduplicates by chat.id during extraction to prevent duplicate tickets.

Step 2: Transform Data

Flatten each LiveChat chat into a SurveySparrow ticket structure, preserving speaker attribution and timestamps:

def transform_chat_to_ticket(chat, agent_lookup):
    """
    Transform a LiveChat chat into SurveySparrow ticket + comments.
    agent_lookup: dict mapping LiveChat agent email -> SurveySparrow user ID
    """
    threads = chat.get("threads", [chat.get("thread", {})])
    messages = []
    
    for thread in threads:
        for event in thread.get("events", []):
            if event.get("type") == "message":
                author_id = event.get("author_id", "unknown")
                text = event.get("text", "")
                ts = event.get("created_at", "")
                
                # Determine if author is agent or customer
                author_type = "Agent" if any(
                    u.get("id") == author_id and u.get("type") == "agent"
                    for u in chat.get("users", [])
                ) else "Customer"
                
                author_name = next(
                    (u.get("name", author_id) for u in chat.get("users", [])
                     if u.get("id") == author_id), author_id
                )
                
                messages.append({
                    "text": f"[{ts}] [{author_type}] {author_name}: {text}",
                    "raw_text": text,
                    "author_type": author_type,
                    "timestamp": ts
                })
    
    # First customer message becomes the description
    first_customer_msg = next(
        (m for m in messages if m["author_type"] == "Customer"),
        messages[0] if messages else {"text": "No content", "raw_text": "No content"}
    )
    
    description = first_customer_msg["text"]
    comments = [m["text"] for m in messages if m != first_customer_msg]
    
    customer = next(
        (u for u in chat.get("users", []) if u.get("type") == "customer"),
        {}
    )
    
    # Build subject from first customer message, capped at 200 chars
    subject_text = first_customer_msg["raw_text"][:180] or f"LiveChat #{chat.get('id', '')[:8]}"
    subject = f"[Migrated] {subject_text}"
    if len(subject) > 200:
        subject = subject[:197] + "..."
    
    # Map agent to SurveySparrow user
    agent = next(
        (u for u in chat.get("users", []) if u.get("type") == "agent"),
        {}
    )
    assignee_id = agent_lookup.get(agent.get("email"))
    
    # Map status
    last_thread = threads[-1] if threads else {}
    status = "OPEN" if last_thread.get("active") else "RESOLVED"
    
    return {
        "ticket": {
            "subject": subject,
            "description": description,
            "priority": "MEDIUM",
            "status": status,
            "assignee_id": assignee_id,
            "custom_fields": {
                "livechat_id": chat.get("id"),
                "livechat_tags": ", ".join(chat.get("tags", [])),
                "livechat_created_at": chat.get("created_at"),
            }
        },
        "contact": {
            "email": customer.get("email"),
            "full_name": customer.get("name"),
            "phone": customer.get("phone"),
        },
        "comments": comments
    }

Step 3: Load into SurveySparrow

Push contacts first to establish IDs, then create tickets, then replay comments in order. Track all source-to-target ID mappings for validation and rollback.

import json
 
SS_BASE = "https://api.surveysparrow.com/v3"
SS_HEADERS = {
    "Authorization": "Bearer <YOUR_SS_TOKEN>",
    "Content-Type": "application/json"
}
 
# Migration ledger for resume logic and rollback
migration_log = []
 
def create_contact(contact_data):
    """Create or retrieve existing contact. Returns contact ID."""
    resp = requests.post(
        f"{SS_BASE}/contacts",
        headers=SS_HEADERS, json=contact_data
    )
    if resp.status_code == 201:
        return resp.json().get("data", {}).get("id")
    elif resp.status_code == 409:
        # Contact already exists — fetch by email
        search_resp = requests.get(
            f"{SS_BASE}/contacts",
            headers=SS_HEADERS,
            params={"email": contact_data["email"]}
        )
        if search_resp.status_code == 200:
            contacts = search_resp.json().get("data", [])
            return contacts[0].get("id") if contacts else None
    elif resp.status_code == 422:
        print(f"Validation error for contact: {resp.json()}")
    return None
 
def create_ticket_with_retry(ticket_data, source_chat_id, max_retries=3):
    """Create ticket with retry logic and ledger tracking."""
    for attempt in range(max_retries):
        resp = requests.post(
            f"{SS_BASE}/tickets",
            headers=SS_HEADERS, json=ticket_data
        )
        if resp.status_code == 201:
            ticket_id = resp.json().get("data", {}).get("id")
            migration_log.append({
                "source_chat_id": source_chat_id,
                "target_ticket_id": ticket_id,
                "status": "success",
                "timestamp": datetime.utcnow().isoformat()
            })
            return ticket_id
        elif resp.status_code == 429:
            wait = min(60 * (2 ** attempt), 300)  # Exponential backoff, max 5 min
            print(f"Rate limited. Waiting {wait}s (attempt {attempt + 1})")
            time.sleep(wait)
        elif resp.status_code == 422:
            print(f"Validation error: {resp.json()}")
            migration_log.append({
                "source_chat_id": source_chat_id,
                "target_ticket_id": None,
                "status": f"failed_422: {resp.text}",
                "timestamp": datetime.utcnow().isoformat()
            })
            break  # Don't retry validation errors
        else:
            print(f"Unexpected error: {resp.status_code} - {resp.text}")
            migration_log.append({
                "source_chat_id": source_chat_id,
                "target_ticket_id": None,
                "status": f"failed_{resp.status_code}",
                "timestamp": datetime.utcnow().isoformat()
            })
            break
    return None
 
def add_comment(ticket_id, comment_text, private=False):
    """Add a comment to a ticket. Used for replaying chat messages."""
    resp = requests.post(
        f"{SS_BASE}/tickets/{ticket_id}/comments",
        headers=SS_HEADERS,
        json={"body": comment_text, "private": private}
    )
    if resp.status_code not in (200, 201):
        print(f"Comment failed for ticket {ticket_id}: {resp.status_code}")
    time.sleep(1)  # Throttle comment creation
    return resp.json() if resp.status_code in (200, 201) else None
 
def save_migration_log(filepath="migration_log.json"):
    """Persist ledger for resume and rollback."""
    with open(filepath, "w") as f:
        json.dump(migration_log, f, indent=2)

For higher throughput, use the batch endpoint:

def create_tickets_batch(ticket_list, batch_size=50):
    """
    Batch ticket creation. Start with batch_size=50 and increase
    if no errors. Maximum batch size is undocumented — test incrementally.
    """
    for i in range(0, len(ticket_list), batch_size):
        batch = ticket_list[i:i + batch_size]
        resp = requests.post(
            f"{SS_BASE}/tickets/batch",
            headers=SS_HEADERS,
            json={"tickets": batch}
        )
        if resp.status_code == 202:
            batch_token = resp.json().get("token")
            # Poll batch status
            while True:
                status_resp = requests.get(
                    f"{SS_BASE}/tickets/batch/status/{batch_token}",
                    headers=SS_HEADERS
                )
                status_data = status_resp.json()
                if status_data.get("status") in ("completed", "failed"):
                    print(f"Batch {i//batch_size}: {status_data}")
                    break
                time.sleep(5)
        else:
            print(f"Batch request failed: {resp.status_code} - {resp.text}")
        time.sleep(2)  # Pause between batches

Step 4: Validate Data

After loading, run validation checks:

• Record count comparison: Total chats extracted (deduplicated by chat.id) vs. tickets created. Compare against LiveChat's Reports → Chats total as the control number.
• Contact count: Unique customers with email addresses vs. contacts created in SurveySparrow.
• Sampling: Spot-check 5–10% of tickets for content accuracy — verify the description matches the first customer message and comments are in chronological order.
• Relationship integrity: Verify tickets are linked to correct contacts by cross-referencing livechat_id custom field with source data.
• Custom field values: Check 10+ records per custom field for correct data type and value.
• Migration log analysis: Count successes, failures by error type, and any records that need manual remediation.

def validate_migration(source_chats, migration_log):
    """Basic validation report."""
    total_source = len(source_chats)
    successes = [r for r in migration_log if r["status"] == "success"]
    failures = [r for r in migration_log if r["status"] != "success"]
    
    print(f"Source chats (deduplicated): {total_source}")
    print(f"Tickets created: {len(successes)}")
    print(f"Failed: {len(failures)}")
    print(f"Success rate: {len(successes)/total_source*100:.1f}%")
    
    if failures:
        # Group failures by error type
        from collections import Counter
        error_types = Counter(r["status"] for r in failures)
        print(f"Failure breakdown: {dict(error_types)}")

Edge Cases and Failure Modes

Chat Threads with No Customer Email

LiveChat allows anonymous chats. If no email was collected via pre-chat survey, you can't create a contact in SurveySparrow (email is required). Options: skip these chats (log them for manual review), assign to a placeholder contact like anonymous+{chat_id}@yourdomain.com, or store the chat ID in a custom field for later reconciliation. Quantify anonymous chats before migration — if they exceed 20% of your dataset, the placeholder approach may pollute your contact database.

Multi-Thread Chats

A single LiveChat chat can span multiple threads (sessions). Decide upfront: one ticket per chat (concatenate all threads chronologically), or one ticket per thread (more granular but higher volume). If you split one conversation into multiple tickets, SurveySparrow supports parent/child related ticket links — but the hierarchy is shallow: a child cannot have its own children. Use parent = first thread's ticket, children = subsequent threads. (support.surveysparrow.com)

File Attachments

LiveChat stores files as event attachments with URLs. These URLs may expire (typically after the chat session ends or based on retention settings) or require authentication. Download all files during extraction to local/cloud storage and re-host them before linking in SurveySparrow ticket comments. SurveySparrow's comment creation API supports attachments up to 15 MB but only for specific file types: PDF, PNG, JPEG, MP3, CSV, WAV. Unsupported file types (DOC, XLSX, ZIP, etc.) must be placed in external storage (S3, Google Cloud Storage) and linked from a comment as a URL. (developers.surveysparrow.com)

Duplicate Contacts

If the same customer appears across multiple chats, deduplicate by email before creating contacts in SurveySparrow. The Contacts API returns 409 Conflict on duplicate email — handle by fetching the existing contact ID and associating it with the new ticket.

Custom Properties Mismatch

LiveChat chat properties are key-value pairs with no fixed schema. SurveySparrow ticket custom fields must be created before use. Audit all property keys in LiveChat (extract a sample of 1,000 chats and collect unique keys), decide which to preserve, and pre-create the corresponding fields in SurveySparrow. Note: SurveySparrow custom field types include Text, Number, Dropdown, Multi-select, Date, and Checkbox. Match types carefully — a LiveChat property stored as a comma-separated string might need a Multi-select field.

LiveChat User ID Format

SurveySparrow's unique_id field must be alphanumeric, while LiveChat user IDs can be UUIDs with hyphens (e.g., a1b2c3d4-e5f6-7890-abcd-ef1234567890). Strip hyphens before using as unique_id, or store the raw source ID in a custom text property instead. (developers.surveysparrow.com)

Ticket Description Field Length

SurveySparrow's ticket description field length limit is not explicitly documented in public API docs. In testing, descriptions up to 65,535 characters were accepted. However, if chat transcripts exceed this (common with chats spanning 100+ messages), split the content: first portion into description, remainder into sequential comments. Always test with your longest chat transcript before running the full migration.

Timezone Handling

LiveChat timestamps use UTC in ISO 8601 format (2024-01-15T10:30:00.000Z). SurveySparrow also accepts ISO 8601 with timezone offset. If your agents operate across timezones, preserve UTC throughout the migration and let SurveySparrow's UI handle display conversion. Do not convert timestamps during transformation — it introduces drift and breaks chronological ordering.

API Failures and Resume Logic

Network drops happen. Your migration script must track the last successful source ID (cursor) so it can resume processing without duplicating records. Keep a ledger file (JSON or database table) with source_chat_id, target_ticket_id, attempt count, last HTTP status, and timestamp. Retry 429 and 5xx with exponential backoff (initial wait: 60 seconds, multiplier: 2x, max wait: 5 minutes). Quarantine hard failures (4xx except 429) instead of retrying — these indicate data problems that need manual inspection. (developers.surveysparrow.com)

Limitations and Constraints

Be explicit about what you're giving up:

SurveySparrow Ticket Management is intentionally simpler. It's built for feedback-driven case management, not high-volume live support. Accept the schema simplification or reconsider the target platform.

Migration timing estimates: SurveySparrow's ingress rate limits dictate migration speed. At a conservative 60 requests/minute:

• 1,000 tickets (no comments): ~17 minutes
• 10,000 tickets + 3 comments each: ~11 hours
• 100,000 tickets + 3 comments each: ~4.6 days of continuous API activity

These are API-time-only estimates. Add 2–4x for extraction, transformation, and error handling overhead.

Validation and Testing

Pre-Cutover Testing

1. Dry run: Migrate 100 chats to a SurveySparrow sandbox or test environment. Verify field mapping, comment ordering, and contact linkage.
2. Record count reconciliation: Compare source chat count (from LiveChat API, deduplicated by chat.id) against created ticket count. Use LiveChat's Reports → Chats total as the control number, not just job logs. (support.surveysparrow.com)
3. Field-level validation: For each custom field, verify 10+ records for correct data type and value. Pay special attention to multiselect fields (tags) and date fields (timezone).
4. Attachment spot-check: Confirm linked files are accessible and not returning 404s or authentication errors.
5. Long transcript test: Identify the 10 longest chat transcripts and verify they migrated completely without truncation.

User Acceptance Testing

• Have 2–3 agents review migrated tickets for their own historical chats
• Verify search works on migrated ticket subjects and descriptions
• Confirm contact records match expected customer data
• Test that ticket custom fields (livechat_id, tags) are filterable and searchable

Rollback Plan

• SurveySparrow's Ticket API supports DELETE /v3/tickets/{id}. Store all created ticket IDs in your migration ledger for bulk rollback.
• Keep LiveChat account active (read-only) until validation is complete.
• Never delete source data until at least 30 days post-migration.
• If your team cannot rerun a failed window without hand edits, you are not ready to cut over.
• Rollback script example: iterate through migration ledger, delete each ticket by target_ticket_id, log deletion status.

Post-Migration Tasks

1. Rebuild automations. LiveChat triggers, routing rules, and chatbot flows don't migrate. Recreate relevant workflows in SurveySparrow's Ticket Management workflow builder (trigger on ticket creation, status change, priority change). Map each LiveChat automation to its SurveySparrow equivalent before cutover. (support.surveysparrow.com)
2. Agent onboarding. SurveySparrow's ticket interface differs significantly from LiveChat's chat console. Run a focused 30–60 minute training session covering: ticket views and filters, comment workflows (internal vs. public), SLA tracking, and how to search for migrated historical data using the livechat_id custom field.
3. Monitor for gaps. Run a daily reconciliation check for 2 weeks post-cutover. Query SurveySparrow's API for total ticket and contact counts. Look for missing contacts, orphaned tickets (no associated contact), and incorrect field values.
4. Update integrations. Any tools connected to LiveChat (CRM, analytics, Slack notifications) need rewiring to SurveySparrow webhooks or API endpoints. Inventory all LiveChat integrations before cutover.
5. Preserve satisfaction history separately. SurveySparrow can import survey responses from CSV for supported question types, which is a better home for historic CSAT/NPS than burying scores inside ticket notes. Export LiveChat's post-chat survey data separately and import via SurveySparrow's response import. (support.surveysparrow.com)
6. Decommission LiveChat. After validation, set LiveChat to read-only. Maintain for reference during the transition period. Cancel after 90 days if no issues surface. Export a final JSON backup of all archives before cancellation.

Best Practices

• Back up everything before migration. Export LiveChat archives to JSON as a permanent record, independent of the migration target. Store in versioned cloud storage (S3, GCS).
• Run test migrations first. Never go straight to production. A 100-record test run catches 80% of mapping errors.
• Use incremental validation. Don't wait until the full migration completes to start checking. Validate in batches of 500–1,000. Stop and fix systemic errors before processing the next batch.
• Preserve source IDs. Store the LiveChat chat ID on every SurveySparrow ticket as a custom field. This is your only link between old and new systems and enables rollback, audit, and troubleshooting.
• Pre-create all custom fields. Build all ticket and contact custom fields in SurveySparrow before loading any data. Map against internal_name, not display labels. Document the mapping in a spreadsheet shared with your team.
• Automate the repeatable parts. Contact creation, ticket creation, and comment insertion should all be scripted. Manual entry introduces inconsistency and is not feasible beyond 100 records.
• Log everything. Write extraction, transformation, and loading logs to persistent storage. When a ticket looks wrong in SurveySparrow, you need to trace it back to the source chat by livechat_id.
• Use date windows for extraction. Smaller windows (1 month at a time) make reruns manageable and avoid hitting LiveChat's 100,000-record export ceiling.
• Test with your worst-case data first. Migrate the longest chats, the ones with the most attachments, and anonymous chats in your first test batch. Edge cases found early are cheap to fix.

For more on post-migration quality assurance, see our Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration.

Making the Right Call

Migrating from LiveChat to SurveySparrow Ticket Management is a data model translation, not a simple export. The biggest risk isn't losing records — it's losing context. Chat transcripts that made sense as threaded conversations can become unreadable walls of text in a flat ticket description. Tags that powered your LiveChat routing become orphaned strings in a custom field. Speaker attribution that was implicit in a chat UI must be explicitly embedded in comment text.

The teams that execute this well share three traits: they scope ruthlessly (not every chat is worth migrating — consider migrating only the last 12–24 months), they validate continuously (not just at the end), and they accept the architectural trade-offs of moving to a simpler system.

If you'd rather not build the extraction scripts, manage rate limits, and debug edge cases yourself, that's exactly what we do.