Plain vs Front (2026): Architecture, TCO & Migration Guide

Pick Plain when support is part of your product and engineering workflow. Pick Front when support is an inbox-driven customer operations function that needs broad omnichannel coverage. That is the fast answer. The longer answer involves real differences in API design, data models, AI extensibility, total cost, and migration complexity that make the wrong choice expensive to unwind later.

The pattern we see across migrations: teams regret the wrong choice through add-ons, workaround code, or migration rework — not through missing headline features. This guide breaks down the architectural differences, total cost of ownership, compliance posture, and the technical realities of migrating between Plain and Front in 2026.

Platform Philosophy: Two Different Bets

Plain and Front solve the same problem — unifying customer conversations — but start from opposite assumptions about who owns the tool.

Plain positions itself as customer infrastructure for technical B2B teams. Conversations, customer data, AI agents, and automations are all programmable via API. The UI is a sensible default, but the API is the product. As Plain's documentation states, the platform is "built with this very GraphQL API we expose to you," meaning there is no gap between what the UI can do and what the API can do. (plain.com)

Plain's core customers reflect this: Vercel, n8n, Raycast, Stytch, Sourcegraph — engineering-led teams whose customers ask questions in code and whose support workflows loop tightly with product and engineering.

Front positions itself as a collaborative inbox for customer operations. Conversations look and feel like email threads, not numbered tickets. The core value is team collaboration: shared drafts, internal comments, assignment rules, and analytics layered on top of a unified inbox that pulls in email, SMS, live chat, social media, and voice. Front reached $100M ARR in August 2025, according to the company's own announcement. Its buyer is typically an operations lead, CX manager, or support director — not an engineer.

The distinction matters when you are choosing: Plain assumes your team will build. Front assumes your team will configure.

Architecture and API Depth

This is where the two platforms diverge most sharply.

Plain: GraphQL, MCP Server, Bring Your Own Agent

Plain exposes a fully public GraphQL API that mirrors every capability in the UI. If you can do it in the app, you can do it via API — no exceptions.

Key architectural features:

• GraphQL API with a fully typed TypeScript SDK
• Native MCP server (generally available) for connecting AI agents directly to the platform (help.plain.com)
• Bring Your Own Agent (BYOA) architecture — plug in any LLM, build custom AI agents on Plain's infrastructure
• Machine users with scoped API keys for automated actions
• Webhooks with configurable retry behavior and guaranteed at-least-once delivery; Plain documents webhook event ordering as per-customer (events for a given customer arrive in order) but not globally ordered across all customers
• Headless support portal — build a white-label customer portal using Plain's API with your own UI
• Thread fields and customer cards to extend the data model and pull live context from your own systems

Plain uses a single GraphQL endpoint, which lets you fetch a thread, its customer, and recent timeline entries in one network request — significantly reducing round-trips compared to a REST approach.

# Fetch a Plain Thread with Customer context in a single request
query GetThreadContext($threadId: ID!) {
  thread(id: $threadId) {
    id
    title
    customer {
      email
      externalId
    }
    timelineEntries(first: 5) {
      edges {
        node {
          __typename
          ... on EmailEntry {
            textContent
          }
          ... on NoteEntry {
            markdownContent
          }
        }
      }
    }
  }
}

A comparable webhook payload from Plain for a thread status change looks like:

{
  "type": "thread.status_changed",
  "payload": {
    "threadId": "th_01HX...",
    "previousStatus": "TODO",
    "newStatus": "DONE",
    "changedAt": "2026-08-01T14:22:00Z",
    "customerId": "c_01HX..."
  }
}

Rate limits: Plain documents 450, 600, and 1,000 requests per minute by plan, with complexity-based throttling on queries rather than raw request counts. (plain.com)

Front: REST API with Plan-Based Rate Limits

Front offers a JSON-over-HTTPS REST API with endpoints for conversations, messages, contacts, tags, inboxes, and teammates. Authentication is via Bearer token or OAuth for partner integrations. As of August 2026, Front also documents an official MCP server in open beta. (dev.frontapp.com)

