Mailchimp Klaviyo: What Transfers and What Resets

What a Mailchimp Klaviyo Migration Actually Moves

A Mailchimp Klaviyo migration moves the data that has a clean, structural home in both platforms: contact records, list or audience membership, custom properties you’ve already mapped, and past campaign sends as a historical record. Email addresses, phone numbers, names and any custom field you’ve built on both sides transfer through Klaviyo’s native Mailchimp integration or a CSV export and import, and this part is the easiest to get right because it’s just data moving between two column structures that look similar.

What moves cleanly is smaller than most teams expect walking in. A migrated contact record isn’t the same thing as a relationship with that contact — Klaviyo can import who someone is, but it can’t import what Mailchimp learned about how that person behaves, because that behavioural record lives in Mailchimp’s own engagement scoring and doesn’t export as a field. The practical effect is that Klaviyo starts every migrated contact as a blank slate on engagement, even for a subscriber who’s opened every campaign for two years.

This guide assumes a $3M–$30M Shopify Plus or equivalent subscription-platform brand with existing Mailchimp automations worth preserving — see /for/scaling-brands for the fuller profile. If you’re running a single monthly campaign with no journeys built, the migration is mostly a CSV export, and most of the three failure modes in this guide won’t apply, because there’s little automation logic to lose in the first place.

What Doesn’t Transfer From Mailchimp to Klaviyo

Three categories consistently don’t move, and all three matter more than the contact list itself. Engagement history — opens, clicks, and the engagement score Mailchimp builds from them — doesn’t transfer, because Klaviyo calculates its own engagement metrics from data it collects after the contact lands in Klaviyo, not from an imported summary. Automation logic — Mailchimp’s Customer Journeys, their branching conditions, and any custom trigger built on Mailchimp-specific events — doesn’t transfer either, because Klaviyo’s flow builder uses its own trigger and filter structure, and there’s no direct one-to-one mapping between the two platforms’ automation models. Suppression and unsubscribe records are the third gap worth naming separately from consent: Mailchimp’s unsubscribe list generally needs to be exported and re-applied manually in Klaviyo, because failing to carry over who opted out is the fastest way to re-email someone who told you to stop.

These gaps aren’t Klaviyo doing anything wrong. They’re two platforms that built engagement scoring and automation logic on architectures that were never designed to talk to each other, so anything downstream of the raw contact record has to be rebuilt rather than moved.

Why Engagement History Doesn’t Carry Over

Engagement history is a live calculation, not a static field, which is the core reason it can’t be exported and re-imported the way a name or email address can. Klaviyo builds its own engagement profile for every contact from the moment that contact starts receiving Klaviyo sends — opens, clicks, and how recently they did either — and that calculation only exists inside Klaviyo’s own send history. Mailchimp’s equivalent score is built the same way, on Mailchimp’s own send history, and the two numbers were never designed to be portable between vendors.

The gap in engagement history matters operationally in two ways. Klaviyo’s own suggested segments and predictive features, such as win-back timing or churn risk, need real send history inside Klaviyo to work well, so a freshly migrated account with no send history will produce advice that’s closer to a generic default than to something specific to your list. Second, and more practically, a segment you built in Mailchimp around “engaged in the last 90 days” cannot be recreated in Klaviyo on day one, because Klaviyo has no record of what happened in the 90 days before the contact arrived. You have to either accept a wider segment until real history accumulates, or import engagement as a custom property, a one-time snapshot rather than a live score, as an interim substitute.

Why Automation Logic Doesn’t Map One to One

Mailchimp’s Customer Journeys and Klaviyo’s flows solve the same problem — send the right message when a contact does something — but they’re built on different trigger vocabularies, and a journey that looks simple in Mailchimp can hide branching logic that has no direct Klaviyo equivalent. A Mailchimp journey trigger based on a custom event built through their API, for instance, doesn’t automatically exist as a Klaviyo metric; Klaviyo needs that event sent to it directly, through its own API or an app integration, before a flow can trigger on it at all.

The practical migration task isn’t “move the automations.” It’s reading every existing journey’s logic, deciding what it’s actually trying to accomplish, and rebuilding that intent as a Klaviyo flow using Klaviyo’s own triggers, time delays and conditional splits. A welcome flow is usually the simplest to rebuild, because the trigger — a list or segment join — exists in both platforms in a near-identical form. A browse-abandonment or win-back journey is harder, because it typically depends on behavioural data such as site activity or purchase history that has to be flowing into Klaviyo correctly before the flow can trigger the way the old journey did, and that data pipeline is a separate piece of setup work from the flow itself, easy to assume is already working when it isn’t.

The Three Things That Break During a Mailchimp to Klaviyo Migration

Most migration problems fall into three recurring failures, and all three are avoidable if you know to check for them before cutover rather than after.

Break One: Deliverability Reputation Resets to Zero

