Summarize this documentation using AI
Iterable and Customer.io are closer in architecture than most platform comparison articles acknowledge. Both are event-driven. Both are API-first. Both treat user behavioral data as the primary input for lifecycle logic. A team migrating between them is not changing paradigms — they are changing implementations of the same paradigm.
What drives the migration from Iterable to Customer.io is typically one of three things: operational cost — Iterable's pricing model at scale is significantly higher than Customer.io's for programs that don't need Iterable's full enterprise feature depth; operational overhead — Iterable's enterprise model comes with platform complexity that smaller lifecycle teams find disproportionate to what their program requires; or developer preference — Customer.io's API is lighter, its documentation is developer-friendly in a different way, and its Liquid templating is more directly accessible for teams that want to do sophisticated personalization without Iterable's Handlebars templating.
The migration is technically the most straightforward of any Customer.io migration path, because the starting data model is the closest match. But it requires the same discipline on event schema design, suppression handling, and Campaign rebuild as any other migration.
Why Iterable Teams Move to Customer.io
Pricing at mid-market scale. Iterable is priced for enterprise. Its feature depth — workflow complexity, catalog functionality, multi-channel depth — is built for programs that use all of it. Teams with 5–20 active Journeys, primarily email and push, and a mid-market contact volume often find that Customer.io delivers comparable lifecycle capability at a meaningfully different price point.
Operator accessibility. Iterable's Journey builder is capable but complex. Teams with smaller lifecycle teams — one or two operators without dedicated platform administrators — find Customer.io's Campaign and Journey builder more directly accessible. The learning curve is shorter, the day-to-day management is lighter, and the Liquid templating is more directly editable without Iterable's Handlebars abstraction layer.
Handlebars vs. Liquid. Iterable uses Handlebars for template personalization. Customer.io uses Liquid. For lifecycle teams that want to write expressive conditional logic, loops, and dynamic content directly in the template without helper functions or custom template helpers, Liquid's syntax is more flexible and more directly translatable to complex personalization requirements. This matters for teams building personalized email flows without manual work at scale.
Catalog functionality → event property depth. Iterable's Catalog feature allows dynamic content insertion from a data table. Customer.io doesn't have an exact Catalog equivalent, but for teams whose Catalog use was powering product recommendation personalization, Customer.io's Liquid loops through event properties (a recommended_items array on a recommendation_generated event, for example) can achieve the same outcome with a different architecture. For teams whose Catalog was doing something more complex, this gap needs explicit evaluation before migration.
The Architecture Difference: Iterable vs. Customer.io
Iterable's model: Event-driven with list-and-field underpinnings. Users have user fields. Events trigger Journey entry. Segments combine field conditions and event history. Journeys use Handlebars for personalization. Catalog enables dynamic content from uploaded data tables. Channel support is broad — email, push, in-app, SMS, web push.
Customer.io's model: Event-driven with Attribute-and-event architecture. People have Attributes. Events trigger Campaign entry. Segments combine Attribute conditions and event history using Liquid-accessible data. Campaigns use Liquid for personalization. No Catalog — dynamic content comes from event properties or webhook-fetched Attributes. Channel support is comparable for email, push, in-app, and SMS.
The migration consequence: Iterable user fields map to Customer.io Attributes. Iterable Events map to Customer.io Events — naming convention review is worth doing during migration, as this is the cleanest opportunity to rationalize an event schema that may have accumulated inconsistencies. Iterable Journeys become Customer.io Campaigns. Iterable Catalog personalization must be rearchitected using Customer.io's Liquid event property access or pre-fetched Attributes.
What Transfers and What Doesn't
Transfers With Mapping ✅
User identity and fields. Iterable's user fields (email, userId, and custom fields) map to Customer.io Attributes. Map Iterable's userId to Customer.io's id field for consistent identity.
Email suppression. Iterable's unsubscribed and bounced users export cleanly. Map unsubscribed to Customer.io global suppression. Map bounced to email suppression. Both move before active users.
Event schema (with review). Iterable Custom Events map to Customer.io Events. Use the migration as an opportunity to review and rationalize event names and property conventions — inconsistencies that accumulated in Iterable are cheaper to fix during migration than after Customer.io Campaigns are built.
Must Be Rebuilt 🔄
Every Journey becomes a Campaign. Iterable Journeys cannot be imported into Customer.io. Rebuild in priority order: activation → retention → re-engagement. For each Journey, convert Iterable's trigger conditions to Customer.io event entry. The branching logic translates conceptually from Iterable's if/else conditions to Customer.io's Journey branches, but must be rebuilt natively.
Catalog personalization → Liquid event property access. For every Iterable template using Catalog lookups for dynamic content, assess whether the data exists as an event property (which Customer.io's Liquid can access directly) or needs to be fetched via webhook action before the message step. Design the replacement approach for each Catalog use case during the pre-migration audit.
Handlebars → Liquid. Every Iterable template using Handlebars personalization must be rebuilt in Customer.io Liquid. The logic is translatable; the syntax differs. Handlebars' {{user.firstName}} becomes {{ customer.first_name }}. Handlebars' conditional helpers ({{#if}}/{{/if}}) become Liquid's {% if %}{% endif %}. The conversion is methodical, not creative.
Migration Checklist: Iterable to Customer.io
Pre-Migration Audit
- Inventory all active Journeys — trigger event, channel mix, entry volume, 30-day performance.
- Identify all Catalog tables in active use — assess Customer.io replacement approach for each.
- Review event schema for naming inconsistencies — resolve before migration rather than after.
- Document all user fields — map to Customer.io Attribute data types.
- Assess channel scope — confirm Customer.io mobile SDK covers push and in-app requirements.
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 fields — map to Customer.io Attributes.
- Segment import by engagement tier.
Technical Setup
- Validate Customer.io API and SDK event instrumentation — confirm events fire with correct properties.
- Configure sending domain — DKIM, SPF, DMARC. Reference email deliverability channel health standards.
- Configure Customer.io mobile SDK if push or in-app channels are in scope.
- Build webhook actions for any Catalog personalization that requires external data fetch.
Campaign Rebuild and Go-Live
- Rebuild all Journeys as Customer.io Campaigns — event triggers, branching logic, timing.
- Rebuild all templates in Customer.io Liquid — convert Handlebars syntax systematically.
- Replace Catalog dynamic content with Liquid event property access or webhook-fetched Attributes.
- QA every Campaign before activating.
- Deactivate Iterable Journeys as Customer.io Campaigns go live.
- Deliverability warm-up — 4–6 weeks, engaged segment first.
Stakeholder Expectations
Lifecycle team: Budget 8–12 weeks for a typical Iterable migration. The Catalog replacement is the most Iterable-specific challenge — assess its scope in the pre-migration audit, as complex Catalog implementations add time. Channel scope (if push and in-app are included) adds engineering time.
Engineering: Event schema review and Customer.io API/SDK validation: 2–3 weeks. If Customer.io's mobile SDK is replacing Iterable's, plan a coordinated app release. Our events and attributes architecture service manages the schema review and instrumentation spec.
Leadership: The financial case for this migration is typically the primary driver. Validate the cost-benefit over a 24-month horizon, factoring in migration cost against Iterable contract cost. Use the customer retention impact calculator to establish the performance baseline before migration.
Working With Propel
Propel is a certified Customer.io partner. Our Iterable migration practice covers the Catalog-to-Liquid replacement strategy, Journey rebuild, Handlebars-to-Liquid template conversion, and the lifecycle strategy review built into every Campaign rebuild.
See the migrate to Customer.io guide for the full migration framework. Then talk to us about the Iterable-specific scope.
Frequently Asked Questions
Does Customer.io have a Catalog equivalent?
Not directly. Dynamic content from Catalog tables is replicated in Customer.io using Liquid access to event properties (arrays of items on a triggering event) or via webhook actions that fetch external data and store it as Attributes before the message step. The right approach depends on what the Catalog was serving.
How does Handlebars compare to Liquid in practice?
Liquid is more expressive for complex conditional logic and loops. Handlebars is more constrained by default, requiring custom template helpers for non-trivial logic. Teams that have been working around Handlebars' limitations in Iterable typically find Customer.io's Liquid a more direct tool for the personalization they wanted to build.
Does Customer.io's push support match Iterable's?
Customer.io's mobile SDK supports iOS and Android push notifications with rich push, deep links, and in-app messages. For most lifecycle push use cases, the capability is comparable. Advanced features specific to Iterable's push implementation should be confirmed against Customer.io's documentation before migration.
What's the biggest migration risk from Iterable to Customer.io?
The Catalog dependency assessment. Teams that have built significant personalization on Iterable's Catalog, especially for recommendation or dynamic product content, should assess the Customer.io replacement approach carefully before committing to the migration timeline.
How long does the email deliverability warm-up take?
4–6 weeks for a typical migration. Starting with your most engaged segment and expanding weekly is the standard approach. Monitor bounce and complaint rates daily through the warm-up period.