The critical constraint is rate limiting:

Burst limits also apply per resource: 5 requests/second for conversations, messages, and channels; 1 request/second for exports. Additional capacity is available as a paid add-on at $200/month per additional 100 RPM. (help.front.com)

Webhook behavior: Front webhooks use HTTP POST with HMAC-SHA256 signatures for payload validation. Front does not guarantee event ordering across conversations and recommends treating webhooks as triggers to re-fetch current state via the REST API, rather than as an ordered event log.

Front's API is capable for standard integrations, but it was added to a UI-first product. If you are building custom AI agents, real-time sync, or running scripted migrations, the gap between Plain's 450–1,000 RPM and Front's 50–200 RPM is significant. At Enterprise limits (200 RPM), extracting 100,000 Front conversations — assuming 3 API calls per conversation to fetch messages, comments, and attachments — requires a minimum of 25 hours of extraction time under ideal conditions, without accounting for burst limits or retry overhead.

Front also supports custom channels via API, allowing you to sync proprietary messaging systems into the Front UI — a useful escape hatch for channel types Front does not natively cover.

Data Model Comparison

Understanding how each platform structures data is required before attempting any integration or migration.

The Front Data Model

• Workspaces: High-level organizational boundaries (e.g., Support, Sales)
• Inboxes: Channel collections within a workspace; ticketing can be enabled per inbox with statuses and IDs
• Conversations: The parent object representing a customer inquiry
• Messages: Individual inbound or outbound communications within a conversation
• Comments: Internal notes attached to a conversation
• Contacts: External users communicating with your team
• Accounts: Company-level groupings of contacts
• Custom fields: Available on contacts, accounts, and conversations

The Plain Data Model

• Tenants: The B2B company or workspace the customer belongs to
• Customers: Individual users, with customer cards for live context from your systems
• Threads: The ongoing issue or request — the primary unit across all channels
• Timeline Entries: A unified ledger of everything that happened in a thread (emails, Slack messages, API events, internal notes, Linear issue status changes)
• Labels: Metadata applied to threads for routing and analytics
• Thread fields: Custom data extensions on threads

Channel Coverage

The channel story is straightforward: Plain dominates developer-native messaging; Front dominates traditional and consumer support channels.

Plain treats Slack, Microsoft Teams, Discord, email, and in-app as first-class channels in a single queue. When a customer messages in Slack, follows up via email, and submits a form, agents see one continuous thread with complete history.

Front covers the widest traditional channel mix — email, SMS, WhatsApp, social media — making it the stronger choice when customers reach out through consumer channels. But Front's Slack and Teams integrations are notification-level, not native bi-directional support channels.

The deciding question: Where do your customers actually contact you? If they are in Slack Connect channels and Discord, Plain is built for that. If they are emailing, texting, and DMing on Instagram, Front handles it natively. (help.plain.com)

Agent Experience: Working a Queue in Each Tool

This dimension is absent from most comparison guides and is where real usability differences emerge.

Plain's agent UI is optimized for engineers and technical agents. The interface is minimal: a thread list on the left, the timeline on the right, with keyboard-first navigation. Bulk actions (snooze, label, assign) are available via multi-select. Search is powered by the same GraphQL schema the API uses — typed and filterable by customer, label, status, and thread field. Context from customer cards (subscription tier, recent API usage, open GitHub issues) appears inline without navigating away. The trade-off: there is no persistent "canned responses" library or WYSIWYG response editor comparable to what Front provides.

Front's agent UI is built around the inbox metaphor. Agents familiar with Gmail will orient immediately. Keyboard shortcuts follow email conventions (e.g., R to reply, E to archive). Shared drafts, conversation assignments, and SLA countdown timers are visible without leaving the thread view. Bulk actions across queue — mass assign, tag, archive — are well-implemented. The Copilot panel (AI add-on) surfaces suggested replies and summaries in a sidebar without interrupting the main thread view. For high-volume queues where agents process 80+ conversations per day, Front's bulk management and macro system (saved message templates with variable substitution) provide meaningful efficiency.

