SolarWinds Service Desk to LiveChat Migration: Technical Guide

Migrating from SolarWinds Service Desk to LiveChat is not a typical help desk swap. It is a platform paradigm shift — moving from a full ITIL-based ITSM platform with incidents, problems, changes, CMDB, and asset management into a chat-first customer engagement tool with a fundamentally simpler data model. Most of your SolarWinds data has no direct equivalent in LiveChat. This guide covers what actually migrates, what gets lost, and how to execute the move without destroying data you might need later.

Why Teams Move from SolarWinds Service Desk to LiveChat

This migration is rarely about features. It is about simplifying the support model. Common drivers:

• Shifting from ITSM to customer-facing chat. Teams that adopted SolarWinds Service Desk for internal IT but now need a customer-facing chat widget move to LiveChat for real-time visitor engagement, proactive greetings, and e-commerce integrations.
• Cost reduction. SolarWinds Service Desk pricing starts at $39/agent/month (Team tier) and scales to $69/agent/month (Professional) and $89/agent/month (Enterprise). Teams that never use CMDB, change management, or release management pay for capabilities they don't touch. LiveChat starts at $20/agent/month (Starter) and $49/agent/month (Team), making it significantly cheaper for chat-only workflows.
• Platform consolidation with the Text ecosystem. LiveChat is part of the Text product family (LiveChat, HelpDesk, ChatBot, Knowledge Base). Teams moving to this ecosystem often adopt LiveChat as the front channel, with HelpDesk handling asynchronous tickets.
• Agency and multi-brand use cases. Agencies managing multiple client websites prefer LiveChat's multi-site widget deployment over SolarWinds' internal IT focus.

Before committing, be clear about what you are giving up. SolarWinds Service Desk is built on ITIL and includes incident, problem, change, and release management workflows, plus a CMDB with dependency mapping. LiveChat has none of this. (solarwinds.com)

Decision tree — should you use LiveChat as the target?

Is your CMDB actively used with dependency mapping?
  ├── YES → LiveChat is the wrong target. Evaluate ITSM-to-ITSM migration instead.
  └── NO →
      Do you have active problem/change management workflows?
        ├── YES → LiveChat alone is insufficient. Evaluate LiveChat + a separate ITSM tool,
        │         or choose an ITSM platform with chat capabilities.
        └── NO →
            Is your primary use case real-time customer-facing chat?
              ├── YES → LiveChat is a viable target. Continue with this guide.
              └── NO → Evaluate HelpDesk standalone or another ticketing platform.

Core Data Model Differences

This is the make-or-break section. The two platforms have almost no structural overlap.

The honest takeaway: if you have 200,000 incident records, a multi-level CMDB, and active change management workflows, you are migrating roughly 10–15% of your data to LiveChat. The rest needs to be archived, exported to a data warehouse, or moved to a different tool.

Migration Approaches

There is no native migration path between SolarWinds Service Desk and LiveChat. No import wizard, no one-click tool, no vendor-supported bridge. Every approach requires custom work.

1. CSV Export → Manual Restructure → HelpDesk Import

How it works: Export incidents, users, and knowledge articles from SolarWinds Service Desk as CSV files via the index page Actions menu or scheduled reports. Restructure the CSV to match HelpDesk's import format. Import manually. (documentation.solarwinds.com)

When to use it: Small environments (under 5,000 records), one-time migration, no engineering resources.

Pros:

• No code required
• SolarWinds supports CSV export from most index pages
• Good for archival snapshots

Cons:

• CSV exports from SolarWinds do not include attachments or embedded images
• Relationships between records (incident → asset, incident → problem) are lost
• Comments and audit trails may not export cleanly
• LiveChat has no bulk CSV import for chat history — you would be importing into HelpDesk only
• Excel breaks row alignment above 32,767 characters in a cell
• Manual field mapping is error-prone at scale

Complexity: Low Scalability: Small datasets only Estimated effort: 1–3 days for a non-technical admin

2. API-Based Migration (SolarWinds REST API → LiveChat APIs)

How it works: Extract data from SolarWinds Service Desk via the Samanage REST API (api.samanage.com), transform it to match LiveChat's chat → thread → event hierarchy, then load it using the LiveChat Agent Chat API and Configuration API. (platform.text.com)

When to use it: Mid-to-large environments, teams that need to preserve conversation history, or environments with custom fields.

Pros:

• Full control over data transformation
• Can preserve agent assignments and customer metadata
• Handles pagination and filtering on extraction side

Cons:

• SolarWinds API rate limits are not publicly documented — you will discover them empirically (in practice, expect throttling above ~100 requests/minute based on community reports)
• SolarWinds API paginates at a max of 200 records per page
• LiveChat's Configuration API is rate-limited to 1,000 requests per 10 minutes per license, shared across all tokens and integrations
• LiveChat generates event created_at timestamps server-side — replayed history will not keep original event timestamps unless you store source dates in properties or an external archive (platform.text.com)
• LiveChat limits message text to 16 KB per event
• Text bills API usage after the one-time free top-up
• Building the transformation layer between an ITSM incident model and a chat thread model is non-trivial

Complexity: High Scalability: Enterprise-grade with proper batching Estimated effort: 2–4 weeks for a senior developer (breakdown below in Timeline section)

3. Third-Party Migration Tools

How it works: Platforms like Help Desk Migration offer automated connectors for both SolarWinds Service Desk and LiveChat/HelpDesk. They handle extraction, mapping, and loading through a wizard-driven interface. The LiveChat Marketplace currently lists a migration app that advertises support for contacts, users, groups, attachments, notes, tags, and 70+ source platforms. (livechat.com)

