Front to Helpshift Migration: The Complete Technical Guide

Front to Helpshift Migration: The Complete Technical Guide

Front is an email-first collaborative inbox. Helpshift is a mobile-first, in-app customer service platform built for apps and games. Moving between them is not a format conversion — it is a full architecture translation.

Neither vendor offers a connector for a Front to Helpshift migration. Every record — conversations, messages, internal comments, contacts, tags, custom fields, attachments — must be extracted from Front's REST API, structurally transformed, and loaded through Helpshift's REST API.

This is not a CSV export-and-import job. It is a schema translation project with two rate-limited pipes, at least one unresolvable data fidelity constraint on standard plans, and several architectural decisions that must be made before a line of code is written.

This guide covers the full technical path: data model mapping, API constraints on both sides, extraction mechanics, loading sequence, error taxonomy, edge cases, and realistic timelines. All API behaviors are verified against Front's Core API and Helpshift REST API v1 as documented in their respective developer references.

Disclosure: This guide is published by ClonePartner, a company that offers managed migration services. We have a commercial interest in one of the approaches described below. We've aimed to provide technically accurate guidance regardless of which approach you choose.

Why Teams Move from Front to Helpshift

Front unifies email, SMS, chat, and social channels into shared inboxes with rules-based routing, internal comments, and CRM-like contact management. It is built for teams that treat email as their primary support channel.

Helpshift is built for mobile-first and in-app support. It is heavily used in gaming and mobile app environments, providing native SDK integrations for iOS, Android, Unity, and Unreal Engine, plus a bot framework designed for deflection-heavy support models.

Common reasons for this migration:

• Mobile-first support model. Teams shifting from email-centric support to in-app messaging need Helpshift's native SDK integrations. Front has no equivalent SDK.
• Device-level context. Helpshift collects device metadata out-of-the-box via its SDK — OS type, app version, device type, battery level, and network state — context that Front does not capture natively.
• Bot-first automation. Helpshift's native bot framework and issue automation engine are designed for high-volume, deflection-heavy models where most queries never reach a human agent.
• Consolidation. Teams already using Helpshift for one product line want to bring all support under one roof.

Front vs. Helpshift: Data Model Differences

Understanding the structural gap between these two platforms is the prerequisite for planning a migration. They are not two versions of the same thing.

SDK Issues vs. Email Issues: A Critical Architectural Decision

This distinction is absent from most migration guides and it matters. Helpshift distinguishes between issues created through the in-app SDK and issues created through email. They have different structural properties:

• SDK-originated issues carry device metadata (OS, app version, device ID), a user identity resolved through the SDK, and a channel context of in-app.
• Email-originated issues carry an email address as the primary identity and are associated with an email-configured app.

A Front email conversation imported as a Helpshift email issue preserves the email-thread model and maps cleanly to Front's structure. Importing it as an SDK issue is structurally incorrect — device fields will be empty, SDK identity resolution will not apply, and automations configured to trigger on SDK device properties will not fire.

Decision rule: Import Front email conversations as Helpshift email issues by associating them with an email-configured Helpshift app. Do not attempt to backfill them as SDK issues. If you are migrating because you are launching an SDK integration for future traffic, keep historical email imports in an email-configured app and create a separate SDK app for new traffic.

Status Mapping

Front's status model is simpler. After enabling ticket statuses, the three default statuses are Open, Waiting, and Resolved. New conversations come in as Open, previously Archived conversations display as Resolved, and previously Snoozed conversations display as Waiting.

Helpshift has seven issue statuses: New Issue (not yet assigned or replied to), New Issue for Agent (assigned, not yet replied to), Waiting for Agent, Agent Replied, Pending Reassignment, Resolved, and Rejected.

A practical mapping:

Custom Fields → Custom Issue Fields (CIFs)

Front supports custom fields on conversations with types including text, number, enum (dropdown), boolean, and date. Each Helpshift CIF combines three parts: the label (identifying the category), the datatype (how the UI represents it, such as a dropdown), and the value (the datapoint itself, which can be a unique identifier or a boolean).

