---
title: "Helpshift to SolarWinds Service Desk Migration: Technical Guide"
slug: helpshift-to-solarwinds-service-desk-migration-technical-guide
date: 2026-08-13
author: Raaj
categories: [SolarWinds Service Desk, Migration Guide, Help Desk]
excerpt: "Technical guide to migrating from Helpshift to SolarWinds Service Desk. Covers API extraction, field mapping, the 50K pagination ceiling, device metadata, and common failure modes."
tldr: "Helpshift Issues map to SWSD Incidents, but device metadata, bot configs, SDK-only users, and the 500-comment cap need deliberate handling. Budget 3–6 weeks."
canonical: https://clonepartner.com/blog/helpshift-to-solarwinds-service-desk-migration-technical-guide/
---

# Helpshift to SolarWinds Service Desk Migration: Technical Guide


# Helpshift to SolarWinds Service Desk Migration: Technical Guide

> [!NOTE]
> **TL;DR — Helpshift to SolarWinds Service Desk Migration**
>
> Migrating from Helpshift to SolarWinds Service Desk (SWSD) restructures a mobile-first, conversation-centric support platform into an ITIL-based IT service management system. Helpshift **Issues** map to SWSD **Incidents**, but Helpshift's flat, app-centric data model must be forced into SWSD's relational hierarchy of Sites, Departments, and Categories. Helpshift's API enforces a hard pagination ceiling at 50,000 records per query window — you must use time-based windowing for larger datasets. The SWSD API (`api.samanage.com`) uses offset pagination and requires multipart form uploads for attachments. Neither platform provides a native import/export path to the other. A typical 50,000–150,000 issue migration takes 3–6 weeks including mapping, test loads, and cutover.
>
> *Targets Helpshift REST API v1 and SWSD API v2.1 (Samanage). Last verified: Q2 2024.*