When to use it: Teams without engineering bandwidth who want a guided migration path.

Pros:

• No-code migration wizard
• Handles field mapping, attachments, and basic relationships
• Demo/test migration available before committing

Cons:

• Limited customization for complex transformations
• May not support all SolarWinds custom fields or CMDB objects
• Per-record pricing can become expensive at scale (Help Desk Migration typically charges $15–40 per 1,000 records depending on volume tier — verify current pricing directly)
• Verify SolarWinds Service Desk as a supported source before committing

Complexity: Low to Medium Scalability: Medium (depends on vendor pricing model) Estimated effort: 2–5 days including test migration and validation

4. Custom ETL Pipeline

How it works: Build a dedicated extract-transform-load pipeline using Python, Node.js, or a data integration tool. Extract from SolarWinds via API, stage in an intermediate database (PostgreSQL, SQLite), transform data models, then push to LiveChat/HelpDesk APIs.

When to use it: Large environments with complex data, teams needing full audit trails, or when you need to split data across multiple targets (LiveChat + HelpDesk + data warehouse).

Pros:

• Maximum flexibility and control
• Can split SolarWinds data across multiple targets
• Intermediate staging enables validation before loading
• Best auditability and rollback position
• Reusable for future migrations

Cons:

• Highest engineering investment
• Requires maintenance during the migration window
• Needs thorough error handling for both APIs
• If you skip source-to-target reconciliation tables, you lose most of the value of building ETL in the first place

Complexity: High Scalability: Enterprise-grade Estimated effort: 3–5 weeks for a senior developer (includes staging schema design, reconciliation tables, and validation scripts)

5. Middleware Platforms (Zapier, Make)

How it works: Use Zapier or Make to connect SolarWinds Service Desk triggers to LiveChat actions. Zapier exposes LiveChat and SolarWinds Service Desk connectors, and Make exposes verified apps for both platforms plus arbitrary API calls. (zapier.com)

When to use it: Ongoing sync of new records during a transition period. Not suitable for bulk historical migration.

Pros:

• Quick setup for simple workflows
• Good for bridging the gap during phased cutover

Cons:

• Not designed for bulk data migration
• Trigger-based execution means you cannot backfill historical data
• Rate limits and task quotas on middleware platforms add another constraint layer
• Pushing 100,000 tickets with 5 comments each will exhaust API quotas and cost thousands in usage fees

Complexity: Low Scalability: Small ongoing volumes only Estimated effort: 2–4 hours for initial setup; ongoing monitoring required

Approach Comparison Table

Recommendations by scenario:

• Small business, <5K records, one-time move: CSV export + HelpDesk import, or a third-party tool.
• Mid-market, 5K–50K records, dedicated engineer: API-based migration with a staging database.
• Enterprise, 50K+ records, complex ITSM data: Custom ETL pipeline, or a managed migration service.
• Phased transition with ongoing sync: Middleware for new records + API-based backfill for history.

Estimated Migration Timeline

For an API-based or custom ETL migration of a mid-sized environment (10K–50K incidents):

For small environments (<5K records) using CSV or a third-party tool, compress this to 3–7 calendar days.

When to Use a Managed Migration Service

DIY migrations between architecturally mismatched platforms fail in predictable ways:

• Data loss from model compression. When you flatten an ITSM incident with 40 fields into a chat thread with 6, the engineer building the transform decides what gets dropped. Without domain expertise, the wrong fields get cut.
• Broken relationships. SolarWinds links incidents to problems, problems to changes, changes to CIs. This relational graph does not exist in LiveChat. Preserving the relationships in metadata or notes requires deliberate design.
• Underestimated scope. Teams budget for incidents and forget about knowledge base articles, attachments, custom fields, and audit logs.
• Hidden engineering cost. A senior engineer spending 3–4 weeks on migration scripting is not shipping product. At $150/hour fully loaded, that is $18,000–24,000 in opportunity cost — often more than a managed service fee.
• Target platform limits. SolarWinds comments can include files up to 25 MB each (documentation.solarwinds.com), while LiveChat's Agent API enforces a 10 MB upload limit. LiveChat rate limits surface as Too many requests, and API usage is billable.

ClonePartner handles complex helpdesk and ITSM migrations, including paradigm shifts like SolarWinds to chat-first tools. We build custom extraction scripts against the Samanage API, handle the data model transformation, and load into LiveChat/HelpDesk with field-level validation. For environments with CMDB data that needs archival alongside the migration, we route data to multiple targets in a single pipeline. We keep the discussion honest: if you still need ITSM capabilities after go-live, we will tell you LiveChat alone is the wrong target.

Pre-Migration Planning

Data Audit Checklist

Before extracting anything, inventory what you actually have in SolarWinds Service Desk:

• Incidents — total count, status distribution (open vs. closed), date range
• Problems — linked incidents, root cause notes
• Changes — approval workflows, linked CIs
• Releases — linked changes
• Assets / Hardware — types, custom fields, warranty data
• CMDB / CIs — hierarchy depth, relationship count
• Knowledge Base Articles — count, categories, attachments
• Users — agents vs. requesters, roles, group memberships
• Groups / Departments — routing rules, escalation paths
• Custom Fields — across all object types (count by object type, note data types)
• Attachments — total size, count of files >10 MB (these need special handling)
• Service Catalog Items — request types, workflows
• Automations — email routing, escalation rules, Slack/Teams hooks, Zapier/Make flows
• Data residency — where SolarWinds hosts your data (US/EU), and where LiveChat will host it (verify LiveChat data center region matches your compliance requirements)