Before migrating data, you must pre-create every CIF in Helpshift's dashboard. CIF keys are system-generated — you cannot set them via API. Your migration script must maintain a mapping table between Front custom field names and Helpshift CIF keys (which take the form cif_dropdown_01, cif_string_02, etc.).

Type conversion notes:

• Front text → Helpshift string CIF: direct mapping
• Front number → Helpshift number CIF: verify decimal precision
• Front enum / dropdown → Helpshift dropdown CIF: all option values must be pre-created in the CIF definition; loading a value not in the dropdown will fail
• Front boolean → Helpshift boolean CIF: direct mapping
• Front date → Helpshift date CIF: verify timestamp format consistency (Front uses Unix ms; confirm Helpshift CIF date format)

The Account Gap

Front has a first-class Account object. Accounts represent external companies, and matching email domains can auto-associate contacts to those accounts. Helpshift has no equivalent — its first-class objects are issues, users/User Hub profiles, apps, FAQs, and agents.

In practice, Front account data usually gets flattened into custom user fields or CIFs, or it stays mastered in your CRM. This is a design choice you must make before you touch production data. There is no Helpshift workaround that replicates domain-based auto-association.

Migration Approaches: Three Options

Option 1: Manual Re-creation

Best for: Fewer than 200 conversations, no compliance requirement to preserve history.

Export Front's analytics messages CSV, which includes sender, recipient, timestamps, tags, and a body extract limited to 200 characters. Have agents manually re-file critical conversations as new Helpshift issues.

Limitation: You lose full message bodies, attachments, internal comments, and custom field values. Only viable when the historical record does not matter.

Option 2: API-Led DIY Migration

Best for: Engineering teams with API integration experience and 1,000–50,000 conversations.

Build a custom ETL pipeline: extract from Front's Core API, transform the data model, load via Helpshift's REST API. This is the most common approach for teams that want full control. The rest of this guide covers the technical detail for this option.

Option 3: Managed Migration Service

Best for: Teams with 10,000+ conversations, complex CIF schemas, compliance requirements, or no available engineering bandwidth.

A managed service handles extraction, transformation, loading, validation, and error recovery. This is where ClonePartner operates — we use the same playbook described below, backed by pre-built infrastructure for both APIs.

Step 1: Extract Data from Front

Front's Core API is your primary extraction tool. It allows you to read, create, update, and delete a wide range of data across Front's various entities, from Contacts to Comments to Tags, and is the right choice for programmatic syncing, export, or modification of Front data.

Authentication

Front uses Bearer token authentication. Generate an API token from Settings → Developers → API Tokens. OAuth is available for partner integrations but unnecessary for a one-time migration.

Scope: Shared vs. Private Inboxes

Start with scope, not code. Front search results are limited by the API token's scope. Shared-resource tokens can search team inboxes. Private-resource access depends on token scope and whether the teammate or admin has allowed API access to personal data.

Front's manual support export does not include individual inbox conversations or contact data. If customer history lives in personal inboxes, a shared-inbox export alone is incomplete. Verify your token covers every inbox you need before writing extraction logic.

Front API Rate Limits

This is the primary bottleneck during extraction. Front's API rate limit starts at 50 requests per minute on the base plan and varies by tier. Rate limits are enforced on a per-company basis, not per token — multiple tokens running in parallel consume the same quota pool.

Front also applies tighter resource-specific limits on heavier endpoints:

• Analytics endpoints: ~1 request/second
• Conversations and messages: ~5 requests per resource per second
• Search conversations: capped at approximately 40% of your global rate limit

If you send subsequent requests before the Retry-After window expires, the delay resets and slides further into the future. Aggressive retry loops make throttling worse, not better. Implement exponential backoff with jitter, not fixed sleep intervals.

Practical throughput estimate: On a Starter plan (50 req/min), extracting a conversation with 10 messages and 2 comments requires approximately 13 API calls (1 get conversation + 1 list messages + 10 message fetches + 1 list comments). That gives you roughly 3–4 complete conversations per minute. For 10,000 conversations, expect 40–50 hours of extraction time at the base tier.