Migrating from Helpshift to SolarWinds Service Desk (formerly Samanage) is not a tool replacement. It is a structural transformation — much like a [LiveAgent to SolarWinds Service Desk migration](https://clonepartner.com/blog/blog/liveagent-to-solarwinds-service-desk-migration-technical-guide/), you are moving from a mobile-first, in-app messaging platform built for consumer apps and gaming into a full ITIL service management suite designed for internal IT and enterprise service delivery.

Helpshift's core object is the **Issue**: a chronological conversation thread between an end-user and agents, enriched with device metadata, app version info, tags, and custom issue fields (CIFs). SWSD's core object is the **Incident**: a structured ticket with priority, category, subcategory, SLA timers, and links to a relational graph of assets, CMDB configuration items, problems, and changes. The two platforms share almost no structural DNA. Every technical decision in this migration flows from that mismatch.

If your team still needs native in-app messaging, persistent player context, or mobile SDK support, stop and re-evaluate before you migrate. Those are product behaviors in Helpshift, and SolarWinds does not replace that experience.

## Why Teams Move from Helpshift to SolarWinds Service Desk

This migration typically signals one of three organizational shifts:

- **Consumer support → internal IT service management.** Companies that used Helpshift for player or app-user support now need a platform to handle employee IT incidents, asset tracking, and change management. Helpshift has no CMDB, no change management module, and no service catalog.
- **Consolidation onto an ITIL platform.** Organizations standardizing on ITIL processes need incident-problem-change linking, SLA enforcement, and approval workflows that Helpshift does not offer.
- **Outgrowing mobile-only support.** Teams that started with Helpshift's in-app SDK for a single mobile product now support multiple channels (email, portal, integrations) and need SWSD's broader intake options and reporting.

The reverse scenario — moving from SWSD to a conversation-first platform — is covered in our [SolarWinds Service Desk export guide](https://clonepartner.com/blog/blog/how-to-export-data-from-solarwinds-service-desk-methods-limits/), as well as our specific guides for migrating SWSD to [Kayako](https://clonepartner.com/blog/blog/solarwinds-service-desk-to-kayako-migration-technical-guide/) or [Dixa](https://clonepartner.com/blog/blog/solarwinds-service-desk-to-dixa-migration-technical-guide/).

## Data Model Mapping: Helpshift → SolarWinds Service Desk

The mapping is lossy by design. Helpshift is flat and conversation-oriented. SWSD is relational and process-oriented. Here is the realistic field-level mapping:

| Helpshift Object | SWSD Target | Notes |
|---|---|---|
| Issue | Incident | 1:1 mapping. Issue title → Incident name. Issue state → Incident state (requires value mapping). |
| Messages (on Issue) | Incident Comments | Each message becomes a comment. Preserve `author` and `created_at`. Agent vs. end-user distinction maps to public vs. private comments. SWSD caps comments at 500 per object. |
| Attachments | Incident Attachments | Download from Helpshift (signed URLs expire), re-upload to SWSD via multipart form data. 25 MB per-file limit in SWSD. |
| Tags | Incident Tags / Category | Helpshift tags are flat strings. SWSD categories are hierarchical (category → subcategory). Decide whether to map tags to SWSD tags (flat) or build a category tree. |
| Custom Issue Fields (CIFs) | Custom Fields on Incident | Must pre-create matching custom fields in SWSD before import. SWSD supports text, dropdown, checkbox, date, and number types. |
| Device Metadata | Custom Fields | Helpshift captures device model, OS version, battery level, carrier, network type, free space, etc. None of these have native SWSD fields. Create custom fields or flatten into a text blob. |
| App Metadata | Custom Fields | App name, app version, SDK version. Same treatment as device metadata. |
| FAQ / FAQ Sections | Solutions / Solution Categories | Helpshift FAQs map to SWSD Solutions. Section → Category mapping is straightforward. |
| User (end-user) | User (Requester) | Match on email where available. Helpshift users may lack email (SDK-only users identified by device ID). These require synthetic identifiers in SWSD. |
| Agent | Agent / User | Map by email. SWSD roles (Administrator, Agent, etc.) must be assigned manually or scripted. |
| Automation / Bots | No equivalent | Helpshift bot flows, QuickSearch Bot configurations, Smart Intent models, and automation rules do not transfer. Rebuild in SWSD's automation engine. |

> [!WARNING]
> **What does NOT migrate:** Helpshift chatbot configurations, automation rules, Smart Intent models, CSAT survey data, Analytics dashboards, and SDK integration settings have zero representation in SWSD. Export these separately for archival before decommissioning Helpshift.

### Helpshift Apps vs. SWSD Sites and Departments

In Helpshift, support queues are separated by **Apps**. A user submits an issue from an iOS game or a specific web portal, and the issue is tagged to that App. SWSD does not use Apps. It routes work based on **Sites** (geographical or logical business units) and **Departments** (IT, HR, Facilities, Customer Support).

You must decide how an "App" translates before importing anything. The most common approach is mapping Helpshift Apps to SWSD **Categories** or creating a dedicated "Customer Support" Department, using Sites to represent different product lines. If you fail to define this hierarchy first, SWSD will dump all Helpshift issues into a default unassigned queue, breaking your SLA rules and reporting.

## Extracting Data from Helpshift

Helpshift exposes a REST API at `https://api.helpshift.com/v1/{domain}/issues` for issue extraction.

**Key constraints:**

- **Authentication:** API key passed as Basic Auth (API key as username, no password). Keys are managed under Settings → APIs in the Helpshift dashboard.
- **Pagination:** Default page size is 100 issues. Maximum page size is 1,000. The API enforces a hard constraint: `page × page-size` must not exceed 50,000. If you have more than 50,000 issues, you must use time-based windowing with `created_since` or `updated_since` filters to partition extraction into batches.
- **Rate limits:** Helpshift does not publicly document rate-limit thresholds in its API reference. In practice, sustained calls above approximately 5 requests/second on the issues endpoint return HTTP 429 responses. This figure is an empirical observation from extraction runs against Helpshift instances on standard plans; behavior may vary by contract tier. Build in exponential backoff regardless.
- **Messages:** Messages for a given issue are returned as a nested array within the issue object, or via a separate `GET /issues/{id}/messages` call depending on the response layout. Always request the full layout to get message bodies and attachment URLs in a single call.
- **Attachments:** Attachment URLs in the API response are time-limited signed URLs. **Download them immediately during extraction** — do not store URLs for later retrieval. They will expire.

```python
import requests
import time

DOMAIN = "your-domain"
API_KEY = "your-api-key"
BASE_URL = f"https://api.helpshift.com/v1/{DOMAIN}/issues"

def extract_issues(created_since_ms):
    page = 1
    all_issues = []
    while True:
        resp = requests.get(
            BASE_URL,
            auth=(API_KEY, ""),
            params={
                "page": page,
                "page-size": 1000,
                "created_since": created_since_ms,
                "sort-by": "created_at",
                "sort-order": "asc",
            },
        )
        if resp.status_code == 429:
            time.sleep(int(resp.headers.get("Retry-After", 10)))
            continue
        resp.raise_for_status()
        data = resp.json()
        all_issues.extend(data.get("issues", []))
        if page >= data.get("total-pages", 1):
            break
        if page * 1000 >= 50000:
            # Hit pagination ceiling — shift time window
            last_created = all_issues[-1]["created_at"]
            return all_issues, last_created
        page += 1
        time.sleep(0.25)  # Stay under rate limit
    return all_issues, None
```

> [!TIP]
> **Handling the 50,000-record ceiling:** If your Helpshift instance has more than 50,000 issues, split extraction by `created_since` windows. Pull the first batch sorted by `created_at` ascending, record the last timestamp, then start the next window from that timestamp. This is the only reliable way to extract complete datasets from Helpshift's API. After each window completes, verify your extracted record count against Helpshift's Analytics dashboard — a mismatch indicates a missed window boundary.

For smaller validation batches, the dashboard CSV export works — but it caps manual selection at 5,000 issues and the Power BI CSV export does not include issue body text. The REST API remains the only reliable path for full-fidelity historical extraction. For a deeper source-side checklist, see [our Helpshift export guide](https://clonepartner.com/blog/blog/how-to-export-data-from-helpshift-api-limits-methods-portability/).

### Estimating Attachment Volume Before You Start

Before building your extraction pipeline, run a pre-flight audit to estimate total attachment volume. This shapes your staging infrastructure decisions:

- Pull a sample of 1,000 issues across different time periods and calculate the average attachment count per issue and average file size.
- A Helpshift instance with 100,000 issues averaging 2 attachments at 500 KB each represents approximately 100 GB of binary data to stage and re-upload.
- At 10 MB/s sustained download from Helpshift's CDN, 100 GB takes roughly 3 hours of pure download time — before any SWSD upload overhead.
- S3 staging costs for 100 GB run under $3/month, making object storage the correct choice over local disk for any migration above 20,000 issues.

These estimates inform how you size your migration instance and whether you parallelize the download phase.

## Loading Data into SolarWinds Service Desk

SWSD's REST API at `api.samanage.com` accepts incident creation via `POST /incidents.json`. Full API reference is available in the [SolarWinds Service Desk API documentation](https://apidoc.samanage.com/).

**Key constraints:**

- **Authentication:** Bearer token. Generate under Setup → Account → API Token in SWSD.
- **Pagination (reads):** Offset-based, max 200 records per page. The `X-Total-Count` response header provides total record count.
- **Rate limits:** SWSD does not publish explicit rate-limit thresholds in its public documentation. In practice, sustained writes above approximately 2 requests/second on the incidents endpoint produce throttling responses. This is an empirical observation, not a guaranteed contract limit — verify against your specific SWSD plan before building your load script.
- **Incident creation:** Wrap the payload in an `incident` key. Required fields: `name` (title), `requester` (email), and `priority`. Categories, subcategories, and custom fields are optional but strongly recommended.
- **CSV import alternative:** SWSD supports CSV imports for incidents and solutions. CSV imports can backdate `created_at` and handle core fields, but they do **not** import attachments or support updating custom fields via CSV. Teams needing higher fidelity typically seed records via CSV and enrich them through the API.

### Pre-loading Users

In SWSD, every incident must have a `requester`. Helpshift tracks users, but often with sparse data — sometimes just a device ID or an anonymous profile.

Before migrating incidents, extract all unique users from Helpshift and `POST` them to SWSD's `/api/v1/users.json` endpoint. SWSD requires a unique email address for every user record.

**For SDK-only Helpshift users without email addresses:**

- **Synthetic emails.** Generate addresses like `hs_{user_id}@noreply.helpshift.local`. This preserves the requester-to-incident relationship but creates user records that cannot receive email notifications.
- **Merge on known identifiers.** If your Helpshift implementation captured user emails via CIFs or identity verification, use those to match against existing SWSD users.
- **Assign to a generic requester.** For truly anonymous issues, assign them to a catch-all user like `anonymous-mobile@yourcompany.com`. This loses per-user history but keeps incident data intact.

Most production migrations use a combination: real emails where available, synthetic emails as fallback. Track the mapping of Helpshift User ID → SWSD User ID in a local database (SQLite or Redis). You will need this mapping table for every incident you create.

De-duplicate on email before creating users in SWSD. Failing to do so creates multiple SWSD user records for the same person, fragmenting their incident history across duplicate profiles — a defect that cannot be automatically merged post-migration.

### Creating Incidents and Preserving Timestamps

When you POST to SWSD's `/api/v1/incidents.json`, the system defaults to setting `created_at` to the moment the API call is made. This destroys your historical reporting.

To preserve historical timestamps, pass the `created_at` parameter formatted as an ISO 8601 string in your JSON payload.

> [!WARNING]
> **Admin privileges required for timestamp override:** Only SWSD accounts with Administrator privileges can override the `created_at` and `updated_at` timestamps via the API. Standard agent-level API tokens will silently ignore these fields and write the current timestamp instead, with no error returned. Ensure your migration API token belongs to a full admin account. Verify this on a test record before running bulk loads — confirm that the `created_at` value in the API response matches the value you submitted, not the wall-clock time of the request.

```bash
curl -X POST "https://api.samanage.com/incidents.json" \
  -H "X-Samanage-Authorization: Bearer YOUR_TOKEN" \
  -H "Accept: application/vnd.samanage.v2.1+json" \
  -H "Content-Type: application/json" \
  -d '{
    "incident": {
      "name": "App crash on launch - iOS 17.2",
      "description": "User reported crash after update...",
      "priority": "Medium",
      "requester": { "email": "player42@example.com" },
      "category": { "name": "Customer Support" },
      "subcategory": { "name": "Mobile App" },
      "created_at": "2023-08-01T12:00:00Z",
      "custom_fields_values": {
        "custom_fields_value": [
          { "name": "Device Model", "value": "iPhone 14 Pro" },
          { "name": "OS Version", "value": "iOS 17.2" },
          { "name": "App Version", "value": "3.4.1" },
          { "name": "Helpshift Issue ID", "value": "hs-issue-abc123" }
        ]
      }
    }
  }'
```

**Keep Helpshift's native identifiers in SWSD.** Store the original Helpshift issue ID in a dedicated custom field — not buried in free text. You will need source IDs for retries, audits, attachment repair, and delta loads. A custom field is indexed and queryable; a text blob is not.

### Migrating Threads as Comments

Helpshift is conversational — an issue is essentially a chat thread. SWSD separates the initial Incident description from subsequent Comments.

To map this accurately:

1. The first message in the Helpshift thread (usually the user's initial outreach) becomes the SWSD Incident `description`.
2. All subsequent Helpshift messages must be iterated chronologically and uploaded to SWSD's `/api/v1/incidents/{incident_id}/comments.json` endpoint.
3. Helpshift "Private Notes" must be uploaded as SWSD Comments with the `is_private` flag set to `true`. Note: once a comment is marked public in SWSD, it **cannot** be switched back to private via the API or UI.
4. The `created_at` timestamp is writable on comments — use it to preserve conversation chronology.

> [!CAUTION]
> **500-comment ceiling:** SWSD caps comments at 500 per object. Long Helpshift chat threads that exceed this limit will fail silently or partially on import. Pre-check your data: run a query against your extracted Helpshift dataset to identify any issues with more than 499 messages before you start the load. For overflow threads, store the excess transcript as an attachment or external archive and add a final summary comment explaining the cut point (e.g., "Thread truncated at 500 comments. Full transcript attached as helpshift-thread-{id}.txt").

Be aware of the API volume this creates. If a Helpshift issue has 40 messages, that requires 1 API call to create the incident and 39 calls to create the comments. A batch of 10,000 active tickets averaging 15 messages each generates approximately 140,000 API requests for comments alone — before incidents, users, or attachments. Budget your rate limiting accordingly and implement exponential backoff to handle `429 Too Many Requests` responses.

### Handling Attachments

Your migration middleware must:

1. Parse each Helpshift issue for attachment URLs during extraction.
2. Download the file immediately into temporary storage or an S3 bucket (Helpshift's signed URLs expire and cannot be regenerated after expiry without re-calling the API).
3. Upload the file to SWSD via a `multipart/form-data` request attached to the specific incident or comment where it originally appeared.

For files exceeding SWSD's 25 MB per-file limit, your script should catch the HTTP 413 rejection, upload the file to a secure external host (such as a signed S3 URL with a long expiry), and inject the external link into the SWSD comment text with a note indicating the file was too large for direct attachment.

> [!WARNING]
> **Disable notifications before bulk import.** SWSD will send email notifications to requesters and assignees for every incident and comment created via the API, unless notifications are disabled at the account level prior to import. Navigate to Setup → Notifications and disable email triggers before starting bulk loads. Re-enable after cutover verification is complete.

## Handling Device and App Metadata

This is where most Helpshift migrations lose fidelity. Helpshift automatically captures rich device context on every issue — device model, OS version, battery level, carrier, network type, free storage, SDK version, and more. SWSD has **none** of these as native fields.

You have three options:

1. **Individual custom fields in SWSD.** Create a custom field for each metadata attribute you want to preserve. This keeps data queryable and reportable but adds visual clutter to the incident form. Note: SWSD's custom field search and filter indexing runs on a nightly schedule by data center — newly created custom fields will not be searchable or filterable until the following business day. Do not schedule UAT for custom field search on the same day you create the fields.
2. **Single JSON/text blob.** Serialize all device metadata into a single custom text field. Preserves everything but makes the data unsearchable in SWSD's native UI.
3. **Selective preservation.** Pick the 3–5 metadata fields your team actually uses for triage (typically Device Model, OS Version, App Version) and discard the rest.

**Recommended approach for most teams:** Use option 3 as the primary path and option 2 as a supplemental archive. Create structured custom fields for Device Model, OS Version, and App Version — the fields most commonly used in triage and bug reports — and serialize the complete Helpshift device metadata JSON into a fourth custom text field named "Raw Device Context." This gives you queryable triage fields without discarding the full audit record.

## Migrating Helpshift FAQs to SWSD Solutions

Helpshift's FAQ system consists of **FAQ Sections** (categories) containing individual **FAQ articles** with title, body (HTML), and optional tags. SWSD's knowledge base equivalent is **Solutions**, organized by **Solution Categories**.

The mapping is direct:

- Helpshift FAQ Section → SWSD Solution Category
- Helpshift FAQ Article → SWSD Solution
- FAQ body (HTML) → Solution body (HTML supported)

Extract FAQs via `GET /v1/{domain}/faqs` and FAQ sections via `GET /v1/{domain}/faq_sections`. Helpshift also lets you export FAQs as CSV or HTML — the CSV zip includes sections, publish IDs, status, titles, content, and translations.

Watch for:

- **Image references in FAQ bodies.** Helpshift-hosted images use absolute URLs pointing to Helpshift's CDN. Once you decommission Helpshift, those URLs will return 404. Download every referenced image during extraction, re-host it (S3 or SWSD's own attachment system), and perform a find-and-replace on image URLs in the migrated Solution bodies before publishing. Broken image links in migrated articles are one of the most common post-migration defects reported after go-live.
- **Publish state.** Verify that migrated solutions are set to the correct visibility (published vs. draft) in SWSD. SWSD defaults new Solutions to draft.
- **Multilingual content.** Helpshift FAQ export preserves translated content per locale, but SWSD Solutions do not have a structured import path for multi-locale content. Each locale must be loaded separately, and SWSD's solution editor handles localization differently from Helpshift's FAQ translation model. Budget additional editorial time for any FAQ library with more than two active locales.

Treat FAQ migration as a separate workstream from the incident loader. FAQ migration is lower-risk (no SLA implications, no user dependencies) and can proceed independently on a parallel track.

## State Mapping

Helpshift states do not map 1:1 to ITIL incident states. You must build a translation matrix before importing.

| Helpshift State | SWSD State | Notes |
|---|---|---|
| New | New | Direct mapping. |
| Waiting for Agent | Assigned | Agent has context, needs to act. |
| Waiting for Customer | Awaiting Input | Waiting on requester response. |
| Resolved | Resolved | Include resolution data in payload. |
| Rejected | Closed | Map to Closed with appropriate resolution code. |

SWSD lets you configure custom incident states and define whether each state pauses or runs SLA timers. Design your state mapping before import and configure custom states in SWSD before running any loads. If you skip this step, imported tickets will be assigned the nearest default SWSD state, and your SLA timer behavior and reporting will be incorrect from day one.

For closed and resolved tickets, SWSD may require a resolution code or resolution comment depending on your account configuration. If you migrate a `Resolved` Helpshift issue without the required resolution data, SWSD will either reject the payload or accept the incident but set it to an open state — check your account's incident closure requirements before building the transformation layer.

## Cutover Strategy and Delta Syncs

Migrating 100,000+ records takes time. You cannot freeze support operations for a week while the script runs. The standard approach is a phased migration with delta syncs:

1. **Historical sync:** Extract and import all closed Helpshift issues up to a specific freeze date. This bulk move can take days and happens entirely in the background without affecting active agents.
2. **Active sync:** Migrate all currently open Helpshift issues. Agents are still working in Helpshift.
3. **Delta syncs:** Run a daily (or hourly) script using Helpshift's `updated_since` parameter. This captures new issues created and comments added to open issues, and pushes them to SWSD.
4. **Cutover:** Route new inquiries to SWSD. Run one final delta sync to catch the last messages. Agents log into SWSD.

For a more detailed walkthrough of phased cutover without support interruption, see our [zero-downtime migration guide](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration/).

### Realistic Timeline

| Phase | Duration | Activities |
|---|---|---|
| Discovery & mapping | 3–5 days | Audit Helpshift data: issue count, CIF inventory, FAQ count, attachment volume estimate (sample 1,000 issues for average attachment count and size), deactivated agent list. Define field mapping. Set up SWSD custom fields, categories, states, and user roles. |
| Script development | 5–8 days | Build extraction scripts for Helpshift API with time-window partitioning. Build transformation layer (state mapping, CIF → custom field, user ID mapping table). Build SWSD import scripts with retry logic. Handle pagination ceiling, rate limiting, attachment download to staging. |
| Test migration (dry run) | 3–5 days | Run full extraction and load against SWSD sandbox. Validate record counts against Helpshift Analytics. Verify comment ordering, attachment integrity, custom field values, and timestamp preservation. Confirm custom field search is available (allow 24 hours after field creation). |
| Delta & corrections | 2–3 days | Fix mapping errors found in test run. Handle edge cases: missing emails, oversized attachments, threads exceeding 500 comments, encoding issues (UTF-8 vs. Latin-1 in older Helpshift data), inactive agent references. |
| Production cutover | 1–2 days | Disable SWSD notifications. Run final delta extraction. Load into production SWSD. Verify record counts. Re-enable notifications. Switch agent workflows. |
| Post-migration validation | 2–3 days | Spot-check migrated incidents. Validate SLA timer behavior against state mapping configuration. Confirm FAQ image rendering. Verify custom field search indexing has completed. |

**Total: 3–6 weeks** depending on issue volume, attachment density, and custom field complexity.

## Common Failure Modes

These are the recurring failure points in Helpshift-to-SWSD migrations, ordered by frequency of occurrence:

1. **Hitting the 50,000 pagination ceiling without time windowing.** Your extraction silently stops at 50,000 records. The API returns success; you simply receive no further pages. Always verify total extracted count against Helpshift's analytics dashboard before declaring extraction complete.

2. **Expired attachment URLs.** If your extraction stores Helpshift's signed attachment URLs for later retrieval rather than downloading files immediately, those URLs will be expired by the time your import script runs. There is no API endpoint to regenerate expired signed URLs without re-fetching the parent issue.

3. **Silent data loss on custom fields.** SWSD's API does not return an error when you submit custom field values for fields that do not exist in the account. The incident is created successfully, and the custom field data is silently discarded. Always pre-create all custom fields in SWSD before running any import loads, and validate custom field delivery on a 10-record test batch before scaling.

4. **Timestamp override ignored due to insufficient privileges.** An agent-level API token cannot override `created_at` or `updated_at`. SWSD accepts the payload without error but writes the current timestamp. The failure is invisible unless you explicitly compare submitted vs. returned timestamps on test records. Use an admin-level token and verify on a test record before bulk import.

5. **Markdown vs. HTML.** Helpshift stores issue body text as plain text or markdown depending on the intake channel. SWSD renders descriptions and comments in a rich text editor that expects HTML. Submitting raw markdown — including `**bold**`, `` `code` ``, and `[link](url)` syntax — into SWSD will render as literal characters. Convert markdown to HTML in your transformation layer before submitting to SWSD.

6. **Comment ordering corruption.** If you import messages without setting `created_at` on each comment, SWSD assigns the current wall-clock time to all of them. Comments for a multi-day conversation will appear to have been created within seconds of each other, and chronological ordering in the SWSD UI will be incorrect.

7. **Orphaned agent references.** Deactivated Helpshift agents — people who left your company — have profiles that no longer exist as active users. Attempting to assign historical tickets to deactivated agent emails in SWSD throws an error. Compile a list of deactivated agents during discovery and map their historical activity to a "System Migrator" service account, prepending the original agent name in the comment body (e.g., `[Migrated from Helpshift — Agent: Jane Smith]`).

8. **Duplicate users from missing deduplication.** Creating SWSD user records without deduplicating on email first produces multiple user profiles for the same person. SWSD does not auto-merge duplicate users. Post-migration cleanup of duplicate users requires manual reconciliation or a separate API-based merge script.

9. **Notification spam on bulk import.** Without disabling notifications first, SWSD sends email to every requester and assignee for every incident and comment created during the import. For a 100,000-issue migration, this generates millions of notification emails hitting live user inboxes. This cannot be recalled after the fact.

10. **Threads exceeding the 500-comment cap.** High-volume Helpshift issues — particularly those involving long back-and-forth escalations or bot conversations — can have hundreds of messages. SWSD will reject comment creation after the 500th comment with an HTTP 422 error. If you don't pre-check for this, your import script will encounter errors mid-thread and leave some incidents with partial conversation histories.

## What You Gain and What You Lose

**You gain in SWSD:**
- Full ITIL process support: incident → problem → change → release linking
- CMDB and asset management with CI relationship tracking
- SLA policies with breach timers, escalation rules, and pause conditions
- Service catalog with approval workflows and fulfillment steps
- Enterprise reporting with scheduled exports
- Self-service portal with email-to-ticket intake and knowledge base integration

**You lose from Helpshift:**
- In-app SDK messaging (native mobile support widget, iOS and Android)
- Chatbot and automation flows — these must be rebuilt from scratch in SWSD's rule engine, which handles routing and SLA escalation but not conversational bot logic
- Automatic device-level metadata capture on every issue
- Asynchronous messaging UX familiar to mobile app users
- CSAT survey data and analytics history — export before decommissioning
- Smart Intent and AI classification models

This trade-off is acceptable when the destination is internal IT service management. It is a harder sell if you still need consumer-facing mobile support — SWSD does not have a mobile SDK or in-app messaging widget.

## When NOT to Migrate

Do not move from Helpshift to SWSD if:

- **Your primary use case is consumer mobile app support.** SWSD is designed for internal IT service delivery, not consumer-facing in-app chat. There is no SWSD mobile SDK equivalent.
- **You rely heavily on Helpshift's chatbot automation.** SWSD's automation engine handles ticket routing and SLA escalation, not conversational bot flows. Migrating means rebuilding all bot logic in a different paradigm.
- **You need to preserve Helpshift's CSAT and analytics data as live reports.** This data does not migrate to SWSD. Export it to CSV before decommissioning and archive it externally.
- **Your users don't have email addresses.** SWSD's user model is email-centric. A large population of anonymous mobile users identified only by device ID will require synthetic email generation and will not be able to use SWSD's self-service portal.
- **You need to run parallel consumer and internal IT support workflows.** If your team supports both external app users and internal employees, consider running both platforms in parallel — integrate them via API and move only the escalation or back-office record layer to SWSD, leaving Helpshift as the consumer intake surface.

## Decision Framework

Use the following criteria to determine whether this migration is appropriate:

| Condition | Recommendation |
|---|---|
| Primary use case is internal IT support for employees | Migrate to SWSD |
| Need ITIL incident-problem-change linking | Migrate to SWSD |
| Still need in-app mobile SDK for consumer users | Do not migrate; evaluate parallel operation |
| Chatbot/bot flows are critical to support volume | Do not migrate until SWSD automation is verified sufficient |
| Large population of email-less SDK users | Proceed with synthetic email strategy; validate user model first |
| CSAT/analytics history must be live in new platform | Export and archive; it will not be live in SWSD |
| Under 50,000 total issues | Standard extraction; no time-windowing required |
| Over 50,000 total issues | Time-windowed extraction required; budget additional script complexity |

## Making the Call

A Helpshift-to-SWSD migration is a platform-class change, not a vendor swap. You are taking fluid, unstructured conversations and forcing them into a rigid, auditable ITIL framework. The migration is technically tractable once you account for the pagination ceiling, the email-less user problem, the 500-comment cap, the timestamp privilege requirement, and the device metadata gap — but each of these failure modes is silent. They do not produce loud errors during import; they produce quietly incorrect data that surfaces weeks later in reporting discrepancies and missing attachments.

The deciding factor is organizational: are you shifting from consumer support to internal IT, or consolidating onto a single ITSM platform? If yes, SWSD is a reasonable target. If you still need mobile-first consumer support alongside ITSM, run both platforms in parallel rather than forcing Helpshift's use case into SWSD's data model.

Keep an untouched raw archive of your complete Helpshift extraction. It is the source of truth you return to when a transformed field value, comment order, or attachment reference is questioned after go-live.

For more on [exporting data from Helpshift](https://clonepartner.com/blog/blog/how-to-export-data-from-helpshift-api-limits-methods-portability/) or [help desk migration best practices](https://clonepartner.com/blog/blog/best-practices-for-help-desk-data-migration/), see our related guides.

> Need help migrating from Helpshift to SolarWinds Service Desk? We handle API limits, delta syncs, and data transformation so your team can focus on operations. Book a 30-minute scoping call.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### What is the Helpshift API pagination limit for exporting issues?

Helpshift's API enforces a hard ceiling: page × page-size cannot exceed 50,000. Maximum page-size is 1,000. For datasets larger than 50,000 issues, you must use time-based windowing with the created_since filter to partition extraction into batches.

### How do you handle Helpshift users without email addresses in SolarWinds Service Desk?

SWSD requires a unique email for every user. For SDK-only Helpshift users with no email, generate synthetic addresses (e.g., hs_{user_id}@noreply.helpshift.local). Use real emails where Helpshift captured them via identity verification or custom issue fields.

### Can I preserve original ticket creation dates when migrating to SolarWinds Service Desk?

Yes, but you must pass the created_at parameter formatted as an ISO 8601 string in your API payload, and the API token must belong to an Administrator account in SWSD. Standard agent roles cannot override timestamps.

### How do I handle Helpshift attachments during the migration?

Helpshift attachment URLs are time-limited signed URLs that expire. You must download the files during extraction into temporary storage, then upload them to SWSD using multipart/form-data requests attached to the specific incident or comment.

### Can SolarWinds Service Desk preserve every Helpshift chat message?

Not always. SWSD caps comments at 500 per object. Long Helpshift threads exceeding this limit need summarization or transcript archiving as an attachment, with a final comment explaining the cut point.