How to migrate from Mailchimp to Klaviyo without losing data in 2027?

Two migration paths: native CSV import versus API-driven backfill

Every Mailchimp-to-Klaviyo project resolves into one of two paths, and picking the wrong one is where most teams lose data.

Path A — native CSV import. You export your Mailchimp audience to CSV, upload it into a Klaviyo list, map columns to Klaviyo profile properties, and separately upload your suppression file. Klaviyo's import UI handles field mapping interactively, deduplicates by email address, and shows you a preview before committing. It moves *who* is on your list and *what you know about them* — email, name, phone, custom merge fields, tags, location, and subscription consent state.

What Path A cannot move: per-message engagement history. A CSV row has no place to say "this person opened campaign #4821 on March 12 and clicked the second link." Klaviyo's profile-level metrics (Opened Email, Clicked Email) are built from *events*, and events land through the Events API, not a profile import. If you take Path A and nothing else, you arrive in Klaviyo with a clean list and a completely blank engagement timeline. Every flow that says "has opened email at least once in the last 90 days" starts at zero, and your first "engaged subscribers" segment is empty on day one.

Path B — API-driven backfill. You keep the profile import (you still need it) but you add a second pass that pulls raw activity out of Mailchimp's Reports endpoints and writes it into Klaviyo as timestamped custom events. Mailchimp's Marketing API exposes per-campaign open and click detail (/reports/{campaign_id}/open-details and /click-details), plus a per-member activity endpoint that returns a contact's recent interactions. You transform those into Klaviyo event payloads with an explicit time field so they land on the historical date rather than today, then push them through Klaviyo's events endpoint.

Path B costs engineering time and calendar days. It also risks a subtler failure: if you post events without the timestamp override, you compress two years of history into a single afternoon, and every recency-based segment in Klaviyo becomes garbage in a way that looks fine until someone asks why 100% of the list is "engaged in the last 7 days."

The hybrid that most teams actually run. Profiles and suppressions via native import (fast, low-risk, done in an afternoon). Engagement history via a bounded backfill — not all history, just the last 90 to 180 days of opens and clicks, which is the window your segments and flows actually reference. Purchase and order history not from Mailchimp at all, but re-synced from the source of truth: connect Klaviyo's Shopify, BigCommerce, or WooCommerce integration and let it backfill orders directly from the store. Mailchimp's e-commerce data is a copy; the store is the original, and pulling from the original avoids reconciling two lossy copies.

The trade-off in one line: Path A gets you sending in a week with no history; Path B preserves segmentation logic but adds two to four weeks and real engineering. The hybrid buys ~80% of Path B's value for ~30% of its cost, which is why it's the default recommendation for any RevOps team that isn't running a nine-figure email program.

How to decide which path fits your account

The decision hinges on four things: list size, how much your segmentation depends on historical engagement, whether you have e-commerce order data, and whether anyone on your side can write and babysit an API script.

Ask them in this order:

1. Does any live flow or segment condition reference past opens/clicks? If yes, you need backfill, full stop. Sunsetting flows, re-engagement campaigns, and "engaged 30/60/90" segments all break silently without it. If your segmentation is purely demographic or purchase-based, skip the backfill entirely and save yourself weeks.
2. Is your list over roughly 50,000 profiles? Above that, CSV import gets unwieldy — you'll be splitting files, and a single malformed row can fail a chunk. The profile bulk-import endpoint is the saner tool at that scale.
3. Do you have a store platform Klaviyo natively integrates with? If yes, do not migrate order data through Mailchimp. Connect the store and let the integration backfill.
4. Do you have an engineer for 20-40 hours? If not, the honest answer is Path A plus a manual suppression upload, and you accept the blank history. That's a legitimate choice — just make it deliberately rather than discovering it after cutover.

One rule that overrides the tree: never let the decision be "we'll figure out history later." Backfilling engagement events six months after cutover means reconciling against a Mailchimp account you may have already downgraded or cancelled, and Mailchimp's report retention is not indefinite. If you're going to backfill, export the raw report data *before* you stop paying — even if you don't process it for another quarter. Dump the JSON to cold storage and you've bought yourself unlimited time.

The concrete numbers behind each path

Path A, native CSV import. Realistic timeline for a 25,000-profile single-audience account: half a day to export and clean, half a day to map and import, one day to rebuild the two or three flows you actually use, one day of test sends. Call it three to four working days of one person's time. Cost is zero beyond the Klaviyo subscription. The Mailchimp export itself is asynchronous — you request it from the Audience screen and Mailchimp emails you a link when the archive is ready; on large audiences that's minutes, not seconds, so don't schedule the import call for five minutes after the export.

