Front to Richpanel Migration: A Technical Guide

Front to Richpanel Migration: A Technical Guide

The Architectural Shift: Shared Inbox to E-commerce Helpdesk

Migrating from Front to Richpanel is not a 1:1 platform swap. You are restructuring how your support data is organized.

Front is a collaborative inbox that unifies email, SMS, chat, and social channels into shared workspaces. Its architecture centers on the Conversation — a threaded exchange enriched with internal comments, shared drafts, tags, and rule-based routing. Front keeps a contact and conversation history for each customer — past threads, notes, and details — so an agent picking up a conversation has context without digging. Statuses, tags, and assignees keep work organized. Internal @-comments let teams discuss a message privately, right inside the thread.

Richpanel is an e-commerce-native platform built around Orders and Customer Profiles. The Richpanel API enables programmatic management of Conversations (support tickets with messages, status, and metadata), Customer Profiles (contact and address information), and order history. Every conversation links to a customer profile and, typically, transaction history synced from Shopify, Magento, or WooCommerce.

There is no native migration path between these platforms. Richpanel's migration wizard supports Zendesk, Gorgias, Help Scout, and Kustomer — Front is not on that list. Every record flows through custom code.

This structural mismatch means your migration script must do more than move data — it must reshape it. Front conversations without a clearly identifiable customer email will orphan in Richpanel unless explicitly mapped to placeholder profiles.

Critical operational risk before you begin: Richpanel may fire customer-facing email notifications when tickets are created via API. If your Richpanel instance has outbound notifications enabled, every historically imported ticket could trigger a customer email about a conversation that is months or years old. Disable all outbound notification triggers in Richpanel before beginning any import, and confirm with Richpanel support whether API-created tickets bypass notification rules or inherit them.

Why Teams Move from Front to Richpanel

Common reasons for this switch:

• E-commerce focus. Front is channel-agnostic and general-purpose. Richpanel surfaces order data, subscription history, and return statuses natively in the agent sidebar. Teams selling physical products want order context without plugins or custom integrations.
• Self-service portal. Richpanel's built-in self-service portal lets customers track orders, initiate returns, and resolve common issues without opening a ticket. Front lacks a native equivalent.
• AI-driven resolution. Richpanel markets autonomous resolution rates for repeat e-commerce queries. Treat vendor claims about specific resolution percentages as sales projections, not guarantees — actual performance depends on query distribution, integration quality, and configuration.
• Pricing model shift. Richpanel pricing starts at $99 per seat plus approximately $0.20 per AI conversation, with a $200 per month minimum (verify current pricing at richpanel.com before budgeting). Front's per-seat pricing on Professional and Enterprise tiers can scale faster for larger teams.

What Transfers — and What Doesn't

Before writing any code, get clear on scope:

Data Model Mapping: Front → Richpanel

The core translation challenge is mapping Front's flexible, multi-inbox conversation model to Richpanel's order-centric structure.

Conversations and Status Translation

Front conversations carry a status field with four base API values: open, archived, snoozed, and trashed. Front's ticketing layer adds custom ticket statuses like Waiting and Resolved on top of these base statuses.

Richpanel's status model is narrower. The API documents OPEN, SNOOZED, and CLOSED as status values. The create conversation endpoint (POST /v1/tickets) accepts a status field. You need to collapse Front's multi-layered statuses:

Contacts → Customers

Front's Contact object includes id, name, description, handles (with source types like email, Twitter, phone), custom_fields, and linked lists.

Richpanel Customer Profiles hold contact information and manage billing/shipping addresses. Key mapping points:

• Front handles [] → Richpanel email: Richpanel expects an email as the primary identifier. Extract the email-type handle from Front. If a contact lacks an email, generate a placeholder (e.g., twitter-handle@social.local) or merge with a known profile.
• Front name → Richpanel firstName / lastName: Split the single name string. Handle edge cases: single names, names with multiple spaces, empty strings.
• Front custom_fields → Richpanel custom properties: Map selectively. Richpanel's customer model is e-commerce-oriented; not all Front custom fields will have a natural home.

Front Accounts are a separate consideration. Front has a first-class Account (company/organization) object that Richpanel's conversation model does not replicate. If your agents rely on Front Accounts for B2B context — account tier, CSM assignment, domain grouping — carry those values across as customer custom fields or tags in Richpanel.

Teammates → Agents

Front Teammates map to Richpanel Agents. Provision all agents in Richpanel before migrating historical data. If a Front teammate has left the company, their historical actions will fail to attribute unless you either:

1. Create inactive placeholder agents in Richpanel.
2. Map their actions to a generic "Legacy Agent" profile.

Build a stable lookup table (Front teammate ID → Richpanel agent ID) before replay starts. Assignment drift will wreck validation if you skip this step.

Tags

Front tags are hierarchical (parent/child) and support private, shared, and company scopes. Richpanel tags categorize and organize conversations for filtering, reporting, and automation — the structure is flat (no hierarchy, no scoping). Richpanel's tag creation normalizes names to hyphen case.

If you use nested tags in Front (e.g., Billing > Refund > Partial), flatten them: billing-refund-partial. Private and nested Front tags may need flattening, renaming, or deliberate exclusion. Color coding will not transfer via API.

Create all tags in Richpanel before starting the conversation import. The create conversation payload accepts a tags array containing tag IDs — you need the Richpanel tag UUIDs in advance.

Comments → Internal Notes

Front supports internal @-comments tied to specific messages within a conversation. In Richpanel, internal notes are appended chronologically to the conversation timeline — the message-level context is lost.

Best practice: prepend the note with context during transformation (e.g., [Note originally on message from 2025-03-15 10:45 AM]).

One nuance to watch: Front comments in shared inboxes are visible to everyone with inbox access, while individual-inbox comment visibility is more granular. Richpanel's internal notes use a simpler agent-only flag. Some audience nuance may be lost in translation.

Inboxes → Teams

Front's Inboxes do not have a direct equivalent in Richpanel. If you use Front inboxes to separate departments (e.g., "Support", "Returns", "Wholesale"), map these to Richpanel Teams or apply Tags to migrated conversations so Richpanel's routing rules can handle them post-migration.

Extraction: Getting Data Out of Front

You have three extraction paths. Only one gives you complete data.

Option 1: Front Core API (Recommended)

Front's Core API allows you to read, create, update, and delete data across Front's entities, from Contacts to Comments to Tags.

The extraction sequence:

1. List all inboxes → GET /inboxes
2. List conversations per inbox → GET /conversations with pagination (up to 100 items per page)
3. For each conversation, fetch messages → GET /conversations/{id}/messages
4. For each conversation, fetch comments → GET /conversations/{id}/comments
5. For each message with attachments, download files → attachment URLs from message objects
6. List all contacts → GET /contacts with pagination
7. List all tags → GET /tags

Front provides a sample export application demonstrating how to export conversations with all messages, comments, and attachments included. This Node.js/TypeScript application on GitHub is a solid starting point for the extraction layer.

Do not use Front's search endpoint as your primary bulk extractor. Its rate limit is proportional — 40% of your company rate — making it better suited for audits and delta backfills than full-history pulls.

Front Events API vs. polling: Front also exposes an Events API for real-time sync, filterable by time window and event type (15 items per page). For historical extraction, the Core API pagination approach above is more reliable. The Events API is useful for delta syncs during cutover — covered in Step 8 below.

Option 2: Account Data Export (via Front Support)

You need to contact Front's Support team to export account data — you cannot do this on your own in the app. The export provides conversations, messages, and discussions from shared inboxes, but will not include attachments, comments, conversations from individual inboxes, or contact data. Message templates and tags are also excluded.

Front acknowledges export requests within 72 hours and delivers files as CSV sets organized by inbox. If email fidelity matters, ask Front for EML files in the support export — keeping message/rfc822 in reserve is worthwhile for rendering provenance and header fidelity.

This export is useful as a supplementary backup, but not sufficient for a full migration.

Option 3: Analytics CSV Export

The Messages export from Front Analytics contains one line per message received. The message body is limited to a 200-character extract. This is an analytics tool, not a migration tool.

Verdict: Use the Core API. It is the only path that gives you complete conversations, full message bodies, comments, attachments, and contact data.

Third-Party Migration Tools

No dedicated third-party migration tool (such as Help Migrate or Import2) advertises a supported Front → Richpanel migration path as of mid-2025. Tools like these typically support Zendesk, Freshdesk, and Intercom combinations — the same set Richpanel's native wizard covers. If you need a no-code option, contact Richpanel's onboarding team directly; they occasionally run assisted migrations for enterprise accounts. Otherwise, custom code via the Core API is the practical path.

API Rate Limits: The Migration Bottleneck

Both platforms impose rate limits that directly control your migration speed.

Front API Limits

Front's API rate limit starts at 50 requests per minute and varies depending on your plan. Rate limits are enforced on a per-company basis rather than a per-token basis.