GDPR and Data Compliance Considerations

If your organization operates in the EU or processes EU personal data:

• Data residency: SolarWinds Service Desk data may be hosted in the US or EU depending on your contract. LiveChat (Text S.A.) is a Polish company and stores data in data centers within the US and EU. Verify that the target region matches your data residency requirements before migration.
• Data processing agreement (DPA): Ensure you have a signed DPA with Text S.A. (LiveChat's parent) before migrating personal data. LiveChat provides a standard DPA on request.
• Right to erasure: If you have outstanding GDPR deletion requests in SolarWinds, process them before migration. Do not migrate data that should already have been deleted.
• Data minimization: Migration is an opportunity to purge data you no longer need. Remove inactive user records, closed incidents beyond your retention policy, and orphaned attachments.
• Transfer mechanism: If migrating data across jurisdictions (e.g., US-hosted SolarWinds to EU-hosted LiveChat or vice versa), confirm that Standard Contractual Clauses or another valid transfer mechanism is in place.

Define Migration Scope

For most SolarWinds-to-LiveChat migrations, you will migrate a subset of your data:

Exclude system-generated alerts, automated password reset tickets, and orphaned assets. If you do not shrink scope early, the project expands into an unplanned re-platform.

Migration Strategy

• Big bang: Export everything, transform, load into LiveChat/HelpDesk, cut over in a single window. Best for small datasets (<10K records). Downside: no fallback if validation fails.
• Phased: Migrate users and groups first, then knowledge base, then historical tickets, then open tickets. Allows validation at each stage. Recommended for most teams.
• Incremental with delta sync: Migrate historical data first, then run a delta sync during the cutover window to catch records created after the initial extraction. Required for teams that cannot afford downtime. Read more about this approach in our zero-downtime help desk data migration guide.

Data Model and Object Mapping

Incident to Chat/Ticket Mapping

SolarWinds incidents do not map cleanly to LiveChat chats. A SolarWinds incident is a structured record with priority, category, subcategory, SLA timers, linked assets, and an audit trail. A LiveChat chat is a real-time conversation thread. (documentation.solarwinds.com)

User and Group Mapping

SolarWinds users map to LiveChat agents (for staff) and HelpDesk contacts (for requesters).

• Roles: SolarWinds has Administrator, Full Agent, Limited Agent. LiveChat has Owner, Admin, Agent. Map accordingly.
• Groups: SolarWinds groups map directly to LiveChat groups. Create groups in LiveChat first, then assign agents.
• Departments: SolarWinds departments have no direct equivalent. Use LiveChat groups as a proxy.

Custom Fields and Properties

LiveChat uses a Properties system rather than traditional custom fields. Properties are key-value pairs organized by namespace and can be attached to chats, threads, or events. This is architecturally different from SolarWinds' custom fields, which behave like database columns on a record.

For HelpDesk (the ticketing product), custom fields are more conventional — you create them in settings and they appear on ticket forms. HelpDesk supports text, number, dropdown, checkbox, and date field types.

Knowledge Base Migration

The Text Knowledge Base is a separate product from LiveChat. Migrating SolarWinds Service Desk knowledge articles requires independent handling:

• SolarWinds extraction: Use GET /solutions.json?per_page=200&page=1 to extract articles. Each article includes title, body (HTML), category, and attachments.
• Content format: Text Knowledge Base accepts HTML content. SolarWinds article HTML generally imports without modification, but test embedded images and internal links.
• Category mapping: SolarWinds article categories do not auto-create in Text Knowledge Base. Create the category structure manually first, then assign articles.
• API access: Text Knowledge Base does not expose a public bulk import API as of July 2025. Articles must be created individually through the Knowledge Base management interface or via the LiveChat Platform Developer API's Knowledge Base methods (currently in beta). For large article sets (500+), contact Text support about bulk import options.
• Attachments: Download from SolarWinds and re-upload to the Knowledge Base CDN. The same 10 MB file limit applies.
• Internal links: Any links between articles that reference SolarWinds URLs will break. Build a URL mapping table and do a find-replace pass before import.

Migration Architecture

Data Flow

SolarWinds Service Desk (api.samanage.com)
        │
        ▼  [Extract via REST API]
Staging Database (PostgreSQL / SQLite / JSON files)
        │
        ▼  [Transform: flatten ITSM model → chat/ticket model]
Transformed Records (JSON)
        │
        ├──▶ LiveChat Agent Chat API (chats, agents, groups)
        ├──▶ HelpDesk API (tickets, contacts, custom fields)
        ├──▶ Text Knowledge Base (articles)
        └──▶ Archive Storage (CMDB, changes, problems → CSV/data warehouse)

SolarWinds API Extraction

SolarWinds Service Desk uses the Samanage REST API. Key details:

• Base URL: https://api.samanage.com
• Authentication: Bearer token (JSON Web Token generated from admin user settings) (documentation.solarwinds.com)
• Pagination: Page-based, max 200 records per page via per_page parameter
• Format: JSON responses (append .json to endpoints)
• Rate limits: Not publicly documented. Community reports suggest throttling above ~100 requests/minute. Implement exponential backoff on 429 responses.
• Plan requirement: API access requires the Advanced or Premier plan tier

Key endpoints for extraction:

GET /incidents.json?per_page=200&page=1
GET /problems.json?per_page=200&page=1
GET /changes.json?per_page=200&page=1
GET /hardwares.json?per_page=200&page=1
GET /users.json?per_page=200&page=1
GET /configuration_items.json?per_page=200&page=1
GET /solutions.json?per_page=200&page=1   # Knowledge base

LiveChat API Loading

LiveChat's API ecosystem is split across multiple APIs:

• Agent Chat API (v3.5): For creating and managing chats, threads, and events. Target v3.5 for migration stability — v3.6 adds rich message formats but does not change core import mechanics.
• Configuration API (v3.5): For managing agents, groups, bots, tags, and properties
• Reports API: Read-only, for analytics and post-migration validation

Key constraints:

• Rate limit: 1,000 requests per 10 minutes per license (shared across all tokens and integrations)
• Auth: OAuth 2.1 bearer tokens or Personal Access Tokens (PATs). For migration scripts, PATs are simpler — generate them in the LiveChat Developer Console.
• No bulk import endpoint: Every chat/thread/event must be created individually
• Message size: 16 KB per event text
• File upload: 10 MB limit per file
• Timestamps: created_at on events is generated server-side — imported history reflects replay time
• Shared rate limit trap: If other integrations (chatbots, CRM connectors) are running against the same license, they consume from the same 1,000-request pool. Pause other integrations during migration load.
• API billing: Text bills API requests after the one-time free top-up (currently 50,000 free requests for new accounts)

HelpDesk API Loading

If you are using HelpDesk as the ticket target (recommended for migrating incidents), key details:

• Base URL: https://api.helpdesk.com
• Authentication: Personal Access Token (generated in HelpDesk Settings → Integrations → API)
• Rate limit: 200 requests per minute per account
• Ticket creation: POST /v1/tickets — accepts subject, message (HTML or text), requester email, status, priority, tags, and custom fields
• Contact creation: POST /v1/contacts — create customers before creating tickets
• Custom fields: Create via the HelpDesk admin UI first. The API does not support custom field creation programmatically.
• No bulk endpoint: Tickets must be created one at a time

Step-by-Step Migration Process

Step 1: Extract Data from SolarWinds

Never pipe data directly from API to API. Extract the SolarWinds data and store it in a staging database or local JSON files. This lets you run transformations without hitting SolarWinds rate limits repeatedly.

import requests
import json
import time
import os
 
SWSD_BASE = "https://api.samanage.com"
SWSD_TOKEN = "your-jwt-token-here"
OUTPUT_DIR = "swsd_export"
 
os.makedirs(OUTPUT_DIR, exist_ok=True)
 
def extract_all(endpoint, output_file):
    headers = {
        "Authorization": f"Bearer {SWSD_TOKEN}",
        "Accept": "application/json"
    }
    page = 1
    all_records = []
    retry_count = 0
    max_retries = 5
    
    while True:
        url = f"{SWSD_BASE}/{endpoint}?per_page=200&page={page}"
        try:
            resp = requests.get(url, headers=headers, timeout=30)
        except requests.exceptions.RequestException as e:
            retry_count += 1
            if retry_count > max_retries:
                print(f"FATAL: Failed after {max_retries} retries on {endpoint} page {page}: {e}")
                break
            time.sleep(2 ** retry_count)  # Exponential backoff
            continue
        
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 30))
            print(f"Rate limited on {endpoint} page {page}. Waiting {retry_after}s...")
            time.sleep(retry_after)
            continue
        
        if resp.status_code >= 500:
            retry_count += 1
            if retry_count > max_retries:
                print(f"FATAL: Server error after {max_retries} retries on {endpoint} page {page}")
                break
            time.sleep(2 ** retry_count)
            continue
        
        resp.raise_for_status()
        data = resp.json()
        retry_count = 0  # Reset on success
        
        if not data:
            break
        
        all_records.extend(data)
        print(f"  {endpoint} page {page}: {len(data)} records (total: {len(all_records)})")
        page += 1
        time.sleep(0.5)  # Respect undocumented rate limits
    
    filepath = os.path.join(OUTPUT_DIR, output_file)
    with open(filepath, "w") as f:
        json.dump(all_records, f, indent=2)
    
    print(f"Extracted {len(all_records)} records to {filepath}")
    return len(all_records)
 