Path B, API backfill. Budget by campaign count, not contact count, because you page through report detail per campaign. If you've sent 400 campaigns and want the last 180 days — say 60 campaigns — you're making a paged request per campaign for opens and another for clicks. Mailchimp's Marketing API paginates with count and offset; count maxes out at 1000 records per request, so a campaign with 40,000 opens is 40 requests. Sixty campaigns at that scale is a few thousand requests, which is a script that runs for a while, not a script that runs for days.

The real constraint people get wrong: Mailchimp's Marketing API limits you to 10 simultaneous connections per account — it is a concurrency cap, not a requests-per-second cap. That means a sequential script never hits it, and a naively parallelized one with 50 workers gets rejected. Keep your worker pool at or below a handful, add exponential backoff on 429s, and checkpoint your progress by campaign ID so a failure at campaign 47 doesn't restart you at campaign 1.

On the Klaviyo side, events go in through the bulk event-creation path rather than one call per event; batching is the difference between a job that finishes overnight and one that doesn't. Klaviyo publishes its own rate limits per endpoint with burst and steady-state tiers — read the current numbers in their developer docs rather than trusting a figure from a blog post, because they've changed as the API has versioned.

Engineering estimate for the backfill: 8-12 hours to write and test the Mailchimp extractor, 6-10 hours for the transform and Klaviyo loader, 4-8 hours of validation and re-runs. Roughly 20-30 hours for a competent engineer who has used both APIs. Double it if they haven't.

Thresholds worth writing down as go/no-go gates:

• Profile count delta between platforms after import: under 2% is expected (Mailchimp permits the same address across multiple audiences; Klaviyo has one profile per email, so genuine duplicates collapse). Over 5% means something failed — do not proceed.
• Hard bounce rate on your first real send: under 2%. Above that, your suppression upload didn't take.
• Spam complaint rate on the test send: under 0.1%. This is the industry-standard threshold major mailbox providers publish for their postmaster tools, and crossing it is how you cook a warm domain.
• Order/revenue total for the trailing 90 days, compared between Mailchimp's e-commerce reporting and Klaviyo after integration backfill: variance over 5% means orders are missing.

What you should expect to permanently lose, and plan around rather than fight: campaign-level aggregate reports (Mailchimp's per-campaign open rate, CTR, and revenue dashboards do not transfer — export them to a spreadsheet or warehouse as a historical archive and accept that your Klaviyo reporting baseline starts at migration date); automation *structure* (you rebuild flows, you don't import them); and Mandrill transactional templates, which live in a separate product entirely and need rebuilding against Klaviyo's transactional path if you use them.

Preserving list hygiene, which is where the real damage happens

If you lose engagement history you lose segmentation quality. If you lose suppression data you lose your sending reputation, and that's the expensive one.

