Leaving Klaviyo: what actually moves, what has to be rebuilt, and what you lose

Every migration post you will read is written by the company you are migrating to, and every one of them says the same thing: it is easy, it is one click, we handle everything. We are the company you might be migrating to, so treat this accordingly — but we would rather lose a deal than have you discover in week three that your abandoned cart flow never came across and nobody noticed for eleven days.

So: this is what Klaviyo's API actually hands over, what it hands over in a shape that needs work, and what does not exist on the other side at all.

You need one read-only key, and only for an afternoon

A migration is a read. Create a private API key scoped to read in Klaviyo, hand it over, and delete it when the import reports finished. Nothing writes back to Klaviyo, nothing keeps polling it afterwards, and no ongoing connection is left behind. If a tool asks you for write scopes to import your data, ask why.

One thing worth being precise about: this is a migration, not a sync. The moment the import finishes, the two systems start drifting apart. Whoever unsubscribes in Klaviyo tomorrow is still subscribed in the new system unless you stop sending from Klaviyo on the same day. Plan the cutover as a date, not a period.

The inventory, endpoint by endpoint

Here is the whole picture in one table, and then the four rows that deserve a longer answer.

Consent: mirror it, never manufacture it

This is the row that turns a migration into a legal question, so it gets the most words.

Klaviyo exposes each profile's subscription state per channel and the timestamp of the opt-in. That is enough to mirror. What it does not reliably expose — especially for profiles that were themselves imported into Klaviyo years ago — is the original consent source and IP address. If your new tool cannot produce those, it should store what it has and record the gap, not invent a plausible-looking source.

Three rules that are worth writing into the project, because they are the ones people skip under deadline:

• Existing in Klaviyo is not consent. Only an explicit, active opt-in state makes a profile eligible to send to. Everything else comes across as a record, not as a recipient.
• The source is the migration. Consent imported from Klaviyo should be stamped klaviyo_import with Klaviyo's timestamp — not rewritten to look as though your new tool collected it.
• Ambiguous means excluded. A profile with a missing or unreadable opt-in timestamp keeps its order history and its spend, and stays out of marketing sends until somebody re-confirms it. That will cost you a few thousand addresses. It is the cheapest insurance you will ever buy.

Segments come across as definitions, and some of them do not translate

Klaviyo returns a segment's condition tree, not just its current membership, which is the good news: a segment is a rule you can re-evaluate rather than a frozen list of people.

Conditions that map cleanly are the ones built from data both systems actually hold — bought from a category, order value over an amount, last order older than N days, consent on a channel, opened or clicked in a window. Conditions that do not map are the ones built on constructs that only exist inside Klaviyo: predictive analytics scores such as expected date of next order or predicted lifetime value, and custom metrics arriving from integrations you are not bringing with you.

Those should arrive named and described, flagged for a human to rebuild — not silently dropped, and definitely not silently approximated with something that looks close. A segment that quietly means something different from what its name says is worse than a segment that is missing.

Flows are the one thing that is not a copy

Everything above is data transfer. Flows are behaviour, and a flow graph does not translate mechanically between two engines that make different assumptions about timing, branching and what counts as an event.

What a good import does with them:

• Brings every flow across as an inert draft — the trigger and the sequence of actions, visible and read-only, never auto-activated.
• Offers an assisted rebuild where an action has a direct equivalent: send an email, wait N days, add to a list, split on a property both systems hold. Pre-filled, then reviewed and confirmed step by step.
• Shows the steps that have no equivalent plainly, named, so you know which piece of your automation has no home yet before you decide the migration is finished.

Budget real hours for this. On a typical shop it is four to eight flows, and the two that matter — the abandoned cart and the post-purchase sequence — are usually also the two with the most conditions in them.

Your sending reputation does not come with you

This one is not an API question and it surprises people anyway. Domain and IP reputation, inbox placement history, the goodwill built up over three years of clean sending — all of that lives with the infrastructure that did the sending, not with your list. Moving means a new sending identity and a warm-up from zero, regardless of how good your Klaviyo numbers were.

In practice that is roughly two weeks of ramping volume before you send a full campaign, and it has a scheduling consequence most migration plans miss: do not move in the fortnight before your biggest sending week of the year. Nobody wants to discover the ramp during Black Friday.

A cutover order that does not go wrong

1. Scan first. Count profiles, lists, segments, flows and events before importing anything. If the event count is in the millions, decide then whether you want all of history or the last eighteen months.
2. Import, resumably. A large event history is rate-limited on Klaviyo's side and takes hours. It must survive a restart without starting again from page one.
3. Reconcile the counts. Subscribed profiles here should equal subscribed profiles there. If they do not, find out why before you send anything.
4. Authenticate the new sending domain — SPF, DKIM, DMARC — and start the warm-up while you are still sending from Klaviyo.
5. Rebuild the flows and run each one against a test profile through its whole branch, including the branch that should not fire.
6. Move one campaign. One real newsletter from the new system, to a segment you can eyeball, before anything automated is switched on.
7. Switch the flows over on one day, off in the old system and on in the new one in the same sitting — never both, or a customer gets the cart reminder twice.
8. Keep Klaviyo readable for a month, then close it. Do not delete an account you may need to check a consent record against.

What we deliberately do not offer

Running alongside Klaviyo — dual-sending, keeping the old system as the source of truth while you trial the new one — is not something we support, and we would rather say so than let you assume it. Two systems both convinced they own consent is exactly how someone gets messaged after unsubscribing. If you want to trial before committing, trial on one segment and one campaign, not on a second live copy of your list.

The parts we have not verified yet

Two things in here are stated from the API's documented shape rather than from a migration we have already run at scale, and it would be dishonest to present them with the same confidence as the rest:

• Whether the original consent IP is exposed per profile for every account age and acquisition path. Our assumption is that it often is not, which is why the rule above is to record the gap rather than fill it.
• Exactly which flow action types are worth building an assisted rebuild for on day one, versus which should simply be shown as unsupported. That list will be written from real migrations, not from a guess.

When those are settled, this post gets updated rather than quietly left as it is.