Intercom to Front Migration: The Complete Technical Guide

Why Teams Move from Intercom to Front

An Intercom to Front migration moves your support operations from a messenger-first, automation-heavy platform to a collaborative, multi-channel shared inbox built around email workflows. Teams make this switch for specific, platform-driven reasons:

• Collaborative email workflows. Front's shared inboxes, internal comments on threads, and @-mention-based collaboration are purpose-built for teams that handle complex, multi-touch customer conversations across email, SMS, and voice — not just chat.
• Multi-channel ownership model. Front routes email, SMS, social, and chat into the same shared inbox with clear assignment rules. Intercom's strength is its Messenger widget and in-app chat; teams that primarily communicate over email often find Intercom's inbox model limiting.
• Transparent customer context. Front's Accounts model ties contacts, conversation history, and custom fields into a single view the whole team can see and edit — without requiring a separate CDP layer.
• Pricing predictability. Teams with high agent counts and moderate automation needs often find Front's per-seat pricing more predictable than Intercom's conversation-volume-based pricing, which can spike with seasonal traffic.

Do not make this switch if Fin AI automated resolution, proactive in-app messaging, or product tours are central to your support strategy. Those capabilities have no equivalent in Front and represent permanent capability loss.

Core Architectural Differences Between Intercom and Front

The data model gap between Intercom and Front is what makes this migration non-trivial. Four architectural differences drive most of the complexity:

1. Continuous chat vs. discrete threads. Intercom treats each customer interaction as a single continuous conversation that can span months, with all messages (called conversation_parts) stored under one conversation ID. Front models conversations as discrete threads — closer to email threads — where each thread has a clear beginning and end. When migrating, you must decide how to segment long-running Intercom conversations into Front threads. A common approach: if an Intercom conversation has gaps of 30+ days between parts, split it into separate Front threads.

2. Automation philosophy. Intercom routes conversations using Workflows, Fin AI bots, and custom bot flows that rely on its built-in CDP and event tracking. Front uses Rules — condition-action pairs configured in the UI — plus shared inbox assignment logic. These paradigms are incompatible. Every Intercom Workflow must be manually rebuilt as a Front Rule. There is no export format for Intercom Workflows, so document their logic manually before decommissioning.

3. Ticket model. Intercom has distinct ticket types: customer tickets, back-office tickets, and tracker tickets. Front handles ticketing as a status layer on conversations (Open, Waiting, Resolved, plus custom statuses). Customer tickets can usually be mapped to Front conversations with ticket statuses, but back-office and tracker tickets have no clean 1:1 equivalent. (intercom.com)

4. Contact identity model. Intercom merges Users (logged-in contacts) and Leads (anonymous visitors) under a unified Contact model, with company association via the Companies object — and a single user can belong to multiple companies. Front uses Contacts (identified by handles — email, phone, Twitter) grouped under Accounts (company-level records), but a Front contact can belong to only one account. Intercom's visitor/lead tracking, events, and multi-company relationships have no home in Front. (help.front.com)

Intercom to Front Data Mapping

Before writing extraction scripts, map Intercom's data model to Front's schema. Do not assume fields map cleanly by name.

Object-Level Mapping

Field-Level Transformations

Key transformations to handle:

Timestamps. Intercom uses Unix epoch seconds. Front's import endpoint accepts created_at as a Unix timestamp — you must specify this field to prevent Front from stamping the import date as the conversation date. If created_at is omitted, all migrated conversations appear as if they arrived on migration day, breaking any date-based reporting or queue ordering.

HTML body. Intercom conversation_part.body may contain HTML. Front's import accepts HTML in the body field for email-type messages. Front lets you specify body_format only for imported messages of type email, not for every imported message type, so Messenger-origin content may need cleanup for readability after import. (dev.frontapp.com)

Attachments. Intercom attachment URLs are temporary signed URLs that expire (typically within hours to days). Download and re-upload to Front using multipart/form-data. Front's import supports up to 25 MB per message. If an Intercom conversation part contains multiple attachments exceeding 25 MB combined, split them across separate import calls or host oversize files externally and link within the message body.

Sender direction. Map Intercom's author.type (admin, user, bot) to Front's metadata.is_inbound boolean. Customer messages are is_inbound: true; agent replies are is_inbound: false. Bot messages should typically be mapped as is_inbound: false (outbound). You can also set metadata.is_archived on imported messages to preserve archived status without burning extra PATCH calls. (dev.frontapp.com)