# Extract each object type
endpoints = [
    ("incidents.json", "incidents.json"),
    ("users.json", "users.json"),
    ("groups.json", "groups.json"),
    ("solutions.json", "solutions.json"),
    ("problems.json", "problems.json"),
    ("changes.json", "changes.json"),
    ("hardwares.json", "assets.json"),
    ("configuration_items.json", "cmdb.json"),
]
 
for endpoint, filename in endpoints:
    count = extract_all(endpoint, filename)
    print(f"{filename}: {count} records\n")

For a quick snapshot, use the CSV export from SolarWinds directly: navigate to the relevant index page, click Actions → Export → CSV-Current View. For larger exports, use Analytics → Reports and schedule a CSV export.

Step 2: Transform Data

The transformation layer is where the real work happens. You are converting a structured ITSM record into a flat chat or ticket.

import re
from html import unescape
 
def strip_html(html_string):
    """Convert HTML to plain text, preserving line breaks."""
    if not html_string:
        return ""
    # Replace <br> and </p> with newlines
    text = re.sub(r'<br\s*/?>', '\n', html_string)
    text = re.sub(r'</p>', '\n', text)
    # Strip all other tags
    text = re.sub(r'<[^>]+>', '', text)
    return unescape(text).strip()
 
def truncate_to_limit(text, limit_bytes=16000):
    """Truncate text to LiveChat's 16 KB event limit, splitting if needed."""
    encoded = text.encode('utf-8')
    if len(encoded) <= limit_bytes:
        return [text]
    # Split into chunks
    chunks = []
    while encoded:
        chunk = encoded[:limit_bytes]
        # Avoid splitting in the middle of a UTF-8 character
        while chunk and (chunk[-1] & 0xC0) == 0x80:
            chunk = chunk[:-1]
        chunks.append(chunk.decode('utf-8'))
        encoded = encoded[len(chunk):]
    return chunks
 