API rate limit add-ons can be purchased to increase limits — 300 additional calls per minute per add-on. This allows an Enterprise plan to reach up to 2,000 RPM with the maximum number of add-ons, at additional cost per add-on per month.

When you exceed the rate limit, Front returns a 429 status with a JSON error body containing a retry_after field in milliseconds. Build exponential backoff with a maximum retry ceiling into your extraction script — not a bare time.sleep() call.

Front also enforces burst rate limits on resource-intensive endpoints — generally 5 requests per second per resource type. Your script must respect both the global RPM limit and the per-second burst limit.

Richpanel API Limits

Richpanel's API has a rate limit of 100 calls per minute. After crossing the usage threshold within a minute, the API responds with a 492 status code — not a standard HTTP status. The response includes X-RateLimit-Limit and X-RateLimit-Remaining headers on all API responses. Once exceeded, a Retry-After header indicates wait time before the next call.

Richpanel error response taxonomy (document these in your error handler):

• 400 — Malformed request payload (missing required fields, invalid types)
• 401 — Invalid or missing API key
• 404 — Resource not found (e.g., customer profile doesn't exist before ticket creation)
• 422 — Unprocessable entity (valid JSON, but business logic rejection — e.g., invalid tag UUID)
• 492 — Rate limit exceeded (Richpanel-specific, non-standard)

Each conversation creation is one API call. Each message addition (via conversation update) is another. For a conversation with 5 messages, you need at minimum 6 API calls (1 create + 5 updates). Richpanel does not offer a bulk import endpoint for historical conversations.

Throughput Math

Realistic throughput estimate for a 30K-conversation dataset with an average of 3 messages per conversation:

This is elapsed API time only — does not include attachment downloads/uploads, error handling, or retries. Plan for a 1.5–2x multiplier on these estimates based on realistic error and retry rates. The multiplier accounts for: 429/492 backoff delays, attachment transfer overhead, malformed payload retries, and network interruptions during long-running jobs.

Step-by-Step Migration Approach

Step 1: Audit Your Front Instance

Before writing migration code, review your Front migration checklist and:

• Count total conversations, messages, and contacts
• Identify which inboxes are in scope (shared vs. individual)
• Document all tags, especially hierarchical ones
• List active automation rules, SLAs, and message templates (these need manual recreation)
• Check attachment volume — large files significantly impact migration time
• Note any custom ticket statuses in use
• Identify stale inboxes, spam conversations, and unused tags — archive or delete before extraction
• Confirm whether Richpanel has a sandbox or staging environment available for test migrations before loading production data

Step 2: Pre-Create Richpanel Reference Data

Many Richpanel endpoints require an appClientId parameter — a unique identifier representing a specific store or brand. Find your app client IDs in Richpanel Settings → Connected Apps.

• Create all tags in Richpanel and map Front tag IDs → Richpanel tag UUIDs
• Set up teams and agent accounts, mapping Front teammates → Richpanel agents
• Connect your e-commerce platform if applicable — Richpanel natively integrates with Shopify, Magento, and WooCommerce
• Sync order data before ticket replay. If imported tickets land before customer and order context exist, agents will open historically complete conversations with none of the business context they need. Richpanel recommends sending historical order events in batches of 25.
• Build lookup tables: Front teammate ID → Richpanel agent ID, Front tag ID → Richpanel tag UUID, Front inbox → Richpanel team
• Disable outbound notifications. Before any import run, verify that API-created tickets will not trigger customer-facing email notifications. This is the highest-impact operational risk in a historical migration.

If you run multiple brands in Richpanel, each conversation must be routed to the correct appClientId. This requires a brand-mapping layer in your transformation logic.

Step 3: Extract from Front

Use the Core API to extract all data in this order:

1. Tags — GET /tags (full list)
2. Contacts — GET /contacts (paginate through all)
3. Conversations — GET /conversations per inbox with pagination
4. Messages per conversation — GET /conversations/{id}/messages
5. Comments per conversation — GET /conversations/{id}/comments
6. Attachments — Download from URLs in message objects

Store everything locally (JSON files per conversation or a local database) before beginning the import. Never extract and import in the same pass — if the import fails mid-way, you do not want to re-extract.

import requests
import time
 
FRONT_API_TOKEN = "your_front_api_token"
BASE_URL = "https://api2.frontapp.com"
HEADERS = {"Authorization": f"Bearer {FRONT_API_TOKEN}"}
RATE_LIMIT_RPM = 100  # Adjust per your plan
MAX_RETRIES = 5
 
def rate_limited_get(url, params=None):
    """GET with rate limiting, exponential backoff, and max retry ceiling."""
    retries = 0
    while retries < MAX_RETRIES:
        resp = requests.get(url, headers=HEADERS, params=params)
        if resp.status_code == 429:
            error_body = resp.json().get("_error", {})
            retry_after = error_body.get("retry_after", 60000) / 1000  # ms to seconds
            wait = min(retry_after * (2 ** retries), 300)  # cap at 5 minutes
            time.sleep(wait)
            retries += 1
            continue
        resp.raise_for_status()
        return resp.json()
    raise Exception(f"Max retries exceeded for URL: {url}")
 
def extract_conversations(inbox_id):
    """Extract all conversations from a Front inbox with pagination."""
    url = f"{BASE_URL}/inboxes/{inbox_id}/conversations"
    conversations = []
    while url:
        data = rate_limited_get(url)
        conversations.extend(data.get("_results", []))
        url = data.get("_pagination", {}).get("next")
        time.sleep(60 / RATE_LIMIT_RPM)
    return conversations

Step 4: Build an Idempotent Pipeline

An idempotent pipeline is one you can run multiple times without duplicating data — if it fails halfway through and you restart it, already-loaded records are skipped rather than duplicated. This property is non-negotiable for migrations: network connections drop, API tokens expire, malformed payloads cause rejections.

Use a local database (PostgreSQL or SQLite) to track state. Create a migration_state table:

• front_conversation_id (Primary Key)
• richpanel_conversation_id
• status (pending, extracted, transformed, loaded, failed)
• error_log
• retry_count

When your script runs, it checks this table. If a conversation is marked loaded, skip it. If marked failed, retry it up to a configurable limit. Store the original Front conversation ID as a Richpanel custom field for audit, de-duplication, and reconciliation.

Never rely on scripts that push data directly from one API to another in memory without tracking state.

Step 5: Transform Data

The transformation layer is where most migration bugs live. Key transformations:

• Split contact names: "Jane Doe" → {"firstName": "Jane", "lastName": "Doe"}. Handle edge cases: single names, names with multiple spaces, empty strings, all-caps names.
• Flatten tags: Parent > Child → parent-child
• Map statuses: Front archived → Richpanel CLOSED
• Resolve assignees: Front teammate ID → Richpanel agent ID via your lookup table
• Handle HTML bodies: Front messages may contain HTML. Richpanel accepts HTML in comment.body.
• Order messages chronologically: Messages must be added in timestamp order to preserve thread coherence.
• Prepend context to internal notes: Since Richpanel loses message-level comment context, add identifiers like [Note originally on message from 2025-03-15 10:45 AM].
• Handle merged conversations: Front supports conversation merging, which can produce non-linear timelines. Sort by message timestamp, not by conversation structure, and flag merged threads for manual review.

Step 6: Handle Attachments and Inline Images

Attachments are the most complex component of any helpdesk migration. Front stores attachments as authenticated URLs within the message payload. These URLs require authorization headers to access, expire, and count against API rate limits.

Your pipeline must:

1. Parse the Front message payload for attachment URLs.
2. Download the file to a local staging area or an S3 bucket using authenticated requests.
3. Upload the file to Richpanel using their attachment endpoints, or append the public S3 URL to the Richpanel message body.

Inline images (images pasted into the email body) are often formatted as CID (Content-ID) references in Front. Parse the HTML body, locate cid: references, download the corresponding inline attachment, and rewrite the HTML <img> tags to point to the newly hosted image URL. Failure to do this results in broken image icons across all historical tickets.

Attachment size limits: Large attachments (>25MB) may fail on Richpanel's upload endpoint. Pre-scan your Front attachment inventory by querying message objects and logging attachment sizes before the migration run. For oversized files, link to external storage (S3, GCS) and append the URL in a note rather than attempting a direct upload.

Step 7: Load into Richpanel

The import sequence:

1. Create customers — POST customer profiles with email, name, and address data
2. Create conversations — Use POST https://api.richpanel.com/v1/tickets with the first message, tags, customer profile, priority, subject, and channel information
3. Add subsequent messages — Use PUT https://api.richpanel.com/v1/tickets/{id} — add each remaining message as a comment with the correct sender_type (customer or operator), oldest to newest
4. Add internal notes — Same update endpoint, with internal note flag
5. Set final status — Close conversations that were archived/resolved in Front only after the full timeline is replayed, so closedAt logic stays consistent

import requests
import time
 
RICHPANEL_API_KEY = "your_richpanel_api_key"
RP_BASE = "https://api.richpanel.com/v1"
RP_HEADERS = {
    "Content-Type": "application/json",
    "x-richpanel-key": RICHPANEL_API_KEY
}
MAX_RETRIES = 5
 
def create_richpanel_conversation(conversation_data, retry_count=0):
    """Create a conversation in Richpanel with the first message."""
    if retry_count >= MAX_RETRIES:
        raise Exception(f"Max retries exceeded for conversation: {conversation_data.get('front_id')}")
 
    payload = {
        "ticket": {
            "status": conversation_data["status"],
            "comment": {
                "sender_type": conversation_data["first_message"]["sender_type"],
                "body": conversation_data["first_message"]["body"]
            },
            "tags": conversation_data["tag_ids"],
            "customer_profile": {
                "firstName": conversation_data["customer"]["firstName"],
                "lastName": conversation_data["customer"]["lastName"]
            },
            "subject": conversation_data["subject"],
            "via": {
                "channel": "email",
                "source": {
                    "from": {"address": conversation_data["customer"]["email"]},
                    "to": {"address": conversation_data["inbox_email"]}
                }
            }
        }
    }
 
    resp = requests.post(f"{RP_BASE}/tickets", json=payload, headers=RP_HEADERS)
 
    if resp.status_code == 492:
        # Rate limited — use Retry-After header if present, otherwise back off
        retry_after = int(resp.headers.get("Retry-After", 60))
        wait = min(retry_after * (2 ** retry_count), 300)
        time.sleep(wait)
        return create_richpanel_conversation(conversation_data, retry_count + 1)
 
    if resp.status_code == 422:
        # Unprocessable — log and skip rather than retry
        raise ValueError(f"Richpanel rejected payload (422): {resp.json()}")
 
    resp.raise_for_status()
    return resp.json()

Step 8: Delta Sync and Cutover

A historical migration takes days to run. During this time, your team is still working in Front. You need a delta sync to capture the gap.

1. Record the exact timestamp when your historical extraction began.
2. Once the historical load is complete, query Front's API with q=updated_at:>={timestamp}.
3. Extract only conversations modified since the historical run began.
4. Push these updates to Richpanel.

For final delta capture, Front's Events API can filter by time window and event type — this is where it earns its value. Note the 15-items-per-page limit and plan pagination accordingly.

Schedule the DNS cutover (updating your support email forwarding rules to point to Richpanel instead of Front) during a low-traffic window. Run one final delta sync immediately after the cutover to catch any emails that arrived during DNS propagation.

Step 9: Validate

Post-migration validation is non-negotiable. Check:

• Record counts: Total conversations, messages, and contacts match source
• Thread integrity: Spot-check 50+ conversations to verify message ordering and completeness
• Tag accuracy: Verify tags applied correctly across a random sample
• Customer linking: Confirm conversations are attached to the right customer profiles
• Attachment presence: Spot-check conversations with attachments — especially inline images
• Status mapping: Verify archived Front conversations are Closed in Richpanel
• Assignee coverage: Confirm agent assignments transferred correctly
• Notification audit: Confirm no customer-facing emails were triggered during import

Use stable keys for validation, not visual spot-checks. Keep the original Front conversation ID stored as a custom field in Richpanel for traceability. Richpanel's docs note that conversation-number lookup may not work reliably for imported conversations — use Richpanel ticket IDs for API-level validation.

Edge Cases and Failure Modes

Multi-inbox conversations

Front conversations can live in multiple shared inboxes simultaneously. Richpanel conversations belong to a single channel context. Decide a priority rule before extraction: use the primary inbox (first assigned) or the most recent inbox. Document the rule and apply it consistently.

Merged conversations

Front supports conversation merging. A merged conversation contains messages from multiple original threads with a potentially non-linear timeline. Sort all messages by timestamp during transformation. Flag merged threads in your migration state table for post-migration manual review.

Shared drafts

Front's shared draft feature has no equivalent in Richpanel. Exclude unsent drafts from migration. If a draft contains important context, convert it to an internal note on the relevant conversation.

Chat vs. email conversations

Front is omnichannel — a single workspace can pull in email, live chat, SMS, social media, WhatsApp, voice, and Slack. Richpanel also supports multiple channels, but the channel type affects display and routing. Map Front channel types to Richpanel's via.channel field accurately — mismatched channel types cause conversations to land in the wrong queue.

Multi-brand / appClientId routing

Many Richpanel endpoints require an appClientId parameter representing a specific store or brand. If you run multiple brands, each conversation must route to the correct client ID. Build your brand-mapping layer into the transformation step, not as an afterthought.

Thread splitting in Front

Front automatically splits threads at 500 messages for most channel types, 1,000 for custom channels, and 10,000 for SMS and WhatsApp. Long-running customer histories may already be fragmented across multiple conversation IDs inside Front. Account for this during extraction or your conversation-to-customer mapping will be incomplete.

What You Must Rebuild Manually

These Front capabilities have no API migration path — they require manual recreation in Richpanel:

• Automation rules — Front's rule engine doesn't export to a portable format. Document each rule's conditions and actions, then rebuild in Richpanel's automation builder.
• Message templates — Export template text manually; recreate as Richpanel macros.
• Knowledge base — Front will provide separate files on request, but these don't import into Richpanel. Manually migrate articles.
• SLA policies — Richpanel has its own SLA framework. Reconfigure from scratch.
• Custom fields on contacts — Audit which fields Richpanel's customer model supports natively vs. what needs workarounds or custom properties.
• Front Plugins — Any custom sidebar plugins are Front-specific. Evaluate Richpanel's integration ecosystem for functional equivalents.
• CSAT scores — Historical CSAT from Front's native feature cannot be attached to Richpanel's CSAT reporting module. Append scores as internal notes or custom tags on migrated conversations for reference.

Compliance and Data Handling

If your support conversations contain PII, payment data, or health information:

• Transfer encryption: Both Front and Richpanel APIs use HTTPS. Ensure your intermediate storage (local JSON files, migration database) is encrypted at rest.
• Data residency: Verify Richpanel's data hosting region aligns with your compliance requirements (GDPR, CCPA, etc.) before beginning extraction.
• Retention policies: Front and Richpanel may have different retention settings. Audit both before cutover to avoid importing data that exceeds Richpanel's retention tier.
• Right to deletion: If customers have submitted deletion requests under GDPR or CCPA, exclude those records from migration. Do not re-import data that has already been purged from Front.

Realistic Timeline

For large datasets, migrate the most recent 6–12 months first, go live on Richpanel, then backfill historical data in the background. Agents get working context immediately, and the full archive follows without blocking the cutover.

When Not to Migrate

This migration does not make sense for every team:

• Non-e-commerce teams: If you don't sell physical products or need order context, Richpanel's core value proposition doesn't apply.
• Heavy rule automation users: If your Front setup relies on 50+ complex rules with conditional logic, rebuilding in Richpanel is a significant, time-consuming effort that should be scoped separately.
• Teams needing deep CRM integration: Front integrates deeply with Salesforce, HubSpot, and other CRMs. Richpanel's CRM integrations are more limited, which is a common reason teams eventually migrate from Richpanel to HubSpot Service Hub.
• Account-centric B2B workflows: Front's Account model and individual inbox behavior serve B2B teams with account-level context. Richpanel is optimized for DTC e-commerce, not B2B account management. If you need strict SLA management and B2B ticket lifecycle control, a Front to Zendesk migration is often a better fit.
• Multi-channel non-email teams: If your primary volume is Slack, voice, or SMS without e-commerce context, Richpanel may not be the right destination.

Making the Call

A Front to Richpanel migration is technically straightforward but operationally demanding. The absence of a native migration path means every record flows through custom code. Rate limits on both sides make this a throughput-constrained project. The data model gap — Front's flexible, multi-status, multi-inbox architecture vs. Richpanel's order-centric, simpler status model — is where most mapping errors occur.

The highest-risk items in order of impact:

1. Customer notification triggers — Verify API-created tickets don't spam customers before you load a single record.
2. Timestamp write access — Confirm with Richpanel's API team what historical timestamps you can actually write before promising full fidelity.
3. Plan retention limits — Confirm your Richpanel plan tier will display multi-year imported history before loading it.
4. Attachment inline images — CID references in HTML bodies will silently break if not rewritten.
5. Idempotency — Migrations that lack state tracking will duplicate data on every failed restart.

Treat this as a software project: build idempotent pipelines with retry depth limits, decouple extraction and ingestion, handle attachments asynchronously, and run multiple test migrations on a subset of 500–1,000 conversations before committing to production. For teams managing hundreds of thousands of conversations, building this pipeline in-house typically pulls senior engineers away from core product work for several weeks — scope that cost honestly against alternatives.