Custom attribute types. Intercom supports string, integer, float, boolean, datetime, date, and list (enum) types. Front custom fields support string, number, boolean, datetime, enum, teammate, and list. Most map directly; Intercom float → Front number. If a custom field is an enum (picklist) in Front, the incoming Intercom string must match the Front picklist value exactly (case-sensitive), or the API will reject the payload with a 400 Bad Request error.

What Has No Clean Equivalent in Front

Be explicit with stakeholders about what gets lost:

• Intercom Events (user activity tracking) — archive to a data warehouse. No Front equivalent.
• Segments — recreate as Front tags or filtered inbox views.
• Fin AI bot conversations — the bot's auto-resolution data and logic are lost; only the conversation transcript survives if extracted via API.
• Outbound Messages (proactive campaigns) — archive or migrate to your email marketing platform.
• Visitors (anonymous, pre-lead contacts) — cannot be mapped; they have no email handle for Front.
• Conversation ratings — can be stored as a conversation custom field (text) but lose their native reporting context (CSAT aggregate dashboards, trend analysis).
• Multi-company contact relationships — pick a primary Front account and preserve secondary company data in a custom field, note, or external archive.
• Conversations with 500+ parts — Intercom's REST API truncates at 500 conversation parts with no pagination within a single conversation. The tail end of very long conversations may be lost unless you use Intercom's cloud-storage export or GDPR export.
• Historical SLA compliance data — SLA timer states and compliance history do not transfer. Front SLA reporting starts fresh from go-live.
• Response time and resolution time metrics — migrated conversations do not populate Front's native analytics. Your reporting baseline resets on migration day.

The API Bottleneck: Rate Limits and Throughput Math

The rate limit math determines your migration timeline more than any other factor.

Intercom Extraction Limits

Intercom's REST API has a default rate limit of 10,000 API calls per minute per app and 25,000 API calls per minute per workspace. This limit is distributed into 10-second windows — so the effective burst cap is approximately 1,666 operations per 10 seconds. Exceeding this returns a 429 Too Many Requests response with a Retry-After header. (developers.intercom.com)

Extracting conversations requires two calls per conversation: one to GET /conversations (list, paginated at up to 150 per page) and one to GET /conversations/:id (to retrieve the full conversation_parts). For 100K conversations, that's approximately 200K+ API calls for extraction alone — roughly 20 minutes of sustained API throughput at the default limit. In practice, add 30–50% overhead for pagination, retries, and contact/company lookups.

One more Intercom extraction gotcha: the list companies endpoint omits companies with no associated users, and standard company pagination only supports up to 10,000 records before you must switch to the Scroll API. If orphan companies matter for your migration, discover that limitation early. (developers.intercom.com)

Front Import Limits

Front's API rate limits are tiered by plan and enforced per-company (not per-token):

The import endpoint is POST /inboxes/:inbox_id/imported_messages. There is no bulk import endpoint — each message requires a separate API call. Every Intercom conversation part becomes one API call to Front. Front supports email, sms, intercom, and custom message types for imported messages. (dev.frontapp.com)

Internal notes should be recreated separately through POST /conversations/:conversation_id/comments.

Key Front error codes beyond 429:

Throughput Math

On a Growth plan (100 RPM), importing a conversation with 8 messages takes 8 API calls minimum (plus calls for tags, custom fields, and contact linking). That yields roughly 10–12 complete conversations per minute. For 50K conversations, expect 60–80 hours of continuous import time. For 200K conversations, you're looking at 250–300+ hours without a rate limit increase.

At 200 RPM (Scale plan), the absolute ceiling is 12,000 message imports per hour. A 150,000-message migration needs about 12.5 hours at this rate before you add contacts, accounts, comments, retries, or status patches.

Front offers an API rate limit add-on on Scale plans. If you are migrating more than 20K conversations, negotiate a temporary rate limit increase before starting.

Estimates assume 8 messages per conversation average and exclude contact/account creation, tag application, and comment posting.

Plan your cutover weekend accordingly. For guidance on handling failed imports, see our rescue guide.

Migration Methods: Which Approach Fits Your Situation

Front's Native Intercom Channel