A sending domain’s reputation is built with the mailbox providers that receive it — Gmail, Outlook, Yahoo — and that reputation is tied to the sending infrastructure, not to your brand or your contact list. Klaviyo sending from a new domain or subdomain starts with no history at any of those providers, regardless of how strong Mailchimp’s reputation was. Send at full volume on day one and inbox providers treat the sudden burst from an unfamiliar sender the way they’d treat any other unfamiliar sender: cautiously, sometimes routing a meaningful share to spam until the new domain proves itself.

Break Two: Segments Rebuild on Different Logic Than You Expect

A segment named identically in both platforms can return a different list of people, because the underlying logic — how “engaged,” “active,” or “high value” gets calculated — isn’t the same formula in both tools. Migrating a segment by name rather than by definition is how a “VIP customers” segment in Klaviyo ends up with a different headcount than the one it replaced, without anyone noticing until a campaign’s reach looks off.

Break Three: Automation Gaps Open Mid-Cutover

If old Mailchimp journeys get switched off before their Klaviyo equivalents are live and tested, contacts moving through the customer lifecycle during that window get no automated message at all — no welcome series, no abandonment follow-up — because neither system’s automation is covering them for those days. This gap is invisible in real time and only shows up later as a quiet dip in flow-attributed revenue for that cohort.

How to Avoid Resetting Your Deliverability Reputation

Deliverability during a platform switch is a warm-up problem, not a settings problem — the fix is sending behaviour over the first weeks, not a checkbox in Klaviyo’s account settings.

Step 1: Warm Up Klaviyo’s Sending Domain Before Full Cutover

Start sending from the new domain at a small fraction of your normal volume, days before you plan to rely on it for real campaigns, so mailbox providers see a sending pattern build up gradually rather than appearing all at once.

Step 2: Migrate Your Most Engaged Segment First

Send the new domain’s earliest volume to the contacts most likely to open and click — recently engaged subscribers rather than your full list. Mailbox providers weight early engagement heavily when deciding how to treat a new sender, so starting with your best audience gives the domain its strongest possible first impression.

Step 3: Match Your Pre-Migration Sending Volume and Cadence

Once warm-up is underway, scale toward your normal sending cadence gradually rather than jumping straight to full list volume the moment the new domain is technically capable of sending. A sudden jump in volume is one of the signals mailbox providers use to flag a sender as behaving unusually, independent of anything about the content itself.

Step 4: Watch Inbox Placement and Complaint Rate During Ramp-Up

Track complaint rate and, where you have visibility into it, inbox placement rather than just open rate during the ramp-up period. Open rate alone can look fine while a meaningful share of sends are landing in spam, because opens are only counted for mail the recipient actually saw.

How to Carry Over Consent Records Without Guessing

Every contact you import needs a defensible answer to “why is this person on our list,” and that answer has to move with the contact, not be assumed from the fact that they’re in the export file. Bring across the original consent source and date if Mailchimp has them recorded — sign-up form, list, and timestamp — as custom properties on the Klaviyo profile, so the record isn’t lost the moment the contact changes platforms.

Unsubscribes need separate, deliberate handling rather than an assumption that “if they’re not in the export, they’re fine.” Export Mailchimp’s suppression and unsubscribe list specifically, and check it against the import before the first Klaviyo send goes out; importing a full audience without cross-referencing suppressions is the single most common way a migration re-emails someone who opted out months earlier.

A brief note on where this connects to capture, since it’s a related but separate problem: however contacts are captured going forward, whether through an embedded sign-up form, a checkout opt-in, or an SMS keyword, the consent that form captured is a record you carry forward at migration, not one you get to reconstruct after the fact. What matters most for the migration itself is that Klaviyo’s own list-level opt-in setting, single or double, is deliberately chosen before the first post-migration send, not left on whatever it happened to default to.

What Happens to SMS Consent During a Mailchimp to Klaviyo Migration?

SMS consent needs the same deliberate handling as email consent, and it’s easy to overlook because most Mailchimp-to-Klaviyo migrations are planned around email first. If Mailchimp holds SMS-consented contacts, through Mailchimp’s own SMS feature or a connected tool, that consent record — who opted in, when, and through what mechanism — has to be exported and mapped into Klaviyo’s SMS consent fields explicitly; it doesn’t travel automatically as part of a standard contact import built for email fields.

Treat a contact with email consent but no clear SMS consent record as SMS-unconsented by default rather than assuming email opt-in covers both channels. It generally doesn’t, and the specific requirements for what counts as valid SMS consent, how it needs to be recorded, and what disclosures are required vary by jurisdiction, so this is worth confirming directly with counsel rather than inferring from how the export looks.

If the consent record itself is ambiguous or missing for a contact — an SMS number present in Mailchimp with no clear opt-in timestamp attached — the safer operational choice is to leave that contact out of the Klaviyo SMS list rather than import the number and assume consent existed. A gap in your SMS list from a cautious migration is a smaller problem than a compliance question raised by a number that shouldn’t have been there.

Should You Run Mailchimp and Klaviyo in Parallel During the Switch?

Running both platforms for a defined overlap period is the standard way to avoid the automation gap that opens when old journeys stop before new flows are ready, and most migrations benefit from it even though it means paying for two tools briefly. The overlap gives you a working safety net: Mailchimp keeps handling live automations while you build and test their Klaviyo equivalents against real traffic, rather than testing in isolation and cutting over based on assumptions.

The overlap period isn’t a fixed number of days. It depends on how many automations you’re rebuilding, how long your longest flow runs (a win-back sequence spanning several months takes longer to validate than a three-email welcome series), and how much testing volume you need to be confident a rebuilt flow behaves the way the original did. Automated flows account for 41% of email revenue across Klaviyo’s own merchant base (Klaviyo, 183,000+ brands, vendor-reported), which is roughly the scale of the rebuild worth protecting rather than rushing. Rather than picking an arbitrary date, tie the cutover to a checklist: every automation rebuilt, tested with real triggers, and compared against its Mailchimp equivalent’s basic shape before Mailchimp’s version is switched off. Before committing to a longer overlap, the flow revenue calculator is a reasonable way to estimate what a week of missing automation coverage would cost, which makes the extra cost of running two tools easier to justify.

How Do You Know When It’s Safe to Turn Off Mailchimp?

Safe to turn off means every automation that used to run in Mailchimp has a tested Klaviyo replacement live and confirmed to trigger correctly, every contact has been checked against the suppression list, and at least one full cycle of your most important flow, usually the welcome series since it runs constantly on new sign-ups, has completed successfully in Klaviyo. Turning off Mailchimp before that checklist is done is how the automation gap in Break Three actually happens in practice, not through a mistake so much as through optimism about how ready things are.

Keep the Mailchimp account active, even at its lowest tier, for a stretch after cutover rather than cancelling immediately. It stays useful as a reference for historical campaign data and as a fallback if something in the new Klaviyo setup needs comparing against what the old automation actually did. How long that stretch needs to be is a judgement call based on your own migration’s complexity, not a fixed industry number — the honest answer is long enough that you’ve stopped needing to check it, which is longer than most teams initially plan for.

Can You Still Access Mailchimp’s Historical Campaign Data After Switching?

Historical campaign data stays inside Mailchimp; it doesn’t get pulled into Klaviyo as part of a standard migration, because Klaviyo has no equivalent record of campaigns it never sent. Past subject lines, send dates, and Mailchimp’s own reported open and click rates for old campaigns remain visible in the Mailchimp account for as long as that account stays active, which is the main practical reason to keep a low-tier Mailchimp subscription running rather than cancelling the moment Klaviyo goes live.

What doesn’t carry over usefully is the ability to compare old and new campaign performance side by side inside one dashboard. Mailchimp’s historical numbers and Klaviyo’s ongoing numbers live in two separate systems, calculated with two separate methodologies, so a direct before-and-after comparison of open rate or click rate across the switch is comparing two different measurement approaches, not a clean before-and-after of the same metric. Anyone reporting on the impact of the migration itself should note this rather than present the two figures as directly comparable.

If you need Mailchimp’s historical data preserved beyond the account’s own retention, export campaign reports before you let the account lapse. A CSV or PDF export of key campaigns is a reasonable archive, since Mailchimp’s own interface may not stay accessible indefinitely on an inactive or downgraded account.

What to Rebuild First Once Klaviyo Is Live

Sequence the rebuild rather than trying to recreate everything from Mailchimp simultaneously. The welcome flow comes first, because it’s the highest-volume automation for most stores and the trigger, a list or segment join, is the most reliably mapped between platforms. Abandonment flows, both cart and browse, come next, because they depend on behavioural data feeds that are worth confirming are flowing correctly into Klaviyo before building the logic on top of them. Post-purchase and win-back sequences come last, partly because they’re lower urgency and partly because win-back specifically depends on Klaviyo’s own engagement history, which starts empty for every migrated contact — it works better once Klaviyo has accumulated enough of its own send history to judge who’s actually gone quiet, since Klaviyo starts that calculation from zero on every migrated contact.

Segmentation and list hygiene should be rebuilt in parallel with this, not treated as a one-time import task. A segment definition copied from Mailchimp without checking Klaviyo’s equivalent logic is one of the most common quiet failures in a fresh account, and it’s worth auditing every migrated segment’s headcount against its old Mailchimp equivalent in the first few weeks, rather than assuming a matching name means matching membership.

A Mailchimp Klaviyo migration is really a Lifecycle flows rebuild wearing a data-export task as its disguise: the contacts move in an afternoon, but the flows, segments and deliverability warm-up behind them are the actual project, which is exactly the work a Lifecycle flows engagement is built to carry through cutover rather than leaving half-rebuilt.