The practical split: Agents responding to technical questions with custom context (checking a customer's API usage, linking a GitHub issue) prefer Plain's model. Agents managing high-volume transactional queues with repeatable answers prefer Front's macro and bulk-action system.

Compliance and Security Posture

This dimension is frequently absent from comparison guides but is a procurement gate for enterprise buyers.

Key compliance implications:

• HIPAA-regulated industries should not evaluate Plain at this time. Front's Enterprise plan supports BAA agreements.
• EU-based companies with strict data residency requirements can use either platform, but should confirm current region availability with each vendor before signing — these configurations change.
• SSO/SCIM availability at the Professional tier ($65/seat) gives Front a meaningful advantage over Plain, where SSO requires the Frontier tier at custom pricing. If your security team mandates SSO, this affects your minimum viable plan and therefore your TCO floor.

SLA Configuration Depth

Both platforms support SLAs, but with different configurability.

Front offers SLA policies configurable per inbox with rules based on conversation tags, contact segments, or custom fields. SLA policies support first response time, resolution time, and next response time targets, with breach escalation rules (email alerts, assignment changes). SLA reports are available at inbox and agent level. Configuration is UI-driven without requiring API work.

Plain supports SLA configuration on the Horizon plan and above. SLA policies can be set per label or tenant, with breach notifications surfaced in the UI and via webhooks. Plain does not currently document the same granularity of next-response-time SLAs as Front. For teams with complex SLA trees across multiple customer tiers, Front's SLA configuration is currently more mature.

Pricing and Total Cost of Ownership

Both platforms use per-seat pricing, but the total cost depends on add-ons, AI usage, and tier requirements. All pricing below is as documented in August 2026.

Plain Pricing

Plain includes its AI agent Ari on every plan at no per-resolution cost. The internal AI assistant Sidekick uses a credit system: 2,000 credits/month on Foundation, 15,000 on Horizon, custom on Frontier. Viewer seats are free across all plans — a real savings when engineering, product, and success teams need visibility without becoming full agents. (plain.com)

Front Pricing

Front's AI features are where costs escalate. On Professional and below, AI is a paid add-on:

• Copilot: +$20/seat/month
• Smart QA: +$20/seat/month
• Smart CSAT: +$10/seat/month
• Autopilot: Per-conversation pricing — Front does not publish Autopilot per-conversation rates publicly; these are negotiated at contract time for Enterprise accounts. Request a quote from Front's sales team before including Autopilot in TCO projections.

Onboarding is mandatory for Front contracts above $25,000. (front.com)

TCO Comparison: 10-Seat Team

Hidden Cost Drivers

The API tax. Front defaults to 50–200 RPM and sells extra capacity at $200/month per 100 RPM. Plain documents 450–1,000 RPM. If you are planning bidirectional sync, heavy reporting, AI agents, or scripted migration validation, that gap should be modeled early. At Enterprise limits, extracting 100,000 conversations from Front requires a minimum of 25 hours under ideal conditions.

File handling. Plain documents a 6 MB combined limit for email attachments. Front varies by channel: 25 MB for Gmail, 100 MB for Office 365, 19.5 MB for generic SMTP. If your team routinely shares crash logs, CSV exports, or annotated PDFs, this is not a small detail. (plain.com)

Identity. SSO/SCIM requires Frontier (custom pricing) on Plain and Professional ($65/seat) on Front. If security mandates SSO, neither platform should be priced from its entry plan. Front's lower SSO tier is a meaningful advantage if SSO is a procurement requirement.

Engineering time. Plain requires engineering resources to implement fully. Front can be set up by an operations manager in an afternoon. Plain's highest value is unlocked when developers integrate it into your product backend. That engineering investment is a real cost that does not show up on a pricing page.

AI Strategy: Infrastructure vs. Modules

Plain and Front take fundamentally different approaches to AI.

Plain's approach: infrastructure. Plain provides the platform — customer context, conversation threading, response APIs — and lets you bring whatever AI works best. Ari, their customer-facing AI agent, is included on every plan and can be grounded in your docs. The real differentiator is the BYOA architecture: build and deploy custom AI agents using Plain's GraphQL API and MCP server, orchestrate multiple agents, and swap models without vendor lock-in. n8n, a workflow automation platform that runs its own support on Plain, has publicly described building a custom AI agent on Plain's API that handles 60% of support tickets autonomously, with a stated goal of 80% AI resolution by end of 2026. (n8n case study, plain.com)

Front's approach: modules. Front ships AI as discrete features — Copilot for agent assist, Smart QA for quality scoring, Smart CSAT for satisfaction prediction, Autopilot for auto-resolution. These are polished, ready-to-use features requiring no engineering effort. The trade-off: they are priced as add-ons, Autopilot pricing is not publicly disclosed, and you cannot swap in a different model or customize the underlying agent behavior.

For a technical team that wants to build custom AI workflows — an agent that queries your internal database, checks subscription status, and drafts a response with product-specific context — Plain gives you the infrastructure. For a support team that wants AI assist out of the box without engineering involvement, Front's modular approach ships faster.

Integration Ecosystem

Plain focuses on the engineering toolchain: Linear, Jira, Shortcut, GitHub Issues, Salesforce, HubSpot CRM. You can create and link issues directly from a thread, keeping the product feedback loop tight. Plain does not have a large app marketplace — the assumption is that you will use the API to build what you need.

Front has a significantly larger marketplace with 130+ integrations: CRMs (Salesforce, HubSpot), project management (Asana, Jira, Monday.com), e-commerce (Shopify), voice (Aircall, Dialpad), and dozens more. For teams that rely on point-and-click configuration rather than API development, Front's ecosystem is materially broader.

Migration: What Maps, What Breaks, and How to Cut Over

In actual migrations, the row count is rarely the hard part. The hard part is rebuilding meaning: statuses, tags, field semantics, routing logic, knowledge base structure, and the workflow decisions nobody documented.

Exporting from Front

Front's data export is not self-serve. A company admin must request it from Front's Support team, and Support confirms admin status before processing (approximately 72 hours based on documented support SLAs). The export arrives as CSV files organized by inbox.

What the export excludes: individual-inbox data, contact data, message templates, tags, and comments. If you rely on the raw export alone, you lose significant operational context. This limitation pushes most teams toward API-based extraction — but Front's rate limits (50–200 RPM) make large-scale exports slow.

Extraction time at scale: At Enterprise limits (200 RPM), a workspace with 100,000 conversations requires approximately 3 API calls per conversation to fetch messages, comments, and attachments separately. That is 300,000 API calls minimum — 25 hours of continuous extraction at theoretical maximum throughput, before accounting for burst limits (5 req/sec per resource), retry overhead from transient errors, and the 1 req/sec cap on export endpoints. Real-world extraction for 100,000 conversations typically runs 3–5 days. (help.front.com)

Exporting from Plain

Plain's GraphQL API exposes everything the UI shows, so programmatic extraction covers the full data model: threads, messages, customers, customer groups, labels, and timeline events. The higher rate limits (450–1,000 RPM) make bulk extraction significantly faster than most competing platforms. At 1,000 RPM (Frontier), the same 100,000-conversation dataset that takes 3–5 days to extract from Front can be extracted in approximately 5–10 hours from Plain, depending on query complexity and pagination depth.

Front → Plain Migration

Plain has an official Front importer available on Horizon and Frontier plans. It covers conversation history, customers, and tags/labels. Workflows and automations do not migrate and must be rebuilt. Ongoing sync is one-way for new records, not a full mirror. (help.plain.com)

For teams doing custom migrations or needing more control, the key technical steps are:

1. Map Users and Workspaces. Extract all Front Teammates via the /teammates endpoint. Map their Front IDs to corresponding Plain User IDs. Ensure all historical actors exist in the target, or attribute actions to a generic "System Migration" user to avoid foreign key errors.

2. Convert HTML to Markdown. Front stores email bodies as HTML. Plain prefers Markdown for its UI and internal notes. Run HTML through a parser like Turndown (Node.js) before pushing to Plain's GraphQL mutations. Failure to clean up nested blockquotes — common in long email threads — produces unreadable timelines in Plain.

3. Translate Tags to Labels. Export shared Front tags and map them to Plain Labels. Front tags can be private or shared; only shared tags should migrate.

4. Reconstruct the Timeline. This is the most complex phase. For each Front Conversation, fetch all Messages and Comments. Merge them into a single array sorted by created_at timestamp. Map Front Messages to Plain EmailEntry mutations and Front Comments to NoteEntry mutations. The merge is necessary because Front's API returns messages and comments in separate paginated endpoints with no unified timeline — a structural difference from Plain's TimelineEntry model that requires custom stitching logic.

5. Handle Attachments. Do not pass raw base64 attachment data directly between the APIs for files exceeding Plain's 6 MB limit. Download attachments from Front to an intermediate S3 bucket, generate a secure URL, and pass the URL to Plain to avoid payload size limits and timeout errors.

6. Manage Rate Limits. Implement exponential backoff for Front's REST API (recommended initial backoff: 1 second, max: 60 seconds). Batch GraphQL mutations on the Plain side where possible, and use a queueing system (like Redis/BullMQ) to control extraction rate from Front. Target 60–70% of your plan's RPM ceiling to leave headroom for burst limit enforcement.

Migration failure modes by data volume:

Plain → Front Migration

Front can import the most recent 50,000 messages from connected Gmail or Office 365 mailboxes. For broader historical imports, Front documents an Import message endpoint requiring sender, recipients, body, external ID, created time, metadata, and supports attachments up to 25 MB. (help.front.com)

The model mismatch creates specific challenges. Plain's customer cards and timeline events do not have neat 1:1 equivalents in Front. The closest destinations are Front accounts, contact and account custom fields, conversation custom fields, and application objects via Connectors. Customer context can usually be preserved, but it needs redesign rather than lift-and-shift mapping. (help.plain.com)

Knowledge base migration is another place teams get surprised. Front's URL-based KB importer supports Help Scout, Intercom, and Zendesk — Plain is not on that list. Plain-to-Front KB moves typically mean CSV import or manual restructuring. (help.front.com)

Note that Front splits most channel-type conversations into a new conversation after 500 messages (custom channels at 1,000; SMS/WhatsApp at 10,000). Long Plain threads imported into Front may be split, which can break thread-level analytics and customer history continuity.

Migration Timeline

Total for a workspace under 50,000 conversations: 2–3 weeks. Larger datasets (50,000–200,000 conversations) typically require 4–6 weeks. Datasets above 200,000 conversations require a sharded extraction strategy and should be scoped individually.

The Decision Framework

When Neither Is the Right Fit

Be honest about the gaps:

• High-volume, ticket-lifecycle support (500+ agents, complex SLA trees): Neither Plain nor Front matches Zendesk's depth here. See our Zendesk vs Front comparison.
• E-commerce support with deep Shopify integration: Gorgias is the specialist. Front can handle it via marketplace apps, but it is not purpose-built.
• AI-first, in-app chat for PLG companies: Intercom leads this category. Plain can compete if you are willing to build your own agent.
• HIPAA-regulated industries: Do not evaluate Plain until HIPAA support is documented. Front's Enterprise plan is the appropriate starting point.

Do not pick Plain just because it feels modern if your team needs low-friction social or voice coverage and mostly point-and-click operations. Do not pick Front just because it is familiar if your roadmap depends on high-volume API work, headless support, or treating support data as part of your application stack.

Both platforms are well-built for their target audience. The mistake is choosing based on a feature checklist instead of asking: Where do our customers talk to us, and who on our team will own the tool? Answer those two questions, and the right platform usually becomes obvious.