How to Migrate From Salesforce Marketing Cloud to Klaviyo Without Losing Personalization

Direct answer: Migrating from Salesforce Marketing Cloud to Klaviyo means rebuilding your data model, not just your automations, and Sticky Digital recommends starting with a full audit of every Data Extension and AMPscript block before touching a Journey Builder rebuild. SFMC's relational data structure lets marketers join multiple data extensions inside a single email using custom SQL and AMPscript. Klaviyo's model is profile and event based, which is simpler to run day to day but does not support that same relational join logic natively. Brands that migrate without accounting for this end up with broken personalization, mistimed sends, or both, in their first month on the new platform.

Sticky Digital's Perspective

SFMC migrations are a different animal from a Mailchimp or HubSpot switch, and it's worth saying plainly: this platform was not built for a typical DTC brand's scale or budget. When a brand does come to us running SFMC, it's usually because a previous team built something ambitious, a personalization engine wired together with Data Extensions, AMPscript, and Journey Builder canvases that took months to construct, and now nobody left on staff fully understands how it works.

That's the real risk in these migrations. It's not the contact export. It's the tribal knowledge sitting inside AMPscript blocks that were written by someone who left the company two years ago. We've opened SFMC accounts where the "personalized product recommendation" in a flagship email was actually a hardcoded SQL query joining three separate data extensions, and not a single person on the current team could explain what would happen if that query stopped returning results.

The pattern holds regardless of category. A brand's SFMC build is almost always more complex than its Klaviyo replacement needs to be, and that's not a criticism of the migration, it's a feature of moving to a platform that doesn't require a dedicated technical resource just to keep email running.

What Actually Breaks in an SFMC to Klaviyo Migration

Data Extensions are the first and biggest problem. SFMC stores data in relational tables that can be joined at send time: a customer record, a purchase history table, a loyalty points table, all queryable together inside a single AMPscript block. Klaviyo doesn't have an equivalent relational join. It has profile properties and event history attached directly to a single customer record. Any personalization built on joining multiple data extensions has to be redesigned as either a flattened profile property, synced in advance, or a Klaviyo custom event, which is a genuinely different way of thinking about the same data.

AMPscript itself is the second problem, and it's the one that catches teams off guard because it looks like it should be a simple find-and-replace into Klaviyo's Liquid templating language. It isn't. AMPscript can execute conditional SQL lookups inline inside an email. Liquid can reference profile and event properties that already exist on the record, but it can't run a live database query mid-render. Every AMPscript block that pulls data dynamically at send time needs its underlying logic rebuilt so that the data it needs already lives on the Klaviyo profile before the email fires, not fetched live the way SFMC allowed.

Journey Builder is the third. SFMC's journeys can branch across email, SMS, push notification, and even direct mail inside a single canvas, often with wait steps tied to external system events synced from Salesforce Sales Cloud or a data warehouse. Klaviyo flows are genuinely capable, but they're built around ecommerce triggers: order placed, product viewed, checkout started. A journey built around a custom Salesforce object update, like a support ticket closing or a loyalty tier changing in an external system, needs that event piped into Klaviyo as a custom event before the equivalent flow logic can exist at all.

The Relational Data Trap

Flattening Everything Into One List Feels Like Progress. It Isn't.

Faced with the complexity of rebuilding relational logic, the shortcut a lot of teams take is exporting every data extension as its own static Klaviyo list and calling the migration done. This gets contacts into Klaviyo. It does not get the relational intelligence into Klaviyo, and that intelligence was often the entire reason the SFMC build was worth the investment in the first place. A year later, the brand is running Klaviyo like a basic ESP and wondering why the platform everyone said was more powerful feels like a downgrade.

Rebuild the Joins as Klaviyo Custom Events

The better path is deciding, extension by extension, what the join was actually accomplishing, then rebuilding it using Klaviyo's native event and profile property model. A "recommended product from purchase history" join becomes a Klaviyo flow branch based on the customer's actual order events synced from your ecommerce platform. A "loyalty tier" join becomes a custom profile property updated whenever the loyalty system fires a webhook. It takes more upfront thinking than a straight export, and it's the difference between Klaviyo performing at its ceiling and Klaviyo performing like a smaller, less capable version of what you already had.

Deliverability at Enterprise Scale

SFMC accounts tend to sit on much larger lists than a typical Klaviyo migration, and that changes the warmup math. Rather than a fixed day count, think in sending tiers. Start with your highest-engagement tier, the segment that's opened or clicked in the last 30 days, and hold there until Klaviyo's own deliverability signals confirm a healthy sending reputation before expanding to your next tier. For a list in the hundreds of thousands, that graduated approach across three or four tiers often takes closer to three weeks than the shorter timelines that work for a smaller list. Rushing a large SFMC list into full volume on day one is one of the fastest ways to land in a spam folder you'll spend months digging out of.

If the SFMC build includes SMS or push notifications through a connected channel, those need their own consent audit before migrating. SFMC accounts, especially ones synced with Salesforce Sales Cloud, sometimes carry contact records with communication preferences that were set for sales outreach rather than marketing consent. Assuming a phone number in the system means marketing SMS consent exists is a compliance risk worth checking before a single text goes out from Klaviyo.

Sequencing the Migration

Phase One: Audit Every AMPscript Block and Data Extension

Before any rebuild starts, someone needs to go through every active AMPscript block and document what it's actually doing. This is the least glamorous part of the migration and the one that gets skipped most often under deadline pressure, which is exactly why it causes the most expensive problems later.

