Front to Intercom Migration: The 2026 Technical Guide

Why Teams Switch from Front to Intercom

A Front to Intercom migration moves your support operations from an email-first shared inbox platform to a messenger-first customer messaging platform with a built-in customer data platform (CDP). Teams make this switch for specific platform-driven reasons: Intercom's native Messenger widget and proactive messaging, the Fin AI agent for automated resolution, product tours and onboarding flows, the visual Workflows automation engine, or the need to consolidate support and marketing messaging into one platform.

Do not make the business case on knowledge base alone. Front has a native knowledge base and help center in 2026. The stronger reason to move is that Intercom ties support, automation, customer data, proactive messaging, and ticketing to the same contact record — and that Fin AI requires Intercom's data model to function.

This migration is non-trivial because of three architectural differences:

1. Shared inbox vs. CDP-powered messaging. Front organizes work around shared email inboxes and rule-driven routing. Intercom organizes work around a customer data platform with Messenger, Inbox, Workflows, and Fin AI. Every workflow assumption changes.
2. Contact model gap. Front contacts are simple records (name, email, phone, custom fields). Intercom contacts sit inside a full CDP with role (user vs. lead), company associations, custom attributes, custom events, browser/device data, and dynamic segments. You are migrating into a richer model.
3. Conversation history import limitations. Intercom does not have a dedicated bulk historical import API equivalent to Zendesk's Ticket Import API. The Conversations API accepts a created_at field described as "only recommended for migrating past conversations from another source into Intercom," but sandbox testing is required to confirm timestamp preservation on your specific plan.

For a deeper look at what makes Intercom compelling as a destination, see our guide on why teams choose Intercom.

Front to Intercom Object and Field Mapping

The correct object-to-object mapping is the foundation of any migration plan. Every item below reflects real API object names.

• Front Conversations → Intercom Conversations and/or Intercom Tickets. This routing decision — which Front conversations become real-time Intercom Conversations vs. tracked async Intercom Tickets — is a key migration design choice. Segment by Front inbox, tag, or conversation metadata during the transform step.
• Front Messages (within conversations) → Intercom Conversation Parts (replies, notes, assignments). Each message becomes a "part" on the conversation.
• Front Conversation Comments (internal notes) → Intercom Conversation Parts with type = "note".
• Front Inboxes (shared inboxes) → Intercom Team Inboxes (configured per workspace, not per email address).
• Front Teammates → Intercom Admins/Teammates.
• Front Teams → Intercom Teams.
• Front Contacts → Intercom Contacts (unified model: role = "user" for known users, role = "lead" for anonymous visitors). Preserve the Front contact ID as Intercom external_id.
• Front Contact Groups (renamed to Contact Lists in the API since September 2025) → Intercom Companies for org-level grouping + Intercom Tags on contacts as a workaround for static group membership. Intercom Segments are dynamic and filter-based — they cannot be statically imported.
• Front Tags (on conversations) → Intercom Tags (on conversations). Front Tags on contacts → Intercom Tags on contacts. Note that Intercom maintains separate namespaces for conversation and contact tags.
• Front Custom Fields (on contacts) → Intercom Custom Attributes (typed: string, integer, boolean, date, list). A Front text field maps to an Intercom string attribute. A Front dropdown maps to an Intercom list attribute — you must enumerate all valid values in Intercom before import via the Data Attributes API.
• Front Contact Notes → Intercom Contact Notes.
• Front Message Templates / Canned Responses → Intercom Saved Replies (partial mapping; Intercom has no folder structure equivalent).
• Front Webhooks → No migration path. Front webhook subscriptions must be decommissioned and rebuilt as Intercom webhook topics or Workflow triggers. Any downstream systems consuming Front webhook payloads need schema updates.

Objects without a clean equivalent in Intercom:

• Front Rules: Must be manually rebuilt as Intercom Workflows. This is often the most time-consuming post-migration task.
• Shared Drafts: No equivalent in Intercom.
• Conversation Links: Front's ability to link distinct conversations together does not exist natively in Intercom.
• Per-Inbox Signatures: Intercom uses workspace-level sender identity and email templates.
• Analytics Dashboards: Must be rebuilt in Intercom's Reports module.
• Inbox-Scoped Channel Routing: Intercom routing uses Workflows, team assignment rules, and Fin AI. Must be redesigned.

Can Front Conversation History Be Imported into Intercom?

Yes, but with significant caveats. Intercom's Create Conversation API endpoint (POST /conversations) includes a created_at field that their documentation describes as "only recommended for migrating past conversations from another source into Intercom." If not provided, the current time is used. This means timestamp preservation is technically supported, but you must test the exact behavior on your plan in a sandbox workspace before committing to a full migration. (developers.intercom.com)

Three additional constraints matter:

• 500-part limit. Intercom caps conversation parts at 500 per conversation. Front conversations with very long threads (500+ messages and internal notes combined) will need to be truncated or split.
• Initial body HTML. The create-conversation endpoint does not support HTML in the initial message body. Rich HTML from Front email threads needs to be handled in reply parts, not the conversation shell. (developers.intercom.com)
• Attachment URL stability. Front attachment URLs served via the API are authenticated and may expire. Before relying on them as source URLs for Intercom attachment imports, test whether they remain accessible for the full duration of your migration window. If URLs expire, you must download attachments locally and re-host them (e.g., on S3 with public-read ACLs or presigned URLs) before passing them to Intercom's API.

For teams migrating into Intercom from other platforms, our Zendesk to Intercom migration guide covers many of the same Intercom-side challenges in depth.

Migration Approaches for Front to Intercom

There is no vendor-documented one-click migration tool between Front and Intercom. The right method depends on whether you need conversation history or just contact data.

CSV Export + Intercom CSV Import — Complexity: Low

Export Front contacts from the Contact Manager as CSV, then use Intercom's People → Import to load contacts. This method only works for contacts. Intercom's CSV import cannot handle conversation history, company data, tags, or internal notes. Files over 20 MB must be split. Use this for contact-only migrations or as the first step in a hybrid approach. Estimated effort: 2–4 hours for a clean contact list.

API-Based Migration — Complexity: High

Extract from Front using GET /conversations, GET /conversations/{id}/messages, GET /contacts, GET /tags, and related endpoints. Load into Intercom using POST /contacts, POST /companies, POST /conversations, POST /conversations/{id}/reply, and POST /tags. This is the only serious option if you want threaded history inside Intercom.

The rate limit math matters. Front's default API rate limit is 50 requests per minute on Starter, scaling to 100 rpm on Professional and 200 rpm on Enterprise. Intercom's default private app rate limit is 1,000 requests per minute, distributed into 10-second windows — meaning a maximum of ~166 operations per 10-second period. Burst past that window and you hit 429 errors immediately. Estimated engineering effort: 80–160 hours depending on conversation volume and edge case density.

Hybrid: Contacts via CSV + History via API — Complexity: Medium

Import contacts via Intercom's CSV import (fast and reliable for people records), then migrate conversation history and company data via the API. This is the pragmatic middle ground for teams with clean contact data but complex conversation history. Estimated engineering effort: 60–120 hours.

Custom ETL Pipeline — Complexity: High

Build extract-transform-load scripts (Python or Node.js) using both APIs. Best when you have a highly customized Front setup, non-standard fields, multi-channel data, or need full control over the Tickets vs. Conversations routing decision. Estimated engineering effort: 100–200 hours, including testing and validation.

Clean-Break Migration — Complexity: Low

Export Front data as an archive, set up Intercom from scratch, skip historical conversation import entirely. Front's full account data export requires contacting Front Support — it is not self-serve — and omits contact data, tags, and individual inbox content. This is an archive strategy, not a full migration strategy. Best when history is low-value or the cost of importing it exceeds the business benefit. Estimated effort: 1–2 weeks for Intercom workspace setup and agent training.