How it works: Front connects directly to Intercom to sync new conversations, replies, assignees, and open/close changes.

What it covers: Live, ongoing conversations only. New Intercom messages appear in Front as they arrive.

What it drops: No historical import, no bot messages, no Intercom Tickets. Identity mapping depends on matching Front and Intercom teammate emails. (help.front.com)

Best for: Fast agent cutover while Intercom stays live as a bridge during transition — not as a migration path for historical data.

Native CSV / S3 Export + Front CSV Import

How it works: Export contacts and companies from Intercom's UI (Reports → Dataset Export) and upload them to Front using the Contact Manager CSV upload (up to 3,000 accounts at a time) or contact import.

What it covers: Contact metadata (name, email, phone, company), company data, tags.

What it drops: Full conversation transcripts, attachments, conversation parts, internal notes, events, threading history. Intercom's native CSV and S3 exports do not include conversation message content. (intercom.com)

Best for: Contact-only migration where conversation history is not needed, or as a supplement to API-based conversation migration.

Custom API Scripts (DIY)

How it works: Your engineering team writes extraction scripts against Intercom's Conversations API (GET /conversations, GET /conversations/:id), transforms the data, and loads into Front via POST /inboxes/:inbox_id/imported_messages.

When to use: Dedicated engineering team, strong familiarity with both APIs, fewer than 50K conversations, or need a repeatable pipeline for phased rollout.

Key risks: You must build retry logic with exponential backoff for 429 errors on both sides, handle Intercom's 500-part conversation cap, manage attachment re-upload (Intercom's signed URLs expire), and correctly map the is_inbound flag. If threading breaks, you get fragmented conversations that are impossible to read.

Estimated effort: 80–200+ engineering hours depending on schema complexity. At a blended engineering rate of $150–200/hr, this translates to $12K–$40K+ in engineering cost, excluding opportunity cost.

For a deep dive on Intercom's export constraints, see our guide on how to export data from Intercom.

Managed Migration Service

How it works: A migration partner handles extraction, transformation, loading, validation, and cutover coordination.

Best for: 20K+ conversations, complex custom fields, compliance requirements (GDPR, HIPAA, SOC 2), or zero-downtime needs.

Typical cost range: $5K–$30K+ depending on volume, complexity, and compliance requirements. Generally more cost-effective than DIY above 50K conversations when factoring in engineering opportunity cost and re-migration risk.

Decision Matrix

Step-by-Step Migration Process

The order of operations matters. Loading data in the wrong sequence produces orphaned conversations and broken contact links.

Step 1: Prepare the Front Environment

Before importing anything, configure Front so that imported records have valid targets:

1. Create all inboxes that will receive migrated conversations. Note: there is no documented hard limit on conversations per inbox, but inboxes with 500K+ imported conversations may show slower search and load times. Consider splitting by date range or team.
2. Create all teammates — including deactivated agents from Intercom — so conversation assignment maps correctly.
3. Create all tags that exist in Intercom.
4. Create all custom fields on Contacts, Accounts, and Conversations to match Intercom's CDA schema.
5. Create accounts before contacts — Front can auto-associate contacts to accounts by domain, and account-based analytics are not retroactive. (help.front.com)
6. Set up a dedicated API token with conversations:write, contacts:write, tags:write, and custom_fields:write scopes.
7. Configure SLA policies in Front before go-live so they apply to new conversations from day one.

Step 2: Extract Data from Intercom

Use the REST API for standard extraction. For conversations exceeding 500 parts or for bulk historical export, use Intercom's cloud-storage export (JSON/JSONL format). For phased migrations requiring incremental extraction, consider Intercom webhooks (conversation.admin.replied, conversation.user.created, etc.) to capture new conversations that arrive during the migration window.

import requests
import time
 
BASE_URL = "https://api.intercom.io"
HEADERS = {
    "Authorization": "Bearer YOUR_INTERCOM_TOKEN",
    "Accept": "application/json",
    "Intercom-Version": "2.11"  # Pin to 2.11; v2.12+ may change pagination behavior
}
 