Front sells API rate limit add-ons that provide 300 additional requests per minute per add-on purchased. Pricing is not published publicly; contact Front's sales team. For large migrations, the cost of a rate limit add-on for one month is typically less than the engineering cost of waiting out base tier limits.

Extraction Order

1. Inboxes — GET /inboxes to map inbox IDs to names
2. Tags — GET /tags to build the tag reference table
3. Contacts — GET /contacts to extract all contact records with handles
4. Conversations — GET /conversations per inbox, with cursor pagination
5. Messages — GET /conversations/{id}/messages for each conversation
6. Comments — GET /conversations/{id}/comments for internal notes
7. Attachments — Download each attachment URL from message bodies immediately (URLs expire)

import requests
import time
import random
 
BASE_URL = "https://api2.frontapp.com"
HEADERS = {"Authorization": "Bearer YOUR_API_TOKEN"}
 
def get_paginated(endpoint):
    url = f"{BASE_URL}{endpoint}"
    results = []
    while url:
        resp = requests.get(url, headers=HEADERS)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            # Add jitter to avoid synchronized retry storms
            time.sleep(retry_after + random.uniform(0, 5))
            continue
        if resp.status_code >= 500:
            time.sleep(10)
            continue
        data = resp.json()
        results.extend(data.get("_results", []))
        # Use returned next link — do NOT infer from record count
        url = data.get("_pagination", {}).get("next")
        time.sleep(1.2)  # Stay under per-second burst limits
    return results
 
conversations = get_paginated(
    "/conversations?q[statuses][]=assigned&q[statuses][]=unassigned&q[statuses][]=archived"
)

Pagination Gotcha

Paginate until _pagination.next is null, not until a page returns fewer rows than the requested limit. The default page size is 50, the max is 100, and deleted resources can cause pages to contain fewer rows than requested even when more data exists. Build your extractor around the returned next link, not around record counts.

For more detail on Front's export capabilities and limitations, see our Front data export guide.

Step 2: Download and Stage Attachments

Front messages include attachment URLs as direct download links. These URLs are temporary — they expire. During extraction:

1. Download every attachment immediately when processing each message
2. Check the MIME type — Helpshift restricts certain file types and enforces a 25 MB per attachment size limit
3. Store locally or in cloud storage (S3, GCS) with a deterministic naming convention: {front_conversation_id}/{front_message_id}_{attachment_index}.{ext}
4. Record the mapping: {front_message_id}_{attachment_index} → local_path

Inline images in HTML email bodies are a separate problem. Front email messages may contain Base64-encoded inline images or cid: references embedded in the HTML. These are not listed as attachments in the API response — they are embedded in the HTML body. Your HTML parser must identify and extract them separately before stripping the HTML.

Attachment downloads count against Front's API rate limits. Factor this into your throughput calculations. A conversation with 3 messages, each containing 2 attachments, adds 6 additional rate-limit-consuming requests.

Step 3: Transform the Data Model

This is where the real engineering work happens. You are translating between two fundamentally different schemas.

Conversations → Issues

Each Front conversation becomes one Helpshift Issue. Map the following:

The Timestamp Fidelity Problem

This is the most consequential unresolved constraint in a Front-to-Helpshift migration. Helpshift's standard Create Issue API defaults created_at to the time of the API call. If you are migrating conversations from 2021 and loading them today, all issues will appear in Helpshift as if they were created today unless you have access to a historical import endpoint.

What is confirmed: The public Helpshift REST API does not document a created_at override parameter on the Create Issue endpoint for standard plans.

What to do:

1. Contact your Helpshift account manager before starting migration to ask explicitly whether historical created_at timestamps can be set via API. Some enterprise agreements include this capability through a separate bulk historical import endpoint.
2. If not available on your plan, implement the canonical workaround: prepend the original timestamp to the message body (e.g., [Originally created: 2021-08-14 09:23 UTC]) and store front_created_at in a dedicated CIF.
3. Test agent attribution and message ordering with a representative 50-conversation sample before committing to a full migration run.

Do not assume historical timestamps are preserved. Verify explicitly with Helpshift support before your extraction run.

