Using SPARKCRM to prepare for a Klaviyo migration (or consolidation across stores)
Planning a Klaviyo migration? See how a real brand used SPARKCRM to audit flows, segments, and suppression logic before consolidating two stores into one account.


A Klaviyo migration that goes well is invisible. Everything moves over, the flows keep running, and within a few weeks the new account feels like home. A migration that goes badly is the opposite: broken automations, missing suppression data, segments that reference properties that no longer exist, and a team spending weeks doing damage control.
The difference between the two is almost always preparation. Most Klaviyo migration failures happen because teams skip the audit phase and go straight to execution. This post walks through exactly what that audit should cover, using a real case we handled for a brand consolidating two Shopify stores into a single Klaviyo account.
The migration that almost went wrong
A mid-size fashion brand came to us after acquiring a smaller label. Both brands ran on Shopify. Both had their own Klaviyo accounts. The plan was to consolidate everything into the main account within 60 days.
The first thing we did was map what was actually in each account. What we found in the acquired brand's Klaviyo account:
- 27 flows in total, 11 of which were active
- 6 flows that were technically active but had received zero recipients in the last 90 days
- 14 segments, 5 of which referenced a custom property that had been deprecated when they switched Shopify themes
- A suppression list that had never been exported or documented
- Three different versions of the welcome series, built at different times, with no clear indication of which one was current
None of this was visible from the outside. The account looked functional. Only the audit revealed how much technical debt had accumulated.
This is not unusual. In every Klaviyo account I've audited, there's a gap between how the team perceives their setup and what's actually in the account. The migration process forces that gap into the open. Better to find it before you move anything.
Phase 1: Map what you have before touching anything
The first step of any Klaviyo migration is a complete account map. Not a cursory look at the flows list. A systematic review of every active automation, its trigger, its segment dependencies, and its performance.
For each flow, answer three questions:
- Is it generating revenue? Pull 90-day attributed revenue. Flows with zero revenue and low recipient counts are candidates for archiving rather than migrating.
- Does it depend on a custom integration, property, or third-party trigger that needs to be set up separately in the new account? These are your migration risks.
- Is there more than one version of it? Duplicate flows are common. Migrate the winner, archive the rest.
For the fashion brand, this phase took three days. It would have taken much longer mid-migration when everyone is under pressure to get things live.
SPARKCRM's Flow Map gives you a visual overview of every active automation with performance data attached. It doesn't replace the human judgment of deciding what to migrate, but it removes the discovery phase that usually eats the most time. See how it works in the Klaviyo flows documentation.
Phase 2: Audit your segment dependencies
Every flow and most campaigns depend on segments. Before migrating, you need to know which segments are actually in use versus which ones were built for a campaign two years ago and never cleaned up.
In the fashion brand's case, we found that 5 of 14 segments were orphaned. They existed in the account, but no active flow or recent campaign referenced them. Three of those orphaned segments referenced the deprecated custom property. Migrating them would have brought broken segments into the new account.
The audit process for segments:
- List every segment in the account
- Check which flows and campaigns reference each one
- Check that the conditions still work: do the properties they reference still exist in the data?
- Mark each segment as: migrate, rebuild, or archive
This step is tedious but fast to execute once you have the list. The risk of skipping it is migrating dead weight into a clean account and then spending months figuring out why certain flows aren't working as expected.
Phase 3: Document your suppression logic
This is the step that gets skipped most often, and the one with the most serious consequences.
Your Klaviyo account has suppression logic that's built up over time: people who unsubscribed, contacts marked as spam complainers, GDPR deletion requests, sunset policy suppressions, and in some cases manual suppressions added by the team for specific reasons. If this logic doesn't transfer to the new account, you'll send to people you legally or ethically shouldn't be sending to.
For the fashion brand, the acquired account had 847 suppressed profiles. About 200 of them were suppressed because of GDPR deletion requests handled outside Klaviyo (the team had maintained a separate list). Without the audit, those 847 contacts would have landed in the new account as active profiles.
What to capture before migration:
- Klaviyo suppression list: export from Settings > Suppressions
- Any custom suppression properties you use as flow filters (e.g. 'do not email' flags)
- GDPR/CCPA deletion records that live outside Klaviyo (check your legal team and your data processor agreements)
- Sunset policy rules: which profiles are filtered out of sends based on engagement thresholds?
Documenting this completely takes half a day. The cost of getting it wrong is much higher.
Phase 4: Run a parallel monitoring period
For most migrations, there's a window where the old and new accounts are both active. Old campaigns are winding down. New flows are being tested. This is where things get confusing if you're not tracking both sides.
For the fashion brand, we ran both accounts in parallel for three weeks. During that time, we compared key metrics daily between the accounts: flow recipient counts, open rates, deliverability signals, revenue attribution.
Two issues surfaced during this period that we wouldn't have caught otherwise: a post-purchase flow in the new account was triggering on a slightly different event than the original (a naming difference in the Shopify webhook), and the welcome series was sending to a broader audience than intended because a segment condition didn't translate exactly between accounts.
Both were fixable in hours once spotted. Neither would have been fixable quickly if the old account had already been shut down.
Recommendation: run the parallel period for a minimum of two weeks. Four weeks for high-volume accounts or complex automation setups. The incremental cost is low compared to the risk of a hard cutover.
What the audit revealed: final numbers
After the full audit and migration, here's what happened to the acquired brand's Klaviyo account:
- 27 flows reduced to 9 migrated (4 rebuilt from scratch, 14 archived)
- 14 segments reduced to 7 migrated (5 archived, 2 rebuilt with corrected conditions)
- 847 suppressed contacts properly transferred, including the 200 managed outside Klaviyo
- Zero revenue-generating automations interrupted during the migration window
The migration took six weeks instead of the original 60-day plan. The extra two weeks came from the parallel monitoring period. In retrospect, the brand said the extra time was worth it. They had one migration. There wasn't room for a redo.
The general principle: audit before you migrate
Whether you're moving from another ESP, consolidating stores, or rebuilding a Klaviyo account from scratch, the preparation work is the same. Map what you have. Document your dependencies. Capture your suppression logic. Run a parallel period before you cut over.
Teams that skip these steps don't save time. They trade upfront audit time for post-migration firefighting time, usually at the worst possible moment (post-launch, pre-campaign, or during a seasonal peak).
The brands I've seen handle migrations cleanly all have one thing in common: they treated the audit as a standalone project, not a checkbox on the migration task list.
How to prioritize what to migrate vs. what to rebuild
One of the more useful outputs of a pre-migration audit is a clear decision on what goes in each bucket: migrate as-is, rebuild from scratch, or archive.
The decision tree we use:
Migrate as-is
- The flow is generating consistent revenue in the last 90 days
- The segment conditions are still valid and use current properties
- The email content is still on-brand and accurate
- No significant changes are planned to the flow strategy
Rebuild from scratch
- The flow is generating revenue but the structure is outdated or overly complex
- The copy is off-brand or references old promotions/products
- The trigger or segment conditions need significant rework anyway
- You've been planning to improve the flow and migration is a natural reset point
Archive
- The flow has zero recipients in the last 90 days
- The flow's purpose is covered by another active flow
- The flow was built for a specific campaign that ended
- The segment it targets no longer exists or makes sense
For the fashion brand in our case study, this framework turned a list of 27 flows into a manageable migration project. Instead of trying to move everything, the team focused their energy on the 9 flows that actually mattered. The rest were documented and archived. The new account started clean.
What to do with flows you are archiving
Archiving a flow does not mean losing the work that went into building it. Before archiving, export a screenshot or PDF of the flow structure and email content. Store it in a shared drive folder labeled with the account name and migration date.
Note the performance data too. Knowing that a flow drove a specific amount of revenue over a given period is useful context for building the replacement, or for explaining strategic decisions to a new team member six months from now.
For the fashion brand in this case study, archiving 18 flows felt uncomfortable at first. The CRM manager had personally built several of them. But the audit data was clear: those flows had generated zero revenue in the previous 90 days. The records gave the team confidence the decision was documented and reversible if needed.
Handling multi-store consolidations
Consolidating two Klaviyo accounts into one adds complexity beyond a standard migration. You are merging two customer bases, two sets of flows, and potentially two distinct brand voices into a single account structure.
Profile deduplication
Customers who have shopped at both brands exist in both Klaviyo accounts. Klaviyo uses email address as the unique identifier, so profiles with the same email merge automatically during consolidation. But the property values need resolving intentionally. Which purchase history takes precedence? Which custom properties conflict between accounts?
Naming conventions
Two accounts built independently will have different naming conventions for segments, flows, and templates. Before migrating, agree on a unified convention and rename everything in the source accounts first. This prevents the new account from becoming a mess of inconsistently named objects within weeks of launch.
Brand voice in shared flows
If the two brands have distinct voices, some flows may need to branch based on which brand the customer originally came from. Klaviyo flow filters and conditional splits handle this, but it needs planning during the audit phase, not mid-migration.
Consolidations that skip this planning work result in accounts that are technically functional but operationally confusing. The team ends up cleaning up inconsistencies for months instead of improving performance.
Timing your migration: when not to do it
Migrations introduce risk. Risk and peak periods do not mix. Avoid scheduling a Klaviyo migration within 8 weeks of Black Friday or Cyber Monday, during an active promotional calendar, when a key team member is on leave, or immediately after a major platform change like a new Shopify theme.
The safest windows for most Northern Hemisphere e-commerce brands: February-March or June-July. Enough time before peak periods to stabilize, and slow enough in terms of campaign volume that the team can focus on the migration properly.
💡 SPARKCRM includes a pre-migration audit workflow that maps your flows, segments, and suppression logic before you move anything. If you're planning a migration in the next 90 days, request a free audit at sparkcrm.cc before you start.
The general principle: audit before you migrate
Whether you are moving from another ESP, consolidating stores, or rebuilding a Klaviyo account from scratch, the preparation work is the same. Map what you have. Document your dependencies. Capture your suppression logic. Run a parallel period before you cut over.
Teams that skip these steps do not save time. They trade upfront audit time for post-migration firefighting time, usually at the worst possible moment: post-launch, pre-campaign, or during a seasonal peak.
The brands I have seen handle migrations cleanly all share one thing: they treated the audit as a standalone project, not a checkbox on the migration task list. If you are planning a migration in the next 90 days, the audit should start now, not the week before you move.
Before you start: a final note
The most common feedback I hear after a successful Klaviyo migration is that the team wished they had started the audit earlier. The audit itself is not the hard part. The hard part is deciding what to do with what you find: which flows to rebuild, which segments to retire, which suppression rules to carry forward and which ones to rethink. Those decisions take time and benefit from calm reflection, not deadline pressure. The earlier you start, the better those decisions will be. A migration that begins with a clear picture of the current state almost always ends better than one that begins with a rushed export and a hope that things transfer cleanly.
Found this article helpful? Share it with others!