def extract_conversations(per_page=150):
    url = f"{BASE_URL}/conversations?per_page={per_page}"
    all_conversations = []
    while url:
        resp = requests.get(url, headers=HEADERS)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 10))
            time.sleep(retry_after)
            continue
        data = resp.json()
        for convo in data.get("conversations", []):
            detail = requests.get(
                f"{BASE_URL}/conversations/{convo['id']}",
                headers=HEADERS
            )
            if detail.status_code == 200:
                full_convo = detail.json()
                parts_count = len(
                    full_convo.get("conversation_parts", {})
                    .get("conversation_parts", [])
                )
                if parts_count >= 500:
                    # Flag for cloud-storage export fallback
                    full_convo["_truncation_warning"] = True
                all_conversations.append(full_convo)
            elif detail.status_code == 429:
                retry_after = int(detail.headers.get("Retry-After", 10))
                time.sleep(retry_after)
            time.sleep(0.1)  # Stay within 10-second burst window
        url = data.get("pages", {}).get("next", {}).get("url")
    return all_conversations

Step 3: Extract Contacts and Companies

Use GET /contacts (with scroll or cursor-based pagination) and GET /companies (with scroll pagination). Store the Intercom id as a lookup key for linking conversations to contacts during the load phase.

Remember: Intercom's list companies endpoint omits companies with no associated users, and standard pagination caps at 10,000 records before requiring the Scroll API.

Step 4: Transform Data

For each Intercom conversation:

1. Map the contact's email to a Front contact handle.
2. Flatten the opening source message plus every conversation_part into a strict time-ordered event list.
3. Set metadata.is_inbound based on author.type (user = true, admin = false, bot = false).
4. Set created_at to the part's Unix timestamp.
5. Download attachments from Intercom's expiring signed URLs and prepare for multipart/form-data upload. Do this in bulk before starting the load phase — do not download on-the-fly during import.
6. Set metadata.thread_ref to the Intercom conversation_id so all parts thread into one Front conversation.
7. Map internal notes to Front comments (separate API endpoint).
8. For multi-company contacts, pick a primary account and store secondary company data in a custom field.

Step 5: Load Contacts and Accounts into Front

Create accounts via POST /accounts, then contacts via POST /contacts. Link contacts to accounts. Apply tags and custom field values. This must happen before conversation import so that imported messages link to existing contact records.

Step 6: Import Conversations into Front

Use POST /inboxes/:inbox_id/imported_messages to import each message. The first message creates the conversation; subsequent messages thread onto it via thread_ref. Use deterministic external_id values (e.g., intercom:conversation_id:part_id) for idempotency so retries do not create duplicates.

import time
import requests
 
FRONT_BASE = "https://api2.frontapp.com"
FRONT_HEADERS = {
    "Authorization": "Bearer YOUR_FRONT_TOKEN",
    "Content-Type": "application/json"
}
 
def import_message(inbox_id, message_payload):
    url = f"{FRONT_BASE}/inboxes/{inbox_id}/imported_messages"
    max_retries = 5
    backoff = 1
    for attempt in range(max_retries):
        resp = requests.post(url, headers=FRONT_HEADERS, json=message_payload)
        if resp.status_code == 429:
            retry_after = int(resp.headers.get("Retry-After", 60))
            time.sleep(retry_after)
            continue
        if resp.status_code == 202:
            return resp.json()  # Contains message_uid
        if resp.status_code in (502, 503):
            time.sleep(backoff)
            backoff *= 2
            continue
        if resp.status_code == 400:
            # Log the full error for debugging — usually a field mismatch
            error_detail = resp.json()
            raise ValueError(f"Bad request: {error_detail}")
        resp.raise_for_status()
    raise Exception("Max retries exceeded for Front API")

After all messages are loaded, apply tags, assignee, and final conversation status. Internal notes should be recreated via POST /conversations/:conversation_id/comments.

Step 7: Validate and Reconcile

Run record-count reconciliation and field-level checks (detailed in the Validation section below).

Persist your own mapping table between Intercom IDs and Front IDs throughout the process. If you rely on Front search to rediscover imported records mid-run, you will burn rate limit and make rollback harder.

How Long Does an Intercom to Front Migration Take?

Plan for 2–6 weeks, not a blind weekend. The short end fits conversation-only moves with modest history and simple schemas. The long end appears when you must flatten Intercom Tickets, rebuild Workflow logic, handle long conversations, or run multiple test cycles before cutover.

Phased vs. Big-Bang

