Summarize this documentation using AI
Klaviyo is an exceptional ecommerce tool. If your business is built around a Shopify store, a repeat purchase cycle, and email-driven revenue attribution, Klaviyo is genuinely hard to beat.
But if your business is a SaaS product, a subscription service with a complex in-app lifecycle, or a consumer app where the purchase event is one signal among dozens — Klaviyo's ecommerce-native architecture starts to create friction instead of removing it. The moment your lifecycle program depends on product events, trial milestones, feature adoption signals, or behavioral conditions that don't originate from a Shopify webhook, you're building workarounds into a tool that wasn't designed for your use case.
That is the inflection point where teams move from Klaviyo to Customer.io. Not because Klaviyo failed, but because the product outgrew it.
At Propel, we work across both platforms. We understand Klaviyo's strengths and Customer.io's architecture with equal depth. This guide covers the migration with the specificity that operators need — not a feature comparison, but a practical walkthrough of what changes, what carries over, and where the migration risk sits.
Why Product and Subscription Teams Make the Switch
Klaviyo's trigger logic is ecommerce-native. Its fastest and most reliable triggers come from Shopify: "Placed Order," "Started Checkout," "Viewed Product." For teams whose product behavioral data doesn't originate from an ecommerce platform, feeding custom events into Klaviyo requires workarounds — custom API integrations, manual attribute updates, or Segment connections — that introduce latency and operational fragility.
Customer.io's trigger logic is event-native from the ground up. A trial_started event fires from your backend. A feature_unlocked event fires from your app. A payment_failed event fires from Stripe. All of these become Campaign entry conditions in Customer.io with no workaround — because the platform was designed to receive any event from any source and act on it immediately.
Klaviyo's flow builder is list-and-filter-based. Flows trigger on events, but the branching logic inside flows operates primarily on profile properties — the static attributes a person has at the time of evaluation. Customer.io's Journey builder branches on both attributes and real-time event properties, meaning you can branch a workflow immediately on the value of a property carried by the entry event itself. This is a meaningful difference for behavioral triggers in retention marketing that depend on event context, not just profile state.
Klaviyo's Liquid is constrained. Klaviyo uses Liquid but restricts some of the language's more expressive features. Customer.io's Liquid implementation is fuller — loops through event properties, nested conditionals, and complex date arithmetic are all available without custom code blocks. For teams trying to build personalized email flows without manual work, this flexibility matters.
Subscription and SaaS-specific Campaigns. Customer.io has native campaign structures for trial expiration reminders, payment failure sequences, churn prevention, and feature adoption nudges. These aren't add-ons — they're the primary use cases the platform was designed around. Klaviyo's equivalent flows are buildable but require more configuration to achieve the same behavioral precision.
The Architecture Difference: Klaviyo vs. Customer.io
Klaviyo's model: Profile-centric and ecommerce-native. Every contact has a profile with properties. Events are primarily ecommerce events pulled from Shopify or other integrations. Flows trigger on these events. Segments filter on profile properties and event history. Revenue attribution is tightly integrated with the ecommerce platform.
Customer.io's model: Event-driven and product-native. Every person has Attributes (profile properties) and receives Events (behavioral actions with properties from any source). Campaigns trigger on Events. Segments filter on Attributes and event history with full Liquid logic available for personalization. There is no native ecommerce integration bias — the platform treats a purchase_completed event from Stripe the same way it treats a feature_adopted event from your app.
The migration consequence: Klaviyo profile properties map to Customer.io Attributes. Klaviyo custom events map to Customer.io Events — with the key difference that in Customer.io, you design the full event schema including property depth from the start, rather than relying on ecommerce platform webhooks to define it for you. Klaviyo Flows must be rebuilt as Customer.io Campaigns. There is no import path.
What Transfers and What Doesn't
Transfers With Mapping ✅
Contact identity data. Email, phone, first name, last name, and custom identifier fields transfer via CSV import or the Customer.io API. Map your primary identifier to Customer.io's id field for consistent user identity.
Custom profile properties → Attributes. Every Klaviyo custom property in active use across flows and segments maps to a Customer.io Attribute. Document every property before migrating — and use this as an opportunity to clean up properties that are no longer referenced anywhere active.
Suppression data. Email unsubscribes and hard bounces move first, before any active contacts. Customer.io's global unsubscribe maps directly from Klaviyo's unsubscribed state. SMS opt-outs map to Customer.io's SMS topic suppression.
Must Be Rebuilt 🔄
Every Flow becomes a Campaign or Journey. There is no import. Rebuild in priority order: onboarding and trial → conversion and purchase recovery → retention and loyalty → re-engagement. Each rebuild is an opportunity to apply the event-property branching that Klaviyo's architecture constrained.
Segments. Klaviyo segments use Klaviyo's filter conditions. Customer.io segments use Attribute and event-based conditions in its own filter syntax. Every segment must be recreated. This is a natural time to apply the advantages of customer segmentation in lifecycle marketing and prune segment logic that has accumulated over time without a clear owner.
Templates. Klaviyo uses a variant of Liquid. Customer.io uses Liquid with a different variable convention. {{ person|lookup:'first_name' }} in Klaviyo becomes {{ customer.first_name }} in Customer.io. Every personalization tag must be remapped. The language structure is familiar; the variable references are different.
Left Behind ❎
Klaviyo's ecommerce revenue attribution. Customer.io's attribution model is campaign-level conversion tracking, not the revenue-attributed dashboard Klaviyo builds from its Shopify integration. For teams where email-attributed revenue is a primary reporting metric, set up your attribution framework in Customer.io's conversion goals before any Campaign goes live.
Klaviyo's predictive analytics. CLV predictions, churn risk scores, and next-order date predictions are Klaviyo-specific. Customer.io has a Predictive Audience feature but it operates differently. The behavioral segmentation you build in Customer.io — using actual event history rather than predicted scores — tends to be more precise for subscription and SaaS use cases once your event schema is mature.
Historical performance data. Klaviyo campaign metrics stay in Klaviyo. Export your performance benchmarks before closing the account. Customer.io engagement history starts fresh on migration day.
The Migration, Step by Step
Event Schema Design: The Work That Determines Everything Else
The most critical difference between a Klaviyo-to-Customer.io migration and a Klaviyo-to-Klaviyo-competitor migration is the event schema design phase.
In Klaviyo, your event schema was largely defined for you — Shopify events come pre-named and pre-propertied. In Customer.io, you define every event name, every property, and every data type from scratch. This is not a burden — it is the power of the platform. But it requires deliberate design work before implementation begins.
Document your complete event taxonomy: every action in your product or service that should trigger a message, with the properties that action carries. A subscription_upgraded event should carry from_plan, to_plan, new_mrr, and upgraded_at at minimum. A feature_first_used event should carry feature_name, days_since_signup, and plan_type. These properties are what enable Customer.io's Campaigns to branch, personalize, and sequence with precision. Our events and attributes architecture service runs this schema design as a formal pre-migration deliverable.
Suppression Import: Before Anything Else Moves
Export Klaviyo's unsubscribed contacts and hard bounces. Import to Customer.io before any active contact data. This is not optional. If active contacts import before suppression data and a Campaign fires in the window between the two imports, previously unsubscribed users receive messages. That is a compliance failure and a deliverability risk simultaneously.
People Import and Attribute Mapping
Export active Klaviyo profiles with all custom properties. Map each property to its Customer.io Attribute equivalent, paying attention to data types — Customer.io distinguishes between strings, numbers, booleans, and timestamps, and segment conditions depend on types being correct.
Segment your import by engagement tier before uploading: 30-day engaged, 60-day engaged, 90-day, lapsed. This segmentation drives your deliverability warm-up sequence and gives your first Customer.io Campaigns a clean audience to start with.
Campaign Rebuild
Campaigns in Customer.io are built around two core trigger types: event-triggered (a person fires a specific event and enters the Campaign immediately) and segment-triggered (a person meets segment conditions and enters). Most lifecycle Campaigns — onboarding, trial conversion, retention — are event-triggered. Most re-engagement Campaigns are segment-triggered, firing when a person hasn't performed a key event in a defined window.
The rebuild for Klaviyo teams is often genuinely liberating. Flows that were constrained by Klaviyo's ecommerce-centric filter options — flows that branched on "placed order" vs. "hasn't placed order" because that was the cleanest available trigger — can now branch on the specific product event that actually signals intent. A feature_deeply_used event is a more precise retention signal than "has placed 2+ orders." Customer.io makes this precision available without workarounds.
Deliverability Warm-Up
The sending domain in Customer.io starts with zero reputation. The warm-up is the same as any platform migration: engaged segment first, expanding weekly over 4–6 weeks. Monitor bounce and complaint rates daily. Our email deliverability channel health service manages this actively for every migration.
Stakeholder Expectations
Lifecycle team: 8–12 weeks for a typical Klaviyo migration. The event schema design and Campaign rebuild are the primary time investments. Campaign output will reduce during warm-up — build this into your roadmap.
Engineering: 2–4 weeks of technical resources for event instrumentation and API validation. The event schema design phase should include an engineer from day one — it is not a document that lifecycle teams can finalize without technical input. This is especially important for teams with complex subscription retention logic that touches multiple product systems.
Leadership: Use the customer retention impact calculator to establish a pre-migration revenue baseline. The 90-day mark post-migration is the right evaluation point — not week two during warm-up.
Propel's Role in Your Migration
Propel is a certified Customer.io partner with direct experience running Klaviyo-to-Customer.io migrations for subscription and SaaS brands. Our practice covers event schema design, suppression and data migration, Campaign rebuild, deliverability warm-up management, and the lifecycle strategy review embedded in every Campaign rebuild.
We have run this customer.io migration engagement across multiple platforms and verticals. We bring the technical depth to get the data foundation right and the lifecycle strategy experience to make the Campaign rebuild count.
Talk to a Propel operator about your Klaviyo to Customer.io migration.
Frequently Asked Questions
Does Customer.io have a native Shopify integration like Klaviyo?
Customer.io has a Shopify integration, but it is not the core of the platform's architecture the way it is in Klaviyo. For teams whose lifecycle program still has significant ecommerce event dependencies, the Shopify integration covers the basics — purchase events, cart abandonment triggers, customer data sync. But the depth of Klaviyo's native Shopify integration is not replicated in Customer.io.
Will my Klaviyo flow revenue attribution carry over?
No. Revenue attribution data and historical campaign performance stay in Klaviyo. Customer.io's conversion tracking starts fresh. Set up Campaign-level conversion goals in Customer.io before your first Campaign goes live.
How does Klaviyo's Liquid compare to Customer.io's?
Both use Liquid, but Customer.io's implementation is more complete. Some Liquid features that Klaviyo restricts — certain filter types, nested loops — are available in Customer.io. The variable referencing convention also differs. Every Klaviyo Liquid tag must be remapped to Customer.io's convention.
Can I use Customer.io for ecommerce as well as SaaS?
Yes. Customer.io works for ecommerce, particularly for brands that want more behavioral event depth than Klaviyo's ecommerce-native model allows. The difference is setup complexity — Customer.io requires more deliberate event schema design than Klaviyo's plug-and-play Shopify integration. The payoff is lifecycle logic that is significantly more precise.
What's the biggest risk in a Klaviyo to Customer.io migration?
Starting Campaign builds before the event schema is validated. Everything in Customer.io — campaign triggers, segment conditions, Liquid personalization — references specific event names and property keys. If those change after Campaigns are live, every affected Campaign must be rebuilt.