def transform_incident_to_helpdesk_ticket(incident):
    """Transform a SolarWinds incident into a HelpDesk-compatible ticket."""
    
    status_map = {
        "New": "open",
        "Assigned": "open", 
        "In Progress": "open",
        "On Hold": "pending",
        "Resolved": "solved",
        "Closed": "closed"
    }
    
    priority_map = {
        "Critical": "urgent",
        "High": "high",
        "Medium": "normal",
        "Low": "low",
        "None": "low"
    }
    
    # Handle missing requester
    requester = incident.get("requester") or {}
    requester_email = requester.get("email")
    if not requester_email:
        requester_email = "unknown-requester@migration.local"
    
    # Handle deleted/deactivated assignee
    assignee = incident.get("assignee") or {}
    assignee_email = assignee.get("email")
    
    description = strip_html(incident.get("description", ""))
    
    ticket = {
        "subject": (incident.get("name", "No Subject") or "No Subject")[:255],
        "description": description,
        "description_chunks": truncate_to_limit(description),
        "status": status_map.get(incident.get("state"), "open"),
        "priority": priority_map.get(
            (incident.get("priority") or {}).get("name"), "normal"
        ),
        "requester_email": requester_email,
        "assignee_email": assignee_email,
        "created_at": incident.get("created_at"),
        "source_id": incident.get("id"),
        "tags": [f"swsd-{incident.get('id')}"],
        "comments": [],
        "warnings": []
    }
    
    # Flag records needing manual review
    if requester_email == "unknown-requester@migration.local":
        ticket["warnings"].append("MISSING_REQUESTER")
    if assignee_email and not assignee.get("is_active", True):
        ticket["warnings"].append(f"INACTIVE_ASSIGNEE:{assignee_email}")
    
    # Preserve category as tag
    if incident.get("category"):
        cat_name = (incident["category"] or {}).get("name")
        if cat_name:
            ticket["tags"].append(f"category:{cat_name}")
    
    if incident.get("subcategory"):
        subcat_name = (incident["subcategory"] or {}).get("name")
        if subcat_name:
            ticket["tags"].append(f"subcategory:{subcat_name}")
    
    # Preserve linked asset info as structured note
    if incident.get("assets"):
        asset_names = [a.get("name", "unknown") for a in incident["assets"]]
        ticket["comments"].append({
            "body": f"[Migration Metadata]\nLinked assets: {', '.join(asset_names)}",
            "author": "migration-bot",
            "created_at": incident.get("created_at"),
            "visibility": "private"
        })
    
    # Preserve linked problem/change references
    if incident.get("problem"):
        ticket["comments"].append({
            "body": (
                f"[Migration Metadata]\n"
                f"Linked Problem: {incident['problem'].get('number', 'unknown')}\n"
                f"Problem Name: {incident['problem'].get('name', 'N/A')}"
            ),
            "author": "migration-bot",
            "created_at": incident.get("created_at"),
            "visibility": "private"
        })
    
    # Preserve SLA data as structured note (since LiveChat has no SLA engine)
    if incident.get("sla_violations"):
        ticket["comments"].append({
            "body": f"[Migration Metadata]\nSLA Violations: {json.dumps(incident['sla_violations'])}",
            "author": "migration-bot",
            "created_at": incident.get("created_at"),
            "visibility": "private"
        })
    
    return ticket

Handle edge cases during transformation:

• Missing requesters: SolarWinds allows incidents without a requester email in some configurations. LiveChat/HelpDesk requires a customer identifier. Assign orphaned records to a placeholder contact (e.g., unknown-requester@migration.local) and flag them for manual review.
• Deleted agents: If a SolarWinds incident is assigned to an agent who has left the company, map that ticket to a generic "Legacy Support" agent in LiveChat.
• Character limits: If a SolarWinds description exceeds LiveChat's 16 KB event limit, split the text and append the remainder as a follow-up event.
• HTML stripping: SolarWinds rich-text fields contain HTML that LiveChat may not support. Strip unsupported tags or convert to plain text while preserving line breaks.

Step 3: Load Attachments

Attachments must be downloaded from SolarWinds and re-uploaded to LiveChat/HelpDesk. SolarWinds comment files can be up to 25 MB each, but LiveChat's upload limit is 10 MB. Files exceeding that limit need to go to external cloud storage (S3, Google Cloud Storage) with a link injected into the ticket.

def handle_attachment(attachment, incident_id):
    """Download attachment from SolarWinds and categorize by size."""
    url = attachment.get("url")
    filename = attachment.get("filename", "unknown")
    size_bytes = attachment.get("size", 0)
    
    # Download to local staging
    local_path = f"attachments/{incident_id}/{filename}"
    os.makedirs(os.path.dirname(local_path), exist_ok=True)
    
    resp = requests.get(url, headers={"Authorization": f"Bearer {SWSD_TOKEN}"}, stream=True)
    with open(local_path, "wb") as f:
        for chunk in resp.iter_content(chunk_size=8192):
            f.write(chunk)
    
    if size_bytes > 10 * 1024 * 1024:  # > 10 MB
        return {
            "action": "upload_to_cloud_storage",
            "local_path": local_path,
            "filename": filename,
            "size": size_bytes,
            "incident_id": incident_id
        }
    else:
        return {
            "action": "upload_to_livechat",
            "local_path": local_path,
            "filename": filename,
            "size": size_bytes,
            "incident_id": incident_id
        }