• Big-bang: Migrate everything over a weekend. Best for teams under 50K conversations with a simple schema. Risk: if something fails, you need a rollback plan.
• Phased: Migrate by date range (e.g., last 6 months first, then historical). Reduces risk but requires running both platforms in parallel and syncing new conversations. Use Intercom webhooks to capture conversations created during the migration window.
• Incremental: Continuous sync during transition. Only viable with a managed service or a well-built pipeline with webhook-driven extraction.

Risk Register

What Customers and Agents Notice During Migration

A well-executed migration is invisible to your customers. Here's what matters:

Conversation history. Customers expect agents to see their full history. If you migrate transcripts correctly, agents in Front can view every past message in context — threaded under the customer's contact record. If you skip transcript migration (CSV-only approach), agents lose all context and customers have to repeat themselves.

Response continuity. During cutover, ensure that any in-flight conversations in Intercom are either resolved before go-live or manually transferred. Front does not have a bidirectional sync with Intercom — Front's Intercom channel handles new messages but does not backfill history. Active Intercom chats mid-resolution during cutover should be closed out in Intercom or manually recreated as outbound messages in Front to continue the thread.

SLAs. Intercom SLA timers do not carry over. Reconfigure SLA policies in Front before go-live to avoid silent SLA breaches on day one. Historical SLA compliance data is lost — export SLA reports from Intercom before decommissioning.

Reporting baseline reset. Migrated conversations do not populate Front's native analytics for response time, handle time, or resolution time. Front's reporting starts from the moment conversations are created or updated in Front's system. Plan for a 30-day baseline-building period where historical comparison is unavailable. Export all critical Intercom reports (team performance, CSAT trends, resolution times) before migration.

Status continuity. If Front ticket statuses are enabled, train agents on Open, Waiting, and Resolved before go-live so migrated history makes sense in queue views and reports.