Managed Migration Service — Complexity: Low (for your team)

A provider handles extraction, mapping, transformation, and loading — including the conversation history timestamp challenge. Best for teams with >50K conversations, limited engineering bandwidth, or tight timelines.

Decision matrix:

Migration Architecture: Front Extraction to Intercom Load

Front Extraction

Front's Core API is the primary extraction path. Paginate with limit and page_token (link-based pagination). Respect the Retry-After header on 429 responses. When fetching conversations, you must make secondary calls to fetch nested messages, comments, and attachments per conversation.

For a full account data export, you must contact Front Support — it cannot be done self-serve. That export covers shared inbox conversations and messages but excludes attachments, individual inbox conversations, contact data, message templates, and tags. For a complete extraction, use the API.

Throughput reality check: 150K conversations with one list call per 100 conversations, one messages call per conversation, and one comments call per conversation comes to roughly 301,500 Front API requests. At 50 requests per minute (Starter plan), that is a theoretical floor of 100+ hours of extraction time — before retries, redirects, or attachment handling. At 200 rpm (Enterprise plan), the floor drops to ~25 hours. This is why filtering by date, inbox, or status and running a pilot first is not optional. (dev.frontapp.com)

One edge case: merged Front conversations can return HTTP 301 redirects on messages and comments calls. Your extractor needs redirect handling, or you will undercount history. (dev.frontapp.com)

Transformation Layer

• Status mapping: Front conversation status (assigned / unassigned / archived) → Intercom conversation state (open / closed / snoozed) or Ticket state (submitted / in_progress / resolved / waiting_on_customer).
• Author attribution: Front teammate → Intercom admin ID. Front contact → Intercom contact ID. Each conversation part must carry the correct author type.
• Contact deduplication: Front allows duplicate contacts by email. Intercom contacts are unique by external_id or email — attempting to create a duplicate returns a 409 Conflict error with a response body like {"type":"error.list","errors": [{"code":"conflict","message":"A contact matching those details already exists with id=..."}]}. Run a dedup pass on Front data before import and define a merge strategy (newest wins, most conversations wins, or manual review).
• Custom field type coercion: Front text → Intercom string. Front dropdown → Intercom list (requires pre-registering valid values via the Data Attributes API).
• Routing decision: Decide whether each Front conversation becomes an Intercom Conversation or Ticket based on inbox, tag, or conversation metadata.

Intercom Load

Use the Contacts API with create-or-update semantics via external_id. Use the Companies API (POST /companies) with company_id as the idempotency key — note that company_id cannot be updated after creation. Create conversations via POST /conversations with created_at set to the original Front timestamp. Add reply parts via POST /conversations/{id}/reply in chronological order.

Throughput math (Intercom side): A workspace with 100K conversations averaging 8 messages each requires approximately 900K total API calls on the Intercom side. At a sustained effective throughput of ~800 requests/minute (accounting for overhead and retries), that is roughly 19 hours of continuous load time — before attachments.

These are the endpoints most custom pipelines touch:

# Front extraction
GET /conversations?limit=100&page_token=...
GET /conversations/{id}/messages?limit=100&sort_by=created_at&sort_order=asc
GET /conversations/{id}/comments
GET /contacts
GET /tags
 
# Intercom load
POST /contacts
POST /companies
POST /contacts/{id}/companies
POST /conversations
POST /conversations/{conversation_id}/reply
POST /tags
POST /tickets

DNS and Email Routing Cutover

The data migration is only half the go-live story. Inbound email routing must be switched from Front to Intercom, and this is a critical operational step that affects customers immediately if misconfigured.

Key steps:

1. Verify your support email domain in Intercom. Intercom requires DNS verification (DKIM and SPF records) before it can receive email on your domain. Add the required CNAME/TXT records and allow 24–48 hours for propagation.
2. Set up email forwarding or MX changes. Two approaches:
   • Forwarding rule (lower risk): Configure your email provider (Google Workspace, Microsoft 365, etc.) to forward incoming mail for support@yourdomain.com to your Intercom forwarding address. This preserves your existing MX records and allows quick rollback.
   • MX record change (full cutover): Update MX records to point directly to Intercom's mail servers. This is a harder cutover with longer rollback time (TTL-dependent, typically 1–24 hours).