Download attachments during the extraction phase and store them locally. During the load phase, upload each file and capture the new CDN URL before creating the associated ticket or event.

Step 4: Create Agents, Groups, and Customers

Create reference data in LiveChat before loading any conversation data. The load order matters: groups → tags → customers → agents → chats/threads → events → attachments. This sequence reduces broken routing and orphaned history.

import hashlib
 
LC_BASE = "https://api.livechatinc.com/v3.5"
LC_TOKEN = "your-pat-token-here"
RECONCILIATION_LOG = "reconciliation.jsonl"
 
def create_agent_in_livechat(agent_data):
    """Create an agent via the Configuration API with retry and reconciliation."""
    headers = {
        "Authorization": f"Bearer {LC_TOKEN}",
        "Content-Type": "application/json"
    }
    
    # Idempotency check: query existing agents first
    check_resp = requests.post(
        f"{LC_BASE}/configuration/action/list_agents",
        headers=headers,
        json={}
    )
    if check_resp.status_code == 200:
        existing = [a for a in check_resp.json() if a.get("email") == agent_data.get("email")]
        if existing:
            log_reconciliation("agent", agent_data.get("email"), existing[0]["id"], "already_exists")
            return existing[0]
    
    # Create new agent
    resp = requests.post(
        f"{LC_BASE}/configuration/action/create_agent",
        headers=headers,
        json=agent_data
    )
    if resp.status_code == 429:
        retry_after = int(resp.headers.get("Retry-After", 60))
        time.sleep(retry_after)
        return create_agent_in_livechat(agent_data)
    
    result = resp.json()
    log_reconciliation("agent", agent_data.get("email"), result.get("id"), "created")
    return result
 
def log_reconciliation(object_type, source_id, target_id, status, payload_hash=None):
    """Write reconciliation entry for audit trail."""
    entry = {
        "object_type": object_type,
        "source_id": source_id,
        "target_id": target_id,
        "status": status,
        "payload_hash": payload_hash,
        "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
    }
    with open(RECONCILIATION_LOG, "a") as f:
        f.write(json.dumps(entry) + "\n")

Step 5: Load Tickets and Chat Threads

Push the transformed data to LiveChat/HelpDesk. For each record:

1. Check if the record already exists (by original SolarWinds ID stored as a tag or property) to provide idempotency across retry runs.
2. Create the chat/ticket with the initial event.
3. Add subsequent comments as thread events, preserving author and visibility (public vs. private).
4. Attach uploaded files using the new CDN URLs.
5. Write a reconciliation entry mapping source ID → target ID, object type, status, and payload hash.

import hashlib
 
DEAD_LETTER_QUEUE = "dead_letter.jsonl"
 
def load_ticket_to_helpdesk(ticket, max_retries=3):
    """Load a transformed ticket to HelpDesk with retry and dead-letter handling."""
    headers = {
        "Authorization": f"Bearer {HELPDESK_TOKEN}",
        "Content-Type": "application/json"
    }
    
    # Idempotency: check if already migrated
    source_tag = f"swsd-{ticket['source_id']}"
    # (In production, query HelpDesk by tag to check existence)
    
    payload = {
        "subject": ticket["subject"],
        "message": {
            "text": ticket["description_chunks"][0] if ticket.get("description_chunks") else ticket["description"],
            "type": "customer"
        },
        "requester": {
            "email": ticket["requester_email"]
        },
        "status": ticket["status"],
        "priority": ticket["priority"],
        "tags": ticket["tags"]
    }
    
    payload_hash = hashlib.sha256(json.dumps(payload, sort_keys=True).encode()).hexdigest()
    
    for attempt in range(max_retries):
        try:
            resp = requests.post(
                "https://api.helpdesk.com/v1/tickets",
                headers=headers,
                json=payload,
                timeout=30
            )
            
            if resp.status_code == 429:
                retry_after = int(resp.headers.get("Retry-After", 60))
                time.sleep(retry_after)
                continue
            
            if resp.status_code >= 500:
                time.sleep(2 ** attempt)
                continue
            
            resp.raise_for_status()
            result = resp.json()
            
            log_reconciliation("ticket", ticket["source_id"], result.get("id"), "created", payload_hash)
            return result
            
        except requests.exceptions.RequestException as e:
            if attempt == max_retries - 1:
                # Dead-letter queue
                with open(DEAD_LETTER_QUEUE, "a") as f:
                    f.write(json.dumps({
                        "source_id": ticket["source_id"],
                        "error": str(e),
                        "payload": payload,
                        "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
                    }) + "\n")
                log_reconciliation("ticket", ticket["source_id"], None, "failed", payload_hash)
                return None
            time.sleep(2 ** attempt)
    
    return None

Records that fail after 3 retries go to a dead-letter queue for manual review. After the main load completes, process the dead-letter queue separately — many failures are transient and resolve on retry.

Step 6: Validate the Migration

After loading, run validation checks in layers:

1. Record counts: Compare total incidents extracted vs. total tickets/chats created, broken down by status and date range.
2. Field-level sampling: Pull 2% of records (minimum 50) and verify subject, description, status, priority, and assignee match.
3. Status distribution: Verify that the open/closed/pending ratio in the target matches the source within 1%.
4. Agent assignments: Confirm tickets are assigned to the correct agents.
5. Search verification: Search for 10 specific known tickets by subject or customer email.
6. Attachment spot check: Open 20 attachments across different file types (PDF, PNG, DOCX, XLSX) and verify they render correctly.
7. Dead-letter review: Check how many records ended up in the dead-letter queue. Anything above 2% failure rate indicates a systemic issue.
8. Reconciliation table audit: Verify every source record has a corresponding target record with a valid ID.