Phase Two: Rebuild Core Flows on Klaviyo-Native Data

Welcome, abandoned cart, and post-purchase flows get rebuilt using Klaviyo's own event and profile model, not translated line by line from Journey Builder canvases. Any personalization that depended on a relational join gets redesigned around a flattened property or synced custom event first.

Phase Three: Migrate Volume in Tiers, Then Retire SFMC

Once core flows are live and performing, migrate list volume in engagement tiers rather than all at once, and keep SFMC active in a read-only capacity for at least a full quarter before decommissioning, since enterprise accounts often have reporting and compliance dependencies that take longer to unwind than the email program itself. For more on how we approach flow rebuilds during a platform move, see our retention marketing services overview.

Reporting and Governance Look Different Too

SFMC's reporting infrastructure was built for enterprise governance: role-based access controls, approval workflows for sends, and audit trails that satisfy compliance teams at large organizations. Klaviyo has permissions and approval features, but they're built for a smaller marketing team running its own program, not for a multi-stakeholder enterprise sign-off chain. Brands migrating from SFMC sometimes assume Klaviyo will replicate the same governance structure automatically. It won't, and that's worth flagging to legal or compliance stakeholders before the migration, not after someone asks where the approval audit trail went.

Reporting itself shifts too. SFMC's reporting is built around campaign-level metrics tied to a Journey Builder canvas, often exported into a separate business intelligence tool for the numbers leadership actually looks at. Klaviyo's reporting lives natively in the platform and is built around flow-level and campaign-level revenue attribution tied directly to Shopify or your ecommerce platform. That's a more direct read on what's actually driving revenue, but it means whoever owns the BI dashboard needs a new data source, and any custom report that pulled from SFMC's data extensions needs to be rebuilt against Klaviyo's API or its native reporting instead.

The team question matters just as much as the tooling question here. SFMC programs at this scale often had a dedicated marketing operations or CRM developer on staff, sometimes a full team, maintaining the AMPscript and Journey Builder logic. Klaviyo is designed so a strategist or producer can run flows and segmentation without a developer in the loop day to day. That's a genuine efficiency gain, but it also means the migration is a good moment to have an honest conversation about what the team structure should look like once the platform stops requiring dedicated technical maintenance just to keep email running.

Why DIY Migrations Fail

The specific failure mode we see most with SFMC migrations is relational data collapse: a team exports every data extension as a flat Klaviyo list, migrates the core flows, and never goes back to rebuild the relational joins that made the original personalization work. The emails still send. They just stop being personalized in the way they used to be, and because nothing technically breaks, nobody notices until a customer points out they got a "recommended for you" email for a product they returned eight months ago, because the join that would have excluded returned items never got rebuilt.

This happens because the people capable of untangling AMPscript are often long gone from the company by the time a migration gets prioritized, and the people running the migration inherit a system they didn't build and don't fully understand. Nobody wants to be the one who breaks a working personalization engine trying to document it first, so the shortcut of flattening everything into static lists feels safer even though it quietly throws away the platform's whole reason for existing.

How Sticky Digital Handles an SFMC Migration

We start with a full audit of every Data Extension and AMPscript block, documenting exactly what each one is doing before we touch a rebuild, since guessing at legacy logic is how personalization quietly breaks. We map every relational join to its Klaviyo-native equivalent, whether that's a flattened profile property or a custom event synced from an external system, so the personalization survives the move instead of getting flattened away by default.

We rebuild Journey Builder canvases as Klaviyo flows using ecommerce-native triggers, piping in any external system events as custom events where needed. We stage list migration in engagement tiers appropriate to the account's actual scale, not a generic timeline borrowed from a smaller migration. And we keep SFMC live in read-only mode through a full reporting quarter before recommending decommission. Brands that want a team that's untangled AMPscript before tend to skip the personalization regression that shows up when this gets rushed.

FAQ

Can Klaviyo replicate SFMC's AMPscript personalization?

Not directly, since Liquid can't run a live database query the way AMPscript does. The underlying logic has to be rebuilt so the data it needs already exists on the Klaviyo profile or as a custom event before the email sends, rather than being fetched dynamically at send time.

What happens to my Data Extensions during the migration?

They need to be audited individually to determine what relational logic they were supporting, then rebuilt as Klaviyo profile properties or custom events. Exporting them as static lists gets the contacts into Klaviyo but loses the relational intelligence that made the original personalization work.

How long does an SFMC to Klaviyo migration take for a large list?

Enterprise-scale lists typically need a graduated warmup across three or four engagement tiers, often closer to three weeks, compared to shorter timelines that work for smaller migrations. Rushing volume for a large list is one of the fastest ways to damage deliverability early.

Do I need to rebuild my Journey Builder canvases from scratch?

Yes, in almost every case. Klaviyo flows are built around ecommerce-native triggers like orders and product views, so any journey based on an external system event, like a Salesforce object update, needs that event piped into Klaviyo as a custom event before the equivalent flow can exist.

What's the biggest risk in an SFMC migration specifically?

Relational data collapse: flattening every data extension into a static list and never rebuilding the joins that powered the original personalization. Emails keep sending, but the personalization quietly stops working, often without anyone noticing until a customer flags it.

Brands ready to untangle the legacy logic and rebuild it properly can start here.

Article By: Mariel Kilroy, Co-Founder, Sticky Digital

Mariel Kilroy is the Co-Founder of Sticky Digital, a retention marketing agency specializing in email, SMS, loyalty, and subscription growth for DTC brands.