Contacts → User Profiles

Front contacts have handles (email, phone, Twitter, etc.). Helpshift user profiles use identities (user ID, email, device ID).

The User Hub Bulk APIs can be used to import end users' data into Helpshift asynchronously via bulk action tasks. The limit is 10,000 payloads per request.

Supported Helpshift identities include uid, email, phone_number, facebook_id, discord_id, whatsapp_id, and several gaming-platform identifiers. This aligns well with Front's email and phone handles, partially with Facebook, and poorly with Front's Twitter, Intercom, Smooch, and custom handles.

For unsupported handle types: Preserve them in custom user fields (custom-properties) so they remain searchable after cutover. Do not discard them — they may be needed for deduplication during delta syncs or for subject access requests.

{
  "task_type": "create_core_profiles",
  "payload": [
    {
      "email": "customer@example.com",
      "name": "Jane Doe",
      "custom-properties": {
        "front_contact_id": "crd_abc123",
        "front_twitter_handle": "@janedoe",
        "front_intercom_id": "ic_789"
      }
    }
  ]
}

HTML to Plain Text Conversion

Front stores email threads as rich HTML. Helpshift renders messages inside iOS and Android apps. If you push raw HTML into a Helpshift issue via the API, the mobile SDK will display raw HTML tags to the end user.

You must parse the Front HTML and convert it. Recommended approach:

1. Strip non-content elements first: Remove <style>, <script>, <head>, and HTML comments entirely.
2. Extract inline images — identify <img> tags with src="data:image/..." (Base64) or cid: references and extract them as separate attachments before stripping.
3. Handle email threading artifacts: Strip quoted reply blocks — the "On [date], [user] wrote:" sections and the blockquoted content beneath them. For historical records, these blocks duplicate content already captured in earlier messages and make issues unreadably long. Use regex patterns targeting common email client quoting signatures (On .* wrote:, From:.*Sent:.*To:.*Subject:).
4. Convert to plain text or markdown: Use html-to-text (Node.js) or beautifulsoup4 + markdownify (Python). If Helpshift's API accepts a markdown subset (bold, links, lists), markdown is preferable to plain text for readability.
5. Preserve raw HTML artifact: Store the original HTML in a CIF or external storage if the original format has legal or training value.

What Helpshift's API accepts: Test your target Helpshift app to determine whether the message-body field renders markdown or strips it to plain text. This varies by app configuration and channel type.

Agent Mapping and Failure Mode

Front conversations can be assigned to agents identified by email. Helpshift agents are identified by internal agent IDs.

Pre-migration requirement: Export all Front agent emails (GET /teammates) and verify each one maps to an existing Helpshift agent. Build a lookup table: {front_teammate_email} → {helpshift_agent_id}.

What happens on mismatch: If a Front agent email does not have a corresponding Helpshift agent, the Create Issue API call will fail with a 4xx error if you pass the unresolvable agent ID. If you pass no assignee, the issue loads as unassigned. The safer default is to load unresolvable assignments as unassigned and flag them in your migration ledger for manual reassignment.

Former employees: Front conversations assigned to teammates who have since left the company are common in historical data. Decide in advance: map to unassigned, map to their manager, or map to a dedicated "Historical Import" agent account. Document the decision.

Internal Comments → Private Notes

Front's internal comments are a first-class object type with their own endpoint, timestamps, and author attribution. Helpshift does not have a directly equivalent "comment" object on Issues.

Your options:

1. Append as private/internal messages — if Helpshift's Add Message API supports an internal flag during issue creation. Test this in sandbox first; behavior varies by Helpshift plan and configuration.
2. Concatenate into a "Migration Notes" CIF — preserves the data but loses threaded context and per-comment timestamps.
3. Drop them — only if internal comments are not compliance-relevant.

@mentions in Front comments will lose their link unless you resolve Front teammate IDs to Helpshift agent names during transformation. Strip the @mention markup and replace with the agent's display name as plain text.

Inbox → App Mapping

Helpshift requires every issue to be associated with an app_id. Front has no concept of an "App," so you must define a routing layer:

• support@company.com (Front Inbox) → App ID: 12345 (Helpshift "Email Support" App — email-configured)
• billing@company.com (Front Inbox) → App ID: 67890 (Helpshift "Billing" App — email-configured)

Decide whether Front inboxes represent brands, products, teams, or routing rules. That determines whether they become Helpshift apps, queues, tags, or CIF values. All apps created for historical email imports should be email-configured, not SDK-configured (see SDK vs. Email distinction above).

Step 4: Load Data into Helpshift

Helpshift API Rate Limits

The Helpshift REST API does not publish specific rate limit numbers in its public documentation in the same way Front does. This asymmetry is a real operational constraint.

What is known:

• The User Hub Bulk API processes requests asynchronously — you submit a bulk task and poll for completion. There is no documented RPM ceiling on task submission, but the system has internal throughput limits on task execution.
• The Issues API (Create Issue, Add Message) operates synchronously. Helpshift recommends coordinating with their team to establish a safe RPM target before running large migrations.
• In practice, teams report sustainable throughput of 60–120 Create Issue requests per minute on standard enterprise plans without triggering throttling, but this is not contractually documented and varies by plan.

Recommendation: Before your production migration run, contact Helpshift support to establish your safe RPM ceiling in writing. Run a 500-issue pilot at increasing RPM (30, 60, 90, 120) and monitor for 429 or 503 responses. Use the lowest RPM that completes without errors as your production rate.

Pre-Migration Setup Checklist

Before loading any data:

1. Create all Custom Issue Fields — CIFs allow you to organize Issues based on categories using fields made up of a label and a type: number, date, string, dropdown, boolean, etc. All option values for dropdown CIFs must be populated before any data loads.
2. Record all CIF keys — Helpshift generates internal keys like cif_dropdown_01; you need the complete mapping table before writing any transformation code.
3. Create all tags that exist in Front.
4. Create or map all agents — Build and verify the {front_teammate_email} → {helpshift_agent_id} table.
5. Create and configure apps — Map Front inboxes to Helpshift apps; ensure email-inbox-sourced apps are email-configured.
6. Confirm timestamp behavior — Verify with Helpshift whether created_at can be overridden on your plan.
7. Set up migration ledger — A local SQLite database or equivalent tracking front_conversation_id → helpshift_issue_id plus load status.

Loading Sequence

For each transformed conversation:

1. Import User Profiles — Bulk import via User Hub Bulk APIs (up to 10,000 per request); wait for task completion before referencing user IDs
2. Create the Issue — POST to the Create Issue endpoint with app_id, title, and the initial customer message
3. Append Messages — Add remaining messages in strict chronological order via the Add Message API
4. Add Private Notes — Convert Front comments to private notes
5. Upload Attachments — Re-upload per message during message creation; do not batch-upload after the fact
6. Apply Tags and CIFs — Update issue metadata
7. Set Final Status — Set the issue state after all messages are loaded

import requests
 
HS_BASE = "https://api.helpshift.com/v1/YOUR_DOMAIN"
HS_AUTH = ("YOUR_API_KEY", "")
 
def create_issue(title, message_body, author_email, tags, cifs, app_id):
    payload = {
        "title": title,
        "message-body": message_body,
        "author-email": author_email,
        "tags": tags,
        "custom-fields": cifs,
        "app-id": app_id
    }
    resp = requests.post(f"{HS_BASE}/issues", json=payload, auth=HS_AUTH)
    resp.raise_for_status()
    return resp.json()
 
def add_message(issue_id, message_body, author_email, is_private=False):
    payload = {
        "body": message_body,
        "author-email": author_email,
        "is-private": is_private
    }
    resp = requests.post(
        f"{HS_BASE}/issues/{issue_id}/messages",
        json=payload,
        auth=HS_AUTH
    )
    resp.raise_for_status()
    return resp.json()

There is currently no documented hard limit on the total number of issues the Create Issue API will accept. However, coordinate with Helpshift's team before running a migration of 10,000+ issues to agree on a safe daily throughput ceiling.

Idempotency