def validate_migration(source_file, reconciliation_file):
    """Basic validation: compare source record count against reconciliation log."""
    with open(source_file) as f:
        source_records = json.load(f)
    
    reconciliation = {}
    with open(reconciliation_file) as f:
        for line in f:
            entry = json.loads(line)
            if entry["object_type"] == "ticket":
                reconciliation[str(entry["source_id"])] = entry
    
    source_ids = {str(r["id"]) for r in source_records}
    migrated_ids = {sid for sid, entry in reconciliation.items() if entry["status"] == "created"}
    failed_ids = {sid for sid, entry in reconciliation.items() if entry["status"] == "failed"}
    missing_ids = source_ids - migrated_ids - failed_ids
    
    print(f"Source records:   {len(source_ids)}")
    print(f"Migrated:         {len(migrated_ids)} ({100*len(migrated_ids)/len(source_ids):.1f}%)")
    print(f"Failed:           {len(failed_ids)} ({100*len(failed_ids)/len(source_ids):.1f}%)")
    print(f"Missing:          {len(missing_ids)} ({100*len(missing_ids)/len(source_ids):.1f}%)")
    
    if missing_ids:
        print(f"\nMissing source IDs (first 20): {list(missing_ids)[:20]}")
    
    return len(missing_ids) == 0 and len(failed_ids) == 0

Do not rely on the LiveChat UI alone for validation. Use the API to verify counts. LiveChat stores past conversations in Archives — use archive-based sampling for UAT instead of only checking the active chat list. (livechat.com)

Step 7: UAT and Cutover

• Invite 2–3 support agents to review their own migrated tickets.
• Have them verify that customer context is preserved and search works.
• If they cannot find legacy customer issues, your data mapping failed.
• Test any workflows or automations built in the target system.
• After successful validation, redirect support traffic to LiveChat.
• Run a final delta sync to catch records created during the validation window.
• Keep SolarWinds in read-only mode for 30–90 days as a fallback (30 days minimum; extend to 90 days if you have regulatory retention requirements).

Edge Cases and Challenges

Inline Images

SolarWinds Service Desk users frequently paste screenshots directly into incident descriptions. These are stored as base64-encoded strings or authenticated AWS links. You must parse the HTML body, extract each image, upload it to LiveChat (within the 10 MB limit), and replace the <img> tag in the text body with the new CDN URL. If you skip this, all historical screenshots will display as broken links.

import base64
import re
 
def extract_inline_images(html_body, incident_id):
    """Extract base64 inline images from HTML and save as files."""
    images = []
    pattern = r'<img[^>]+src="data:image/(png|jpeg|gif);base64,([^"]+)"'
    
    for i, match in enumerate(re.finditer(pattern, html_body)):
        ext = match.group(1)
        b64_data = match.group(2)
        filename = f"inline_{incident_id}_{i}.{ext}"
        filepath = f"attachments/{incident_id}/{filename}"
        
        os.makedirs(os.path.dirname(filepath), exist_ok=True)
        with open(filepath, "wb") as f:
            f.write(base64.b64decode(b64_data))
        
        images.append({"filepath": filepath, "filename": filename, "original_tag": match.group(0)})
    
    return images

Duplicate Requesters

SolarWinds sometimes allows duplicate user records if SSO configurations change. Shared inboxes and generic requester emails create the same problem. Deduplicate users by email address during the staging phase and define a deterministic merge rule for conflicting records (e.g., keep the most recently active record, merge group memberships).

Multi-Level Relationship Collapse

SolarWinds links incidents → problems → changes → CIs in a relational graph. LiveChat has no concept of inter-record relationships. Preserve these as structured notes on the migrated record:

[Migration Metadata]
Original ID: INC-4521
Linked Problem: PRB-089
Linked Change: CHG-312
Linked CIs: SRV-WEB-01, SRV-DB-03
Source System: SolarWinds Service Desk
Migration Date: 2025-07-15T14:30:00Z

Attachment Size Mismatches

SolarWinds comment files can be up to 25 MB each. LiveChat's upload API enforces a 10 MB limit. For files exceeding 10 MB:

1. Upload to S3, Google Cloud Storage, or Azure Blob Storage
2. Generate a signed URL with a long expiry (or make the object publicly readable within your org's access controls)
3. Inject the URL into the ticket comment: [Attachment: large_report.pdf (18.2 MB)](https://storage.example.com/...)

Timestamp Limitations

LiveChat documents created_at as server-generated for events. Imported history will reflect the time of replay, not the original event timestamp. Store source dates in chat/thread properties or a reconciliation table to preserve the original timeline for audit purposes. HelpDesk is slightly better — its ticket creation API accepts a created_at field, but verify current behavior as this has changed across versions.

API Failures and Retries

Both APIs return transient errors. Implement:

• Exponential backoff with jitter on 429 and 5xx responses (base delay × 2^attempt + random(0, 1s))
• Idempotency checks — before creating a record, check if it already exists by original ID stored as a tag
• Dead-letter queue — records that fail after 3 retries go to a separate file for manual review
• Checkpoint by updated_at plus source ID, not by page number alone — page-based checkpointing breaks if records are created or deleted during extraction

Limitations and Hard Constraints

What LiveChat Cannot Replace

• No CMDB or asset management. Configuration items and hardware assets have no home in LiveChat. Export to a dedicated CMDB tool (Device42, Snipe-IT, or a spreadsheet for small environments).
• No problem/change/release management. These ITIL workflows must be rebuilt in another tool (Jira Service Management, ServiceNow, Freshservice) or abandoned.
• No SLA engine. SolarWinds SLA policies cannot be replicated. HelpDesk has basic SLA features (first response time, resolution time) but lacks the granularity of SolarWinds (per-priority, per-group, business hours calendars).
• No service catalog. Self-service request forms do not exist in LiveChat. HelpDesk offers basic ticket forms but not multi-step request workflows with approvals.
• Simplified schema. LiveChat's data model is intentionally flat: chats → threads → events. There is no concept of nested or relational objects.

API Rate Limit Summary

Neither platform offers a bulk import API. For large migrations (100K+ records), the import phase alone can take 2–5 days of continuous operation.

Post-Migration Tasks

Rebuild Automations

SolarWinds automation rules — triggers, escalations, SLA policies, macros — do not migrate. Rebuild them manually:

• Recreate routing rules and auto-greetings in LiveChat
• Rebuild automated workflows in HelpDesk (if adopted)
• Recreate canned responses (SolarWinds Macros → LiveChat Canned Responses)
• Update email forwarding rules to point to the new LiveChat/HelpDesk inbound address
• Document every active SolarWinds automation before cutover — create a spreadsheet with automation name, trigger condition, action, and equivalent in the target system

Wire HelpDesk for Ticket Workflows

If you still need ticket queues after the move, configure HelpDesk deliberately. LiveChat's current docs explain replacing LiveChat Tickets with HelpDesk and forwarding ticket-form messages there. That is the cleanest post-cutover pattern for teams that want LiveChat as the front door but still need ticket handling behind it. (livechat.com)

Train the Team

The shift from an ITSM interface to a chat-first interface is significant:

• Agent training on the LiveChat dashboard, chat handling, and canned responses (budget 2–4 hours per agent)
• Training on HelpDesk ticket management (if adopted)
• Updated SOPs for escalation paths (since problem/change management workflows no longer exist in-platform)
• Create a one-page reference card mapping old SolarWinds workflows to new LiveChat/HelpDesk equivalents

Monitor for Issues

For the first 2 weeks post-cutover:

• Watch for tickets with missing requester information (search for unknown-requester@migration.local)
• Check for attachments that failed to upload or render
• Verify that new incoming chats route correctly to the right groups
• Reconcile any delta records that landed in SolarWinds during the final validation window
• Monitor the dead-letter queue for patterns (same error on multiple records may indicate a mapping issue)
• Track agent adoption metrics in LiveChat (response times, chat acceptance rates) to identify training gaps

Best Practices

• Back up everything before starting. Export all SolarWinds data to CSV and store it independently, even if you are also using the API for extraction. Store backups in at least two locations.
• Run a sandbox migration first. Migrate 500 records to a LiveChat trial account. Validate the output before committing to a full run. This costs nothing and catches 80% of mapping issues.
• Migrate in stages. Users/groups → knowledge base → closed tickets → open tickets. Validate at each stage, not only at the end.
• Preserve original IDs. Store the SolarWinds incident ID as a tag or custom field in every migrated record. You will need it for traceability and debugging months later.
• Freeze system configurations. Implement a change freeze on SolarWinds Service Desk two weeks before migration. Do not allow admins to add new custom fields or change state workflows.
• Archive what does not migrate. CMDB data, change records, and problem records should be exported to a durable format (CSV + JSON) and stored for compliance. Retain for the period required by your data retention policy (typically 3–7 years for regulated industries).
• Plan for the data you are losing. Write a one-page document for your team that explicitly lists what data exists in SolarWinds but has no home in LiveChat. This prevents post-migration surprises.
• Pause other LiveChat integrations during load. Since rate limits are shared per license, chatbots, CRM integrations, and analytics tools all compete for the same 1,000-request pool. Pause them during the import window.

For more guidance on planning help desk migrations, see our help desk data migration checklist and our post-migration QA checklist.

Rollback Plan

LiveChat/HelpDesk does not offer a "delete all imported records" function. Your rollback options, from least to most disruptive:

1. Tag-based cleanup (partial rollback): If all migrated records were tagged with swsd-{id}, you can query by tag and delete records programmatically via the API. This is time-consuming at scale but preserves any new records created natively in LiveChat after cutover.
2. Parallel operation: Run both systems simultaneously for 30–90 days. Route new requests to LiveChat while keeping SolarWinds active for reference. This is the safest approach and the one we recommend.
3. Account reset (nuclear option): If the migration fails validation completely, delete the LiveChat/HelpDesk account and recreate it from scratch.
4. Recovery baseline: Maintain a full SolarWinds export (API + CSV) as your recovery baseline. Store it independently of both platforms.

Making the Decision

Migrating from SolarWinds Service Desk to LiveChat is an architectural downgrade in ITSM capability and an upgrade in real-time customer engagement. That trade-off is intentional for teams shifting from internal IT service management to customer-facing chat support. Go in with open eyes: you will lose CMDB, change management, problem management, and SLA engine capabilities that LiveChat was never designed to replace.

If your team has fewer than 20,000 records, no CMDB dependencies, and a developer who can spend 2–4 weeks on the migration, the API-based approach works. For larger environments or teams without migration experience, the engineering cost of handling both APIs, the data model translation, and the edge cases (typically $15,000–25,000 in developer time) often exceeds the cost of a managed migration service.

If your real destination is still ITSM, stop here and look at an ITSM-to-ITSM plan such as our SolarWinds Service Desk to ServiceNow guide instead. If LiveChat is one of several targets you are evaluating, our LiveChat to Help Scout migration guide covers the LiveChat data model in depth.