Change management. Front's UI is fundamentally different from Intercom's. Plan 2–3 days of hands-on training for agents. The assignment model (shared inbox vs. Intercom's round-robin + Workflow routing) requires workflow retraining. Tell the team about known visibility gaps — bot messages, Intercom Tickets, and some side-conversation patterns may be archived or flattened rather than recreated as native Front objects — before cutover, not after.

Because Front connects directly to your email infrastructure, the moment you update your MX records or forwarding rules, new inbound messages will appear in Front. For exact DNS sequencing, see our guide on zero-downtime help desk data migration.

Edge Cases That Break During the Move

Plan for these specific scenarios before they become production issues:

Inline images. Intercom stores inline images as hosted URLs within the HTML body of conversation parts. These URLs may be CDN-hosted and could expire or become inaccessible after account closure. Download and re-host inline images before decommissioning Intercom. Parse the HTML body for <img src="..."> tags and replace URLs with re-hosted equivalents.

Expiring attachment URLs. Intercom hosts attachments on secure AWS S3 URLs that expire. Your script must download the binary file from Intercom and POST it to Front's multipart upload endpoint — you cannot just pass the URL through. Download all attachments in a batch step before starting the Front import.

Duplicate contacts. Intercom sometimes creates multiple contact records for the same person (one as a Lead, one as a User). Deduplicate before loading into Front to avoid multiple contact records for the same email. In Front, an email address or phone number cannot exist on more than one contact — the API will return a 409 Conflict if you attempt it. (dev.frontapp.com)

Multi-company contacts. Intercom allows one user to belong to multiple companies. Front allows one account per contact. Pick a primary account (e.g., highest monthly_spend or most recent activity) and preserve secondary company data in a custom field, note, or external archive. (help.front.com)

Historical teammate mapping. If agents who handled conversations in Intercom are no longer with your company, you still need their accounts created in Front (even as deactivated teammates) to preserve assignment history. Without this, historical conversations lose their assignee and appear unassigned.

Custom field name case sensitivity. Front custom field names are case-sensitive. A field named Revenue is different from revenue. Ensure your transformation script matches the exact case used in Front's configuration. Enum values are also case-sensitive.

Attachment size limits. Front accepts up to 25 MB per message via multipart upload. Intercom conversations with large file attachments may need to be split or the attachments stored externally with a link in the message body.

API concurrency. Front's rate limits are per-company. If you run migration scripts while your team uses Front for live support, both consume the same API quota. This can cause live integrations (CRM sync, Slack notifications) to fail with 429 errors. Monitor your rate limit headers (X-RateLimit-Remaining) during migration.

Company pagination limits. Intercom's list companies endpoint omits companies with no associated users, and standard pagination only supports up to 10,000 records before requiring the Scroll API. Account for this early if orphan companies matter.

Help Center articles. Front has a native knowledge base, but Intercom Articles must be migrated via a separate process. Intercom's GET /articles endpoint returns HTML content, but Front's knowledge base editor uses its own format. Expect manual formatting cleanup for complex articles with embedded videos, callouts, or custom CSS.

Intercom API version differences. The code samples in this guide use Intercom-Version: 2.11. Version 2.12+ introduced changes to contact search pagination. If you use a newer version, verify pagination behavior against Intercom's changelog before running extraction.

Validation and Testing

Do not trust your scripts blindly. Run a structured validation process post-migration.

Pre-Go-Live Checks

1. Record count reconciliation. Compare total contacts, accounts, conversations, and messages between Intercom (source) and Front (target). Tolerance: 0% for contacts and accounts, <0.5% for messages (accounting for the 500-part truncation edge case).
2. Field-level spot checks. Sample 50–100 conversations across different date ranges and conversation lengths. Verify: correct threading, accurate created_at timestamps, attachment accessibility, proper is_inbound direction, assigned agent, and tag/custom field presence.
3. Contact-to-account linking. Verify that migrated contacts are correctly associated with their Front accounts. Spot-check multi-company contacts to confirm primary account assignment.
4. Assignee mapping. Confirm that historical conversations show the correct teammate as assignee, including deactivated agents.
5. Attachment accessibility. Click on 20+ migrated attachments in Front to ensure they resolve to the actual file, not a dead Intercom AWS link.
6. Search functionality. Search for a known customer by email in Front and verify their full conversation history appears.
7. Truncation audit. Query your mapping table for conversations flagged with 500 parts. Verify these were supplemented via cloud-storage export or document the data gap.
8. Custom field rendering. Verify that enum, datetime, and boolean custom fields display correctly in Front's UI — not as raw strings.

UAT Protocol

Have 3–5 agents perform their normal workflow in the migrated Front environment:

• Pull up 10 recent customers and verify conversation history completeness.
• Check that tags and custom fields render correctly in the sidebar.
• Attempt to reply to a migrated conversation (replies should route through Front's channels, not back to Intercom).
• Verify that Rules fire correctly on new incoming messages.
• Confirm SLA timers activate on new conversations.
• Check that Front's analytics dashboard shows new conversations (not migrated ones — confirm this expectation with the team).

Rollback Plan

Keep Intercom active (read-only) for at least 30 days post-migration. If critical data issues are discovered:

1. Routing rollback: Revert MX records or email forwarding rules to point back to Intercom. DNS TTL determines propagation time — if you set TTL to 300 seconds before cutover, rollback takes effect within 5 minutes.
2. Handle in-flight Front conversations: Any conversations that arrived in Front during the failed migration period must be manually forwarded to Intercom or handled as a backlog when Front is re-attempted.
3. Clean up Front: Use your ID mapping table to identify and bulk-delete imported records if needed, or archive the migration inbox.
4. Root cause: Identify whether the failure was data-related (fixable with transformation changes) or systemic (rate limits, API changes) before re-attempting.

Do not cancel your Intercom subscription until validation is complete and your team has confirmed that all critical data is accessible in Front.

For a stricter test matrix, see our post-migration QA checklist.

Build In-House or Use a Managed Service

Build in-house when:

• You have fewer than 10K conversations and a simple schema (few custom fields, no multi-level company hierarchy).
• You have a backend engineer with 2+ weeks of available bandwidth and familiarity with both APIs.
• You're comfortable owning retry logic, rate limit orchestration, threading validation, and attachment re-hosting.

Use a managed service when:

• You have more than 20K conversations.
• You have complex custom data attributes (many teams run 50–100 active custom fields in Intercom).
• You need zero-downtime migration — support continues in Intercom during the data transfer without message loss.
• You have compliance requirements (GDPR, HIPAA, SOC 2) that demand audit trails and data handling guarantees.
• Your engineering team's time is better spent on product work than on a one-time migration script.

The hidden cost of DIY is not the initial build — it's the debugging. Broken threading, orphaned conversations, expired attachment URLs, and silent data truncation at the 500-part limit account for the majority of re-migration requests.