3. Test with a canary address first. Route a low-volume alias (e.g., support-test@yourdomain.com) to Intercom before switching the primary address. Verify that conversations are created correctly, auto-replies fire, and Workflows trigger.
4. Cut over during low-traffic hours. Schedule the switch during your lowest-volume period. Monitor both Front (for stragglers) and Intercom (for incoming messages) for 2–4 hours after the cutover.
5. Disable Front inboxes post-cutover. Once Intercom is receiving all inbound email, disable or archive the corresponding Front inboxes to prevent agents from accidentally working in the wrong tool. Do not delete them — keep them in read-only mode for reference.

If you use Intercom's Messenger widget, deploy it to your website/app alongside or before the email cutover. Messenger is additive — it does not require DNS changes.

Step-by-Step Front to Intercom Migration Process

Order of operations matters. Contacts and company associations must exist in Intercom before you create conversations, otherwise requester attribution breaks silently and fixing it later requires deleting and re-creating conversations.

1. Audit Front data and define scope. Count conversations, contacts, tags, custom fields, inboxes, rules, and active webhooks. Decide which Front conversations become Intercom Conversations, which become Tickets, and which stay archived in Front.
2. Set up the Intercom workspace. Configure channels (including email domain verification and DNS records), teams, custom attributes (via Data Attributes API or UI), Saved Replies, and scaffold Workflows before loading any data.
3. Extract and deduplicate contacts. Pull contacts from Front via API. Deduplicate by email since Front allows duplicates but Intercom enforces uniqueness. Assign external_id values (preserve the Front contact ID).
4. Load contacts and companies into Intercom. Push companies first, then contacts with company associations. Store the resulting Intercom IDs — you will need them for conversation creation.
5. Load conversations with parts. Create each conversation via POST /conversations with created_at set to the original Front timestamp. Add reply parts in chronological order via POST /conversations/{id}/reply with correct author attribution (admin vs. contact). Add internal notes as conversation parts with type = "note".
6. Upload attachments. Download Front attachments locally (Front attachment URLs may be authenticated and time-limited). Re-host on S3 or equivalent if needed. Intercom accepts up to 10 image URLs per conversation creation call. Large attachments may need to be hosted externally and linked rather than uploaded directly. Individual files can be up to 100 MB via Messenger uploads, but inbound emails above 20 MB are rejected.
7. Apply tags. Tag conversations and contacts using the Intercom Tags API.
8. Rebuild webhooks. Decommission Front webhook subscriptions. Create equivalent Intercom webhook topics or Workflow-based triggers. Update downstream systems to handle Intercom's payload schema.
9. Execute DNS/email cutover. Follow the cutover plan from the DNS section above. Monitor both platforms during transition.
10. Validate. Run record-count reconciliation, verify timestamps, spot-check threading and attachment integrity.

# Creating a conversation in Intercom with original timestamp
import requests
import time
 
headers = {
    "Authorization": "Bearer YOUR_TOKEN",
    "Content-Type": "application/json",
    "Intercom-Version": "2.15"
}
 
payload = {
    "from": {"type": "user", "id": "intercom_contact_id"},
    "body": "Original message body from Front",
    "created_at": 1672531200  # Original Front timestamp as Unix epoch
}
 
response = requests.post(
    "https://api.intercom.io/conversations",
    json=payload,
    headers=headers
)
 
# Handle rate limiting with backoff
if response.status_code == 429:
    retry_after = int(response.headers.get("Retry-After", 10))
    time.sleep(retry_after)
 
