Alen Capelja.
← Library

Assignment #4 · Lifecycle · November 16, 2026 · 5 min

Migrate your ESP without losing revenue

Where an email and SMS platform change puts revenue at risk, and the order I'd move data, warm up sending and rebuild flows to keep it.

The question

“How do you move 9 million profiles without losing a day of revenue?”

The assignment

Before you agree to a cutover date, work through the pre-migration checklist and put the warmup on the calendar.

9 million profiles migrated

Profiles moved between email platforms during peak Q4

When a large California retailer moved from Cordial to Klaviyo, I was the CRM and lifecycle manager on the account. We moved 9 million profiles during their peak Q4, when there was no room for a mistake that touched revenue. We went from zero to roughly 9 million emails a day in 45 days without a single revenue-impacting incident.

I also led the move to Klaviyo for a second retailer with two customer types, consumers and trade accounts. That one had different problems, mostly about how to structure the account and how slowly to warm it up.

If a platform change is on your calendar, this is the order I'd work in and the checks I'd run.

Why migrations fail

At the retailer the project ran through IT, the dev team, the .NET team and marketing, five or more departments in all. Each had its own priorities and its own idea of what a good launch looked like, and their requests came to me. On top of the migration I was advising on the Cordial sunset, the CRM sync, tracking and integration for the native app, and the SMS integration, all at once.

Scale makes small errors expensive. With 9 million profiles, a field mapped to the wrong place affects everyone it touches at the same moment, and you may not see it until a flow sends the wrong offer or sends nothing.

Then there's the inbox. Sending volume on the new platform has to be built up from zero, and at the second retailer we hit technical problems that could have done real damage to inbox placement.

What to migrate, in what order

At the retailer the data came in through SFTP imports, using custom Python scripts I wrote for customer profiles, the product catalog and historical transactions. Live events and the integrations came on top of that. This is the order I'd follow:

  1. Account structure. Decide it before you import anything. At the second retailer, consumers and trade accounts bought in very different ways, so we built separate structures for each. That gave the business performance reporting by customer type for the first time.
  2. Profiles, with their email and SMS consent and every unsubscribe and suppression.
  3. The product catalog, since abandonment and post-purchase messages pull product details from it.
  4. Historical transactions. Tiers, RFM scores and the expected reorder dates behind a predictive purchase flow all come from order history. Without it, your best customers arrive looking like people who have never ordered, and they get the first-order offer.
  5. Live events from the site and the app, once the first four are in and checked.
  6. Flows, last.

The warmup

The 45 days it took the retailer to reach full volume belong in the plan from the start. If the new platform is expected to carry your full volume on its first day, the plan already has a problem.

My general advice is to start with the people who have opened or clicked most recently and widen the audience as inbox placement holds. Decide the old platform's sunset date only after the warmup is planned, so you are never forced to send full volume from a domain the inbox providers have not learned to trust yet.

At the second retailer, those technical problems meant we ran a very conservative warmup schedule. If something looks wrong during the warmup, I'd slow down before I'd push more volume.

Validating the data model

Every week during the migration I ran an alignment meeting with the teams involved to validate the data model and the event structures. At 9 million profiles, one mistake would have been very hard to undo.

I check two things. The first is the profile data your segments use. The five tiers I described in the first issue come from order count and lifetime value, with $840 as the line between the top two. If either number comes over wrong, people land in the wrong tier, and every flow that splits by tier sends them the wrong message.

The second is events. Every flow starts from one, and the definitions are specific. In the retailer's framework, abandoned product fires when someone spends 30 seconds or more on a product page, or views it twice or more, without adding to cart. Abandoned cart fires when a cart sits for 30 minutes without a checkout. If an event name or property doesn't match what the flow expects, the flow doesn't fire, and the first sign is a flow with nobody in it.

The checks themselves are plain. Pick a few customers you know, including some long-time buyers, and compare their order count and lifetime value in the new platform with your store's own records. Then trigger each event yourself, on the site and in the app, and confirm it arrives with the fields the flows read.

What to rebuild first once you're live

Once the retailer was live, I migrated the core flows within the first 30 days: welcome, browse and cart abandonment, post-purchase, winback and loyalty. I'd put these first in any migration, because each one answers something a customer just did, and a gap there means someone signed up or left a cart and heard nothing.

After that I built the segmentation strategy and the segments, and the flows were reworked around the tiers, so the trigger stayed the same and the message changed with the customer. The team could target in ways they couldn't before.

At the second retailer the two customer types were different enough that we rebuilt every email template and reconstructed the flows with separate logic for consumers and trade accounts as part of the move. Whichever way you go, get the core flows running before you work on finer segments.

Do this Monday

Before you agree to a cutover date:

  1. List every system that sends data to your current platform, such as the store, CRM, app, SMS and site tracking, and name the person who owns each one.
  2. Write down every flow trigger you use today, the event behind it and the fields the flow reads.
  3. Check that your transaction export carries order count and lifetime value per customer, or the order history to calculate them. If you sell to more than one type of customer, decide how the account will be structured.
  4. Put the warmup on the calendar next to your contract end date and your peak season. At the retailer, reaching full volume took 45 days, and it ran through peak Q4.
  5. Book a weekly meeting with whoever owns your data, at least IT, dev and marketing, for the length of the project.
  6. Pull attributed revenue for welcome, browse and cart abandonment, post-purchase, winback and loyalty over recent months, so you have a baseline to compare against after the switch.
  7. Confirm that unsubscribes, suppressions and SMS consent come across with the profiles.

In one line: get the order history in and checked before the flows go live, and give the warmup its own weeks on the calendar.

Yewgo. Every Monday.

One assignment a week, in your inbox before Monday.

More from the Library