Maintain a local SQLite database or Redis instance to track the mapping between front_conversation_id and helpshift_issue_id, plus load status (pending, created, messages_loaded, complete, failed). If your script crashes mid-run, you can resume without creating duplicate issues. This mapping table is also your audit trail for post-migration validation and compliance queries.

CREATE TABLE migration_ledger (
    front_conversation_id TEXT PRIMARY KEY,
    helpshift_issue_id TEXT,
    status TEXT DEFAULT 'pending',
    message_count_front INTEGER,
    message_count_helpshift INTEGER,
    error_message TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Helpshift's 50K Row Pagination Ceiling

If you need to verify loaded data or cross-reference during validation, note that the page and page-size parameters together cannot exceed a product of 50,000. If you keep the page-size at 1,000, you can fetch 50,000 issues by modifying the page parameter.

For datasets larger than 50K issues, use time-range filtering with created_since and created_until parameters combined with sort-by=creation-time to window your queries and iterate through the complete dataset in chunks.

Helpshift API Error Taxonomy

This is where most migration scripts fail silently. Common Helpshift API errors and their recovery actions:

Silent failures to watch for:

• Tags that don't exist in Helpshift are silently dropped (no error returned) — verify tag pre-creation and spot-check tag counts post-load.
• User profiles that fail bulk creation will still return a 200 on the task submission — poll the task status endpoint to confirm actual success before creating issues linked to those users.

Step 5: Delta Sync and Cutover

Migrating tens of thousands of conversations through rate-limited APIs takes days. During this time, your team is still working in Front. You cannot do a hard cutover without a delta sync strategy.

Delta Sync Implementation

Front supports two mechanisms for capturing changes during the migration window:

Option A: Polling (simpler, sufficient for most migrations)

import sqlite3
from datetime import datetime, timezone
 
def get_updated_conversations(since_timestamp):
    """
    Fetch conversations updated since last sync run.
    Front API: updated_after is a Unix timestamp in seconds.
    """
    endpoint = f"/conversations?q[updated_after]={int(since_timestamp)}"
    return get_paginated(endpoint)
 
def delta_sync():
    conn = sqlite3.connect("migration_ledger.db")
    cursor = conn.cursor()
 
    # Get last sync timestamp
    cursor.execute("SELECT MAX(updated_at) FROM migration_ledger WHERE status='complete'")
    last_sync = cursor.fetchone()[0] or 0
 
    updated_conversations = get_updated_conversations(last_sync)
 
    for conv in updated_conversations:
        front_id = conv["id"]
        cursor.execute(
            "SELECT helpshift_issue_id, status FROM migration_ledger WHERE front_conversation_id=?",
            (front_id,)
        )
        row = cursor.fetchone()
 
        if row is None:
            # New conversation created after initial sync started
            load_new_issue(conv)
        elif row[1] == 'complete':
            # Existing issue — sync new messages only
            sync_new_messages(front_id, row[0], last_sync)
 
    conn.commit()
    conn.close()

Option B: Webhooks (lower latency, more complex)

Register a Front webhook for conversation.updated and message.created events via POST /webhooks. Each webhook payload includes the conversation ID, event type, and timestamp. Use this to trigger near-real-time sync during the cutover window.

Deduplication is essential: a webhook event for a conversation that is also being processed by your bulk sync run will cause a race condition. Implement a distributed lock (Redis SETNX or equivalent) per front_conversation_id before processing either path.

The Cutover Sequence

1. Initial Sync: Run the ETL pipeline on all historical Front data up to a specific cutover timestamp (T₀). This moves approximately 95% of your data.
2. Delta Syncs: Run every 4–8 hours, querying Front for conversations with updated_after > last_run_timestamp.
3. 48-Hour Pre-Cutover Window: Increase delta sync frequency to every hour. Notify agents that the cutover is imminent.
4. The Freeze (T₁): Pick a low-traffic window (Saturday 2–4 AM local time is typical). Route DNS/MX records and support forms away from Front and into Helpshift. Simultaneously, pause new Front webhooks if registered.
5. Final Delta: Run the script one last time from T₀ to T₁ to catch all activity during the migration window.
6. Validation Sprint: Run the validation checklist (see below) before declaring go-live.
7. Go Live: Switch live email, web, or SDK traffic to Helpshift. Monitor automations closely during the first full support shift.

Run a Sample Migration First

Before the full backfill, test with a representative set of 100–200 conversations that covers:

• Email-heavy threads (10+ messages)
• Multi-recipient conversations
• Comments with @mentions
• Conversations with attachments (including inline images)
• Tagged conversations
• Conversations with all CIF types (dropdown, date, boolean, number, string)
• At least one account-linked contact
• At least one conversation assigned to a former employee

Validate not just record counts, but agent readability — does the migrated data make sense to a human support agent looking at it in Helpshift's UI?

Validation Checklist

After loading, validate before cutover:

• Record count match — Total conversations in Front = Total issues in Helpshift (accounting for any intentional scope exclusions)
• Message count per issue — Spot-check 50+ conversations for message parity; include some with 10+ messages
• Attachment verification — Confirm attachments are accessible, not corrupted, and under the 25 MB limit
• Tag coverage — All Front tags appear in Helpshift; spot-check 20+ conversations for tag accuracy (remember: missing tags fail silently)
• CIF values — Custom field data populated correctly; verify each CIF type including dropdowns with specific option values
• Status accuracy — Resolved conversations are Resolved in Helpshift; open ones are New or New for Agent
• Agent assignments — Assigned conversations map to the correct Helpshift agents; unresolvable assignments are flagged in ledger
• Timestamp ordering — Messages within each issue appear in correct chronological order
• Contact linkage — Issues are linked to the correct user profiles; verify User Hub bulk task completion status
• Private note visibility — Front comments loaded as private notes are not visible to end users in Helpshift
• App assignment — Issues are associated with the correct Helpshift apps; email issues are in email-configured apps
• Migration ledger completeness — No pending or failed status rows without documented resolution

Realistic Timeline Estimates

These estimates include mapping, scripting, testing, dry runs, delta syncs, and cutover. Extraction time can be reduced significantly by purchasing Front API rate limit add-ons (300 additional req/min per add-on). At 350 req/min (base + one add-on), 10,000 conversation extraction drops from ~50 hours to ~7 hours.

Edge Cases and Failure Modes

Multi-Recipient Email Threads

Front conversations can have multiple recipients. Helpshift issues expect a single primary end-user. Pick a canonical end-user rule before writing transformation code — typically the earliest customer sender (excluding internal agent emails). If one Front thread genuinely mixes separate customers, split it into separate Helpshift issues rather than merging unrelated identities into one issue.

Conversations with 100+ Messages

Front conversations can have hundreds of messages. When loading into Helpshift, messages must be added sequentially to preserve chronological order. A conversation with 150 messages requires 150 sequential API calls. At 60 req/min, that is 2.5 minutes per conversation. A single high-volume account with 200 such conversations adds ~8 hours to your loading time.

Multi-Channel Conversations

Front conversations can span email, SMS, WhatsApp, and social channels within a single thread. Helpshift Issues are single-channel. Import multi-channel Front conversations as single Helpshift Issues with a front_channel_mix CIF noting the original channel types. This preserves the data without forcing a Helpshift architecture that doesn't exist.

Merged Conversations

Front allows conversation merging. The resulting conversation has messages from different original senders. Import the merged conversation as-is — Helpshift has no merge concept, so the merged state is the canonical record. Store the original constituent conversation IDs in a CIF for traceability.

Bot Transcripts

If Front integrations include chatbot messages (via custom channels or integrations), these appear as regular messages in the API. Map bot-authored messages to a dedicated Helpshift bot agent or tag them with migrated-bot-message so they are identifiable post-migration and excluded from human response-time metrics.

Archived Issues in Helpshift

Helpshift automatically archives issues in Resolved or Rejected state for more than 12 months. Archived issues cannot be accessed through Helpshift's standard API — only through Data Portability exports. If you are migrating old resolved conversations, run your post-migration validation immediately after loading. Do not plan a validation pass 13 months after the fact expecting to access those records via the API.

Timestamp Alignment

Front uses Unix time format with millisecond precision for timestamps. Helpshift also uses Unix timestamps in milliseconds. This is one of the few areas where the platforms align naturally — but verify consistently throughout your pipeline, especially in message ordering logic where off-by-one second errors can reorder messages incorrectly.

Compliance and Data Residency

Before starting:

• GDPR / CCPA: Both platforms process PII. Verify Helpshift's data processing agreements and storage regions against your Front configuration before moving EU or California resident data.
• Data retention: Helpshift archives resolved/rejected issues after 12 months, and archived issues leave the standard API. If your retention policy requires longer-term access, plan for Data Portability exports or CRM archival alongside the migration.
• Audit trail: Store the Front-to-Helpshift ID mapping table permanently. You will need it for GDPR subject access requests, legal discovery, and any future platform migration.
• Attachment content: Verify Helpshift's attachment encryption at rest and access controls meet your requirements if Front conversations contain sensitive files (medical records, financial documents, legal correspondence).

What This Migration Cannot Preserve

Be direct with stakeholders about what will be lost:

• Front Rules and Automations — Must be rebuilt from scratch as Helpshift Automations and Smart Views; there is no import mechanism
• Analytics history — Front's SLA metrics, first response times, resolution times, and CSAT scores do not transfer; Helpshift's analytics clock starts at go-live
• Conversation segments — Front's segment concept has no Helpshift equivalent
• Draft messages — Unsent drafts are not accessible via API and are not migrated
• Internal comment threading — Comment context is flattened depending on approach chosen
• Channel-specific metadata — Email headers (CC, BCC, Reply-To, Message-ID), social media post IDs, and SMS metadata may not map cleanly to Helpshift fields
• Front Account associations — No first-class equivalent; flattened to CIFs or CRM-mastered
• Snooze expiry times — Snoozed conversations map to "Waiting for Agent" status; the original snooze schedule is lost
• Knowledge base content — Front KB and Helpshift FAQs are separate workstreams; Helpshift supports FAQ/section APIs plus FAQ CSV import/export, but content must be reviewed and reformatted for the different rendering environment

When Not to Migrate Everything

Not every Front conversation needs to land in Helpshift. Consider migrating only:

• Open/active conversations — These need immediate agent action and must be migrated
• Last 6–12 months of resolved conversations — Provides agent context for recurring customers
• Conversations with compliance holds — Legal or regulatory requirements override the time filter

Older resolved conversations with no compliance requirement can be archived to cold storage (S3, BigQuery, or your data warehouse) rather than loaded into Helpshift. This reduces migration time significantly, avoids cluttering Helpshift's dashboard, and keeps you below Helpshift's pagination ceiling for manageable data sets. Export these to Parquet or JSON lines format for queryability.

Putting It All Together

A Front-to-Helpshift migration is a genuine platform shift. You are moving from an email-centric shared inbox to a mobile-first, SDK-driven support platform with a fundamentally different data model, status lifecycle, issue type architecture, and routing system.

The technical path is clear: extract via Front's Core API with exponential backoff on rate limits, transform the schema with explicit decisions on timestamps, agents, HTML conversion, and CIF mapping, then load via Helpshift's REST API with idempotent tracking and a two-phase delta sync.

The hard parts live in the details: Front's 50 req/min base limit (budgeting 40+ hours of extraction per 10K conversations), HTML-to-plain-text conversion including inline images, CIF pre-creation with system-generated keys, attachment re-hosting, the Helpshift 50K pagination ceiling for validation, the historical timestamp fidelity gap on standard plans, and building a migration ledger that enables safe retry and rollback.

Teams get into trouble when they treat history migration, live channel cutover, and workflow recreation as one job. Keep them separate. Validate at each stage. Test with a representative 100–200 conversation sample before committing to the full run.

For more on Front's export side, see our Front data export guide. For Helpshift-specific export mechanics, see How to Export Data from Helpshift. And if you're still scoping the move, our Front migration checklist covers the planning process end-to-end.