# Handle duplicate contact conflict
if response.status_code == 409:
    error_data = response.json()
    # Response body: {"type":"error.list","errors":[{"code":"conflict",
    # "message":"A contact matching those details already exists with id=..."}]}
    existing_id = error_data["errors"][0]["message"].split("id=")[1]
    print(f"Contact already exists with Intercom ID: {existing_id}")

How Long Does a Front to Intercom Migration Take?

For a typical mid-size team (30 agents, 150K conversations), expect 3–6 weeks end-to-end. A clean-break move can be done in 1–2 weeks; a full history import with workflow rebuilds can take 6–10 weeks, especially if you discover timestamp or dedup issues during the pilot.

Phased timeline:

Risk register:

Fin AI and Migrated Data

If Fin AI is a primary reason for switching to Intercom, understand how migrated data interacts with it:

• Fin AI draws from your Intercom Help Center (Articles), external URLs, and uploaded content sources — not from historical conversation data. Migrated conversations do not automatically train Fin.
• However, migrated conversations affect Fin's handoff behavior. Fin uses conversation context (including prior parts) when deciding to hand off to a human agent. Poorly structured migrated conversations — with missing author attribution or garbled HTML — can confuse Fin's context window.
• Custom Answers in Fin must be created manually. There is no migration path from Front's canned responses to Fin Custom Answers.
• Recommendation: After migration, audit a sample of migrated conversations that Fin is likely to encounter (open/active conversations) and verify that Fin's behavior is acceptable. Exclude archived historical conversations from Fin's active scope if they contain low-quality or malformed data.

GDPR and Data Compliance During Migration

Running Front and Intercom in parallel creates a period where customer data exists in two systems simultaneously. For teams subject to GDPR, CCPA, or similar regulations:

• Data Processing Agreements (DPAs): Ensure you have signed DPAs with both Front and Intercom covering the parallel operation period. Both vendors offer standard DPAs.
• Data minimization: Only migrate the data you actually need in Intercom. If conversations older than 2 years have no operational value, exclude them from migration to reduce your compliance surface.
• Deletion obligations: If a customer exercises their right to deletion during the migration window, you must delete their data from both Front and Intercom. Have a process for this.
• Data residency: Intercom offers US and EU data hosting. Confirm that your Intercom workspace region matches your data residency requirements before starting the migration.
• Post-migration cleanup: Once Front is decommissioned, delete customer data from Front in accordance with your retention policy. "Read-only mode" does not exempt you from deletion requests.

What Happens to Customers During Migration?

Your end-users will not experience downtime during a well-executed migration. Front and Intercom can run in parallel — new conversations continue in Front while historical data loads into Intercom.

The bigger customer-facing change is the Messenger shift. If your team is adopting Intercom's Messenger widget, customers will see a completely new support interface. This is not just an internal tool swap — plan customer communications for the transition, update help center links, and brief your customer success team. Consider deploying the Messenger widget 1–2 weeks before the email cutover so customers can acclimate.

If history is imported, old email conversations will appear in Intercom's Inbox but may not thread identically to how they appeared in Front. If history is archived instead, the common pattern is to keep Front in read-only mode for 6–12 months as a lookup tool for agents who need to reference past interactions. Note that Front subscription costs continue during this period — factor this into your migration budget.

SLA policies in Front do not transfer. Intercom SLAs must be configured from scratch, and historical SLA compliance data stays in Front.

One operational detail worth noting: if you adopt Intercom Tickets, when a customer replies to a ticket in Waiting on customer or Resolved state, Intercom automatically moves it back to In progress. That affects queue behavior and SLA expectations. (intercom.com)

What Can't Be Migrated from Front to Intercom?

Be explicit with stakeholders about what does not transfer:

• Rules and automations → Must be rebuilt as Intercom Workflows (visual builder, completely different paradigm). This is often the most time-consuming post-migration task — expect 1–2 weeks for a team with 20+ rules. See our guide on why automations are a migration's secret saboteur.
• Analytics dashboards → Must be rebuilt in Intercom's Reports module. Historical trend data does not transfer.
• Shared drafts and draft states → No equivalent in Intercom.
• Conversation links → No native equivalent.
• Per-inbox signatures → Intercom uses workspace-level sender identity and email templates.
• Integration configurations (Salesforce sync, Slack setup, Jira links) → Must be reconfigured using Intercom's App Store integrations.
• Webhook subscriptions → Must be decommissioned in Front and rebuilt as Intercom webhooks or Workflow triggers. Downstream consumers need payload schema updates.
• Channel routing logic (inbox-scoped in Front) → Intercom routing uses Workflows, team assignment rules, and Fin AI. Must be redesigned.
• Contact group membership → Intercom segments are dynamic and filter-based. Use tags as a workaround for static groupings.
• SLA timer state and historical compliance data → SLA policies recreated from scratch; past performance data stays in Front.
• Fin AI Custom Answers → No migration path from Front canned responses. Must be created manually.

For a complete pre-migration checklist, see our Front migration checklist.

Edge Cases and Known Challenges

• Duplicate contacts. Front allows multiple contacts with the same email. Intercom enforces uniqueness and returns a 409 Conflict error with a body containing the existing contact's ID. Define your merge strategy before you start loading data.
• Multi-channel conversations. A single Front conversation spanning email and SMS becomes ambiguous in Intercom, where conversations are typically tied to one channel. Decide whether to split or flatten.
• 500-part limit. Intercom caps conversation parts at 500 per conversation. Long-running Front conversations with hundreds of messages and internal notes will hit this ceiling and must be truncated or split.
• Merged Front conversations. Messages and comments API calls for merged conversations can return HTTP 301 redirects. If your extractor does not follow the redirect and consolidate correctly, you will undercount history. (dev.frontapp.com)
• HTML rendering differences. Front messages use rich HTML. Intercom conversation parts support HTML in replies, but the initial conversation body does not support HTML. Complex email templates with nested tables or CSS may also render differently in Intercom's UI.
• Attachment URL expiration. Front attachment URLs served via the API are authenticated. Test whether they remain accessible for the full duration of your migration. If they expire, download attachments to local/cloud storage before starting the Intercom load phase.
• Attachment size limits. Intercom accepts up to 10 image attachment URLs per conversation creation call. Messenger uploads allow individual files up to 100 MB, but inbound emails above 20 MB are rejected. Old oversized attachments may need external hosting.
• Front Contact Lists API change. The old /contact_groups endpoint is deprecated — use /contact_lists (renamed September 2025). (dev.frontapp.com)
• Company ID immutability. In Intercom, company_id cannot be updated after creation. Plan your company identifier scheme carefully before the first API call. If you use Front's internal company IDs and later need to align with your CRM, you cannot change them.
• GDPR deletion requests during migration. If a customer requests deletion while data exists in both Front and Intercom, you must honor the request in both systems. Have a documented process before starting.

Validation and Testing After Migration

Validation is where migrations succeed or fail. Run these checks before go-live:

• Record-count reconciliation. Conversations exported vs. created. Contacts vs. contacts. Messages vs. conversation parts. Tags applied vs. expected.
• Timestamp verification. Confirm imported conversations show original dates, not migration-date timestamps. This is the most common failure mode. Check at least 20 conversations across different date ranges.
• Sampling strategy. Random sample of 50–100 conversations across date ranges. Manually verify threading, part ordering, author attribution, and attachment integrity. For long threads, do not rely on Intercom's readback alone — the retrieve-conversation endpoint returns only the 500 most recent parts.
• Attachment spot-check. Verify that attachment URLs are accessible and rendering correctly in Intercom's UI. Test across file types (images, PDFs, CSVs).
• Agent UAT. Have 2–3 agents review their own recent conversations in Intercom Inbox and flag discrepancies. Test that Workflows and Saved Replies work with migrated data.
• Fin AI behavior check. If Fin AI is enabled, test it against open migrated conversations to verify it handles context correctly and does not produce confused responses from malformed historical data.
• Email routing verification. Send test emails to your support address and confirm they arrive in Intercom (not Front) after the DNS cutover.
• Rollback plan. Keep Front active in read-only mode for 8–12 weeks post-migration as a fallback archive. Document the steps to revert DNS/email routing if critical issues emerge.

For a detailed post-migration QA framework, see our post-migration QA checklist.

Should You Migrate Front to Intercom In-House or Use a Service?

In-house works when: you have fewer than 10K conversations, a simple setup (1–2 inboxes, no custom fields, no webhooks), available engineering time (budget 80–160 hours), and a clean-break approach is acceptable.

In-house is risky when: you have a large conversation history that must be preserved, a multi-channel setup, active webhooks feeding downstream systems, a tight timeline, the Tickets vs. Conversations routing decision is non-obvious, or your engineering team is needed elsewhere.

The hidden costs of DIY are real. The conversation history timestamp problem alone can consume 2+ weeks of engineering time to debug. Broken requester attribution — where messages are attributed to the wrong contact — lost internal notes, and duplicate contacts from failed dedup are the most common failure modes in self-managed migrations.

ClonePartner has completed 1,500+ data migrations across helpdesk, CRM, HRIS, ATS, and ITSM platforms. For Front-to-Intercom specifically, the service handles conversation history import with timestamp preservation, requester attribution, contact deduplication, company mapping, the Tickets vs. Conversations routing decision, custom attribute mapping, and tag migration.

Front to Intercom Migration FAQ

How long does a Front to Intercom migration take? For a mid-size team (30 agents, 150K conversations), expect 3–6 weeks end-to-end including planning, test migration, conversation history loading, Workflow rebuilds, DNS cutover, and validation. Conversation history migration is the primary bottleneck due to API rate limits.

Can I keep my full Front conversation history in Intercom? Yes, through an API-led approach. Intercom's Conversations API accepts a created_at timestamp field for migrating past conversations. Timestamp preservation must be tested on your specific plan in a sandbox workspace before committing to a full import. Conversations are capped at 500 parts.

What data can't be migrated from Front to Intercom? Rules/automations, shared drafts, conversation links, per-inbox signatures, analytics dashboards, SLA compliance history, webhook subscriptions, and integration configurations cannot be migrated programmatically. They must be rebuilt manually in Intercom.

Can I migrate Front rules and automations to Intercom Workflows? No automated path exists. Front rules are simple condition-action pairs. Intercom Workflows are visual, multi-step, event-driven automations. Each rule must be manually redesigned as a Workflow.

Should I use Intercom Tickets or Conversations for migrated Front data? Use Intercom Conversations for real-time, chat-like exchanges. Use Tickets for tracked async issues like bug reports, feature requests, and back-office follow-ups. Many successful migrations use both, routed by Front inbox, tag, or case type. Finalize this routing decision during the discovery phase.

What happens to email routing during the migration? You must update DNS (MX records or email forwarding rules) to route inbound support email from Front to Intercom. Use a forwarding rule for a reversible cutover, or update MX records for a full switch. Test with a low-volume alias before cutting over your primary support address.

Does migrated data train Fin AI? No. Fin AI draws from your Help Center articles, external URLs, and uploaded content — not from conversation history. However, migrated conversations do affect Fin's handoff behavior in active conversations, so data quality matters.

What about GDPR compliance during the migration? During parallel operation, customer data exists in both Front and Intercom. Ensure you have DPAs with both vendors, only migrate necessary data, and have a process for handling deletion requests across both systems.

Making the Right Call

The biggest decision is not API versus CSV. It is whether old Front threads are active enough to justify full replay inside Intercom, or valuable enough to keep as a Front archive while you start clean. Answer that honestly, and the migration method usually becomes obvious.

Start with a data audit. Test timestamp behavior in an Intercom sandbox before writing a single line of production migration code. Plan the DNS/email routing cutover with the same rigor as the data migration. And plan the Messenger rollout as a customer communication project, not just an engineering task.