Mailchimp tracks several distinct non-mailable states and they do not all come out of the same export. Unsubscribed contacts, cleaned contacts (Mailchimp's term for addresses removed after hard bounces or repeated soft bounces), and complaint-flagged addresses each need to be captured. The audience CSV export includes contact status, so unsubscribed and cleaned members are visible there if you export *all* contacts rather than just subscribed ones — the single most common migration mistake is exporting only subscribed contacts, importing them into Klaviyo, and thereby throwing away the entire do-not-mail list.

Do this specifically:

1. Export all contacts, every status, from every audience. Not just "subscribed."
2. Split the file by status. Subscribed contacts become your Klaviyo list import with consent preserved. Unsubscribed, cleaned, and complaint contacts become a separate suppression file.
3. Upload the suppression file through Klaviyo's suppression path — a profile import does not suppress anyone. Importing an unsubscribed address as a regular profile with a mailchimp_status: unsubscribed property makes it *visible* but still *mailable*, and the first campaign that targets "everyone" will hit it. The property is useful documentation; it is not a suppression mechanism. This distinction has burned enough teams that it deserves its own line in your runbook.
4. Keep the raw bounce report too. Knowing an address hard-bounced on a specific date is useful context when someone re-subscribes through a form later.
5. Verify after upload: pull Klaviyo's suppression count and compare it to the number of rows in your unsubscribed-plus-cleaned file. They should match within a handful of records. A large gap means part of the file was rejected — usually malformed emails, which you should review rather than ignore.

On consent and compliance: carry over the original consent metadata where Mailchimp captured it — signup timestamp, signup IP, and signup source are all available in the audience export and all matter if a regulator or a mailbox provider ever asks how you acquired an address. Import them as profile properties even though Klaviyo doesn't require them. GDPR-scoped lists in particular should keep opt-in date and source; a list of addresses with no provenance is a liability.

A related trap: double opt-in behavior differs between platforms. If your Mailchimp signup forms used double opt-in and you rebuild forms in Klaviyo without it, or vice versa, your list-growth reporting shifts and so does the quality of incoming addresses. Decide deliberately rather than inheriting whatever the new form defaults to.

Rebuilding automations, and why manual is the right answer

Klaviyo does not import Mailchimp automations, and no third-party connector meaningfully changes that. The trigger models are different: Mailchimp's Customer Journeys and Klaviyo's Flows express similar ideas with different primitives, different split logic, and different metric names. A translation layer would produce something you'd have to audit line by line anyway.

Treat the rebuild as an opportunity to cut. Most accounts have accumulated automations nobody has looked at in two years. Before rebuilding anything, pull each automation's send volume and revenue for the trailing 12 months from Mailchimp's reporting and sort descending. In practice a small handful of flows — welcome, abandoned checkout, post-purchase, win-back — carry nearly all the value. Rebuild those carefully; archive the rest and rebuild on demand if someone actually misses them.

Sequencing that avoids double-sends and gaps:

Run both platforms in parallel for a bounded window, but never with both sets of automations live. The failure mode is a contact who triggers a welcome series in Mailchimp *and* in Klaviyo and gets two of everything, which reads as broken to the recipient and generates complaints.

Flow-by-flow testing details that matter. Create three or four seed profiles with addresses you control and walk each through its trigger. For abandoned checkout, actually abandon a checkout in a test order. For the welcome series, submit the real form. Check not just that the email sends but that conditional splits evaluate correctly — a split on "has opened email in the last 30 days" behaves very differently on a freshly migrated profile with no history than it did on a mature Mailchimp profile, and that's exactly the class of bug the backfill exists to prevent. If you skipped the backfill, rewrite those conditions rather than leaving them to silently route everyone down the "not engaged" branch.

Sending reputation during cutover. You are changing sending infrastructure. Even with a well-authenticated domain, ramp rather than switching a million-address list over in one send. Start at roughly 5% of list volume, watch bounce and complaint rates for 24 hours, then step up over five to seven days. Confirm SPF, DKIM, and DMARC alignment for your sending domain in Klaviyo before the first send — not after — and if you use a dedicated sending domain in Mailchimp, expect to configure the equivalent DNS records fresh.

Keep Mailchimp read-only for 30 days minimum. Not active — you don't want accidental sends — but accessible. Every migration surfaces a question in week three that only the old account can answer: what was this segment's definition, what did that template look like, when did this contact actually subscribe. Downgrading to a free or lowest paid tier for a month is cheap insurance compared to discovering you cancelled the only copy of something.

Post-migration monitoring for silent data loss

Data loss rarely announces itself at cutover. It shows up two weeks later as a flow that stopped firing or a segment that quietly shrank to nothing.

Watch four signals for the first 30 days:

List size drift. A drop of more than roughly 3% in 48 hours points at suppression logic doing something you didn't intend — often a bulk unsubscribe triggered by importing profiles into a list that had a webhook or an integration attached. Check what's writing to your list besides you.

Hard bounce rate. Anything sustained above 1-2% after the first couple of sends means stale addresses got through, which almost always traces back to an incomplete suppression upload. Compare your Klaviyo suppression count against your original Mailchimp unsubscribed-plus-cleaned count again; it's worth re-checking because partial file rejections are easy to miss the first time.

Open rate versus pre-migration baseline. You archived Mailchimp's campaign reports, so you have the baseline. A drop of more than about 10% on comparable content to a comparable segment suggests either a deliverability problem (authentication, ramp too fast) or a targeting problem (your "engaged" segment is now selecting the wrong people because history is missing). Those have different fixes, so diagnose before reacting — check inbox placement with seed testing before you start rewriting segment logic.

Flow entry counts. For each rebuilt flow, compare weekly entries against the equivalent Mailchimp automation's historical weekly volume. A flow with dramatically fewer entries has a broken trigger; one with dramatically more may be double-triggering. Both are findable in a five-minute check that nobody runs unless it's on a checklist, so put it on the checklist.

Build a "migration validation" segment in Klaviyo that selects profiles where an expected imported property is missing — for example, profiles with no mailchimp_signup_date when every imported profile should have one. If that segment has members, part of your import didn't map. It's a cheap standing alarm for the class of failure where one CSV chunk out of eight silently failed.

Finally, write the runbook down as you go, including the field mapping table. The next person to touch this — possibly you in eighteen months, wondering what mc_rating on 40,000 profiles means — will need it, and reconstructing a mapping after the source system is gone is not possible.

Related questions

Does Klaviyo import Mailchimp's open and click history automatically?

No. Klaviyo's profile import moves contacts and their properties, not per-message engagement. Historical opens and clicks have to be pulled from Mailchimp's report endpoints and written to Klaviyo as timestamped events, or they're simply absent.

Can I keep sending from Mailchimp during the migration?

Yes, and you should for campaigns. Just never run both platforms' automations simultaneously — that's how contacts get duplicate welcome series. Pause all Mailchimp automations in the same window you activate Klaviyo flows.

What happens to contacts that exist in several Mailchimp audiences?

Klaviyo keeps one profile per email address, so those collapse into a single profile. Expect a 1-2% total count reduction. Decide beforehand which audience's property values win when they conflict, or you'll get whichever file imported last.

Do I need to warm up my sending domain again in Klaviyo?

Ramp, don't cold-start. Configure SPF, DKIM, and DMARC before the first send, begin around 5% of list volume, watch bounce and complaint rates, and step up over five to seven days rather than switching full volume at once.

Should I migrate Mailchimp's e-commerce data or re-sync from my store?

Re-sync from the store. Klaviyo's native store integrations backfill order history from the source of truth, which avoids reconciling Mailchimp's copy against the original and typically produces more complete data.

FAQ

How long does a Mailchimp to Klaviyo migration actually take?

A profile-and-suppression-only migration on a mid-sized list is three to four working days of one person's time. Add two to four weeks if you're backfilling engagement events and rebuilding a meaningful set of flows. The calendar time is dominated by flow testing and the sending ramp, not by the data movement itself.

Will I lose my Mailchimp campaign reports?

Campaign-level aggregate metrics don't transfer. Export them from Mailchimp's reporting to CSV or push them to a warehouse before you cancel, and treat them as a historical archive. Your Klaviyo reporting baseline starts at migration date — plan any year-over-year comparison around that discontinuity.

Is there a tool that migrates Mailchimp automations to Klaviyo flows?

Nothing that produces output you can trust without a full audit, because the trigger and split primitives differ between the two platforms. Rebuild the handful of flows that carry your revenue, reuse the HTML from exported templates, and archive the rest.

What's the single most common cause of data loss in this migration?

Exporting only subscribed contacts. That discards every unsubscribe and every cleaned address, so the do-not-mail list vanishes and the first broad send hits addresses that already bounced or opted out. Export all contacts, every status, and upload the non-mailable ones through Klaviyo's suppression path — not as ordinary profiles.

Why did my engagement segments come out empty after import?

Because engagement segments read events, and a profile import creates no events. Either backfill 90-180 days of opens and clicks with explicit historical timestamps, or rewrite those segment conditions to use something you do have — purchase recency, signup date, or property values.

Can I migrate Mailchimp transactional emails?

Mailchimp's transactional product (Mandrill) is separate from the marketing platform and its templates and logs don't come along with an audience export. If you rely on it, plan a separate workstream to rebuild those messages against Klaviyo's transactional sending, and don't discover the dependency during cutover week.

Sources

• Klaviyo Developer Documentation
• Klaviyo Help Center
• Mailchimp Marketing API Reference
• Mailchimp: Export Your Audience Data
• Mailchimp: About Cleaned Contacts
• Google Postmaster Tools Help
• M3AAWG Sender Best Common Practices
• Gartner: B2B Buying Journey

Related on PULSE

• What are the key differences between Mailchimp and ActiveCampaign for email automation workflows?
• How to migrate all my contacts and deals from Pipedrive to Salesforce without losing data?
• How do you migrate CRM platforms without losing data in 2027?
• How Do I Migrate CRMs Without Breaking the Forecast in 2027?
• How do you migrate off Salesforce after the 2027 price increase?
• How do you migrate from seat-based to value-based pricing in 2027?