Migrate from Intercom to Customer.io: When Support Tooling Isn't a Lifecycle Platform

Intercom is a customer communications platform built around support, onboarding chat, and in-product messaging. It is genuinely excellent at those things. The teams migrating from Intercom to Customer.io for lifecycle marketing are not leaving because Intercom is bad — they're leaving because they've discovered that lifecycle marketing and customer support tooling, when run from the same platform, create architecture compromises that hurt both functions.

Intercom's messaging model is conversation-centric. Its data model was designed for support threads, chat sessions, and in-product messages. Its Series automation builder was added to handle lifecycle email sequences, but it sits on top of a support-first architecture — which shows in the data model, the event tracking depth, the Liquid templating constraints, and the segmentation logic.

Customer.io was built from the ground up for behavioral lifecycle marketing. There is no support chat, no conversation inbox, no shared inbox team feature — just a clean, event-driven platform for building triggered Campaigns that respond to what users actually do. For teams that want their lifecycle marketing to be precisely that, the migration makes clear architectural sense.

What Intercom Lifecycle Marketers Run Into

Series vs. event-triggered Campaigns. Intercom's Series can trigger on user events and filter on attributes, but the builder's logic depth is limited compared to Customer.io's Journey builder. Complex conditional sequences — branch on event property, wait for a secondary event, branch again, send different content to each cohort — are buildable in Customer.io's Journeys but become unwieldy in Intercom's Series format.

User attribute depth. Intercom's user attributes are functional but the platform's data model treats them as support context (for identifying users in conversations) rather than as lifecycle marketing data. The segmentation and personalization depth that event properties enable in Customer.io is simply not the design priority in Intercom.

Liquid constraints. Intercom supports some Liquid for email personalization, but its implementation is constrained compared to Customer.io's full Liquid access. Teams building conditional content blocks, loops through event property arrays, or complex date logic find Customer.io's Liquid significantly more capable.

Separate tools for support and marketing. The cleanest outcome for teams migrating out of Intercom is typically to retain Intercom for what it's genuinely best at — in-product messaging, support chat, the conversation inbox — and move lifecycle email automation to Customer.io. This isn't a replacement; it's a functional unbundling that lets each tool do what it was designed for. How lifecycle marketing agencies drive revenue is almost always through tools that are purpose-built for lifecycle marketing — not multipurpose support platforms with marketing features bolted on.

The Architecture Difference: Intercom vs. Customer.io

Intercom's model: Conversation-centric and support-first. Users are identified as visitors or contacts. User attributes are support-context properties. Events can be tracked but are secondary to conversation and session data. Series handles automated email sequences. The in-product messenger is the platform's primary engagement surface.

Customer.io's model: Event-driven and lifecycle-first. People have Attributes and fire Events. Campaigns trigger on Events in real time. There is no conversation inbox, no support chat, no in-product messenger (Customer.io's in-app messaging is in-app, not chat). Every feature is built for lifecycle marketing precision, not support context management.

The migration consequence: Intercom's user attributes map to Customer.io Attributes. Intercom's tracked events map to Customer.io Events. Intercom's Series must be rebuilt as Customer.io Campaigns. Intercom's in-product messaging — if it's being migrated — requires Customer.io's mobile SDK or in-app message setup. Support functions stay in Intercom.

What Transfers and What Doesn't

Transfers With Mapping ✅

User attributes → Attributes. Every Intercom user attribute in active use across Series and segment conditions maps to a Customer.io Attribute. Document every attribute before migrating.

Tracked events → Events. Intercom tracked events map to Customer.io Events. Review naming conventions during the migration — this is the opportunity to rationalize event names that may have been defined pragmatically in Intercom rather than deliberately.

Email suppression. Intercom's unsubscribed users export to Customer.io global suppression before any active contacts. Hard bounces map to Customer.io email suppression.

Must Be Rebuilt 🔄

Every Series becomes a Campaign. Intercom Series cannot be imported into Customer.io. Rebuild in priority order: onboarding email sequences → trial conversion → retention → re-engagement. For each Series, identify the underlying product event that should serve as the Customer.io Campaign trigger — often the same event that triggered the Intercom Series, now firing directly to Customer.io. For teams looking to tighten their reduced customer churn with a better onboarding program, this rebuild is the moment to make onboarding Campaigns genuinely event-adaptive rather than time-based.

In-app messaging (if migrating). If Intercom's in-product messenger was being used for lifecycle messaging rather than support, Customer.io's in-app message implementation requires SDK setup and is structurally different from Intercom's messenger. Assess in scope or out of scope before migration starts.

Segmentation. Intercom segments must be recreated in Customer.io using Attribute and event filters. The conditions are conceptually translatable; the syntax is platform-specific.

Stays in Intercom ❎

The support inbox and conversation management. Intercom remains the support tool. Customer.io handles lifecycle email and in-app messaging for product engagement. The two tools serve different functions for the same user — Intercom for support and in-product help, Customer.io for behavioral lifecycle marketing. This functional split is the standard outcome of this migration and it produces better results in both areas than the compromised single-platform model.

Migration Checklist: Intercom to Customer.io

Pre-Migration Decisions

• Define the functional split — determine which messaging functions move to Customer.io and which stay in Intercom.
• Confirm whether Intercom's in-app product messages move to Customer.io in-app messaging or remain in Intercom.

Pre-Migration Audit

• Inventory all active Intercom Series — trigger event, email count, 30-day performance.
• Document all user attributes in active use across Series and segments.
• Review tracked events for naming consistency before migrating to Customer.io.
• Design Customer.io event schema incorporating the trigger event review.

Data Migration

• Export unsubscribed users — import to Customer.io global suppression first.
• Export bounced users — import to Customer.io email suppression.
• Export active users with all relevant attributes — map to Customer.io Attributes.
• Segment import by engagement tier before uploading.

Technical Setup

• Instrument Customer.io API events per designed schema — validate every event fires correctly.
• Configure sending domain — DKIM, SPF, DMARC. Reference email deliverability channel health standards.
• Set up Customer.io in-app messaging SDK if in-app is in migration scope.

Campaign Rebuild and Go-Live

• Rebuild Intercom Series as Customer.io Campaigns — event triggers, branching, timing.
• Rebuild all email templates in Customer.io with Liquid personalization.
• QA every Campaign before activating.
• Deactivate Intercom Series as Customer.io Campaigns go live.
• Deliverability warm-up — 4–6 weeks, engaged contacts first.

Stakeholder Expectations

Lifecycle team: Budget 6–10 weeks for a typical Intercom lifecycle migration. Intercom programs tend to be email-series-oriented without extreme Journey complexity — the Campaign rebuild is the primary time investment. If in-app messaging is in scope, add engineering time for SDK setup.

Support team: Intercom stays. The migration is a lifecycle marketing function split. Brief the support team that Intercom is not going away and that their workflows are unaffected.

Engineering: Customer.io event instrumentation: 1–3 weeks depending on event schema complexity. In-app messaging SDK adds scope. Our events and attributes architecture service manages the technical specification.

Leadership: The customer retention impact calculator is useful for establishing the post-migration performance baseline. Brief leadership on the deliverability warm-up period before the first month shows reduced send volume.

Working With Propel

Propel is a certified Customer.io partner. We have run Intercom-to-Customer.io migrations for SaaS teams navigating the support-tool-to-lifecycle-platform separation. Our practice covers the functional split planning, Series rebuild, and the lifecycle strategy review that every Campaign rebuild should include.

For the complete migration framework, see migrate to Customer.io. Then talk to us about the Intercom-specific migration.