We Migrated 40,000 Email Subscribers Mid-Month. Here’s the Order of Operations.
We migrated 40,000 email subscribers from one platform to another while running 11 active campaigns and planning 30 emails for April.
Not ideal timing. But the calendar doesn’t stop because you decided to change platforms.
And that’s the thing about email migrations — nobody plans them for a quiet week. They happen because costs blew out, or the platform stopped growing with you, or the support got unbearable, or someone finally ran the numbers and realised you were paying for features you’d never use. It’s always mid-campaign. It’s always inconvenient.
So this is the order of operations we used. Not a hypothetical framework. The actual sequence, from a live migration, where the stakes were real and the sends kept going.
Why Migrations Fail
Most email platform migrations fail for three reasons, and they all happen in the first 48 hours.
First: people rush the subscriber export. They pull the list, skip the tags and segments, and dump 40,000 addresses into the new platform as a flat file. Then they spend the next six weeks rebuilding the segmentationps://grey-wolf.co.za/fifteen-emails-one-week-zero-unsubscribe-spikes/" class="linkosaurus-link" data-linkosaurus-source="2006" data-linkosaurus-target="2008" data-linkosaurus-score="0.591">segmentation they had in the old system.
Second: they forget the suppression list. This is the one that genuinely worries me, because it’s not just an operational problem — it’s a legal one. Your suppression list is every person who has unsubscribed, bounced hard, or asked to never be contacted again. If that list doesn’t come with you, you will email people you have no right to email. Deliverability hit is the least of your concerns at that point.
Third: they send too fast out of the gate. They migrate the list, fire up the first campaign, and wonder why open rates collapsed. Your domain reputation lives with your sending history. New platform, potentially new sending infrastructure — the inbox providers haven’t seen enough volume from this configuration to trust you yet. You have to earn it again.
Most migrations skip one of these. Some skip all three. The result is a list that takes months to recover, if it recovers at all.
The Sequence That Works
Here’s what we actually did, in the order we did it.
Step 1: Export subscribers with every tag and segment intact
Do not export a raw address list. Export everything — behavioural tags, custom segments, purchase history flags, engagement categories, suppression status. Whatever the old platform knows about your subscribers, you want it in that export file.
Before you pull the export, document what segments exist and what logic drives them. You’ll need to recreate that logic in the new platform, and if you didn’t write it down when you built it, you will struggle to remember exactly how the “engaged in the last 90 days” filter was constructed.
This step takes longer than you think. Do it first.
Step 2: Export and protect the suppression list
This is not optional. Export your full suppression list — every unsubscribe, hard bounce, and spam complaint — before you touch anything else in the migration.
Import this list into the new platform immediately. Before any subscribers. Before any templates. Before any automations. The suppression list goes in first, so there is zero chance a suppressed contact slips through.
If you are moving from Klaviyo to MailerLite (or any other combination), these platforms handle suppression differently. Map the status fields carefully. A “globally unsubscribed” contact in one platform may not automatically suppress in another unless you explicitly mark it that way on import.
Step 3: Recreate templates before importing subscribers
Build your email templates in the new platform before a single subscriber arrives. Test them. Render them across email clients. Find the quirks in the new template editor — there will always be quirks.
This matters because the moment you import subscribers, you are officially running on the new platform. If a campaign fires before the templates are ready, you either delay the send (which might not be possible) or you send something that looks broken.
Templates first. Subscribers second.
Step 4: Verify DNS and sending domain before any sends
Before you send a single email from the new platform, your DNS records need to be correct. SPF, DKIM, DMARC — all verified. If you are using a custom sending domain, make sure it is configured and authenticated in the new platform, not just listed.
Most platforms have a domain verification tool that will flag issues. Use it. Then wait for the DNS propagation to complete properly before you send anything. Rushing this step is how you land in the spam folder on day one.
Step 5: Pause automations selectively — not everything
This is the step people get wrong in both directions. Some people pause nothing, and subscribers start receiving automation sequences that reference the old platform’s logic, or worse, duplicate sequences from both platforms running simultaneously. Some people pause everything, and important transactional or welcome sequences go dark during the migration window.
The answer is selective pausing.
Pause anything that depends on platform-specific logic you haven’t yet rebuilt. Pause automations that overlap with the migration period where someone might trigger from both old and new platforms.
Do not pause transactional automations unless you have a verified replacement running. Do not pause welcome sequences if new subscribers are still coming in.
Write out every active automation, categorise it, and make an explicit decision for each one: pause, leave running, rebuild first.
Step 6: Test sends across primary email clients before going live
Send test emails to a seed list that covers the major clients — Gmail, Outlook (the tricky one), Apple Mail, and mobile. Check rendering. Check links. Check that tracking pixels are firing. Check the unsubscribe link works and routes to the correct page.
This is boring and it matters enormously. Broken rendering on Outlook is a gift that keeps giving.
Step 7: Run a warm-up plan if your domain reputation is resetting
If your sending IP or domain has changed as part of the migration, your deliverability reputation does not automatically follow you. Inbox providers learn to trust sending configurations over time, based on consistent volume and positive engagement signals.
You may need to warm up. This means starting with smaller sends to your most engaged subscribers, gradually increasing volume over a week or two, letting the engagement signals accumulate before you send to the full list.
Whether you need to warm up depends on your migration specifics. If you kept your sending domain and the new platform uses your own dedicated IP, you may be fine. If you are sharing infrastructure or changed domains, plan for a warm-up.
Do not find out you needed a warm-up plan by watching open rates fall off a cliff on day three.
Step 8: Establish go/no-go criteria before the cutover date
This is the step most people skip because it feels like unnecessary formality.
It isn’t.
Before you flip the switch, you need to know what “ready” looks like. Write it down. Ours included:
- Suppression list imported and verified
- DNS records verified and propagated
- All active automation sequences rebuilt or paused
- Template render test passed for all major clients
- One test send completed successfully from the new platform
- Warm-up plan in place if required
Every item needs a checkmark. If something is red on cutover day, the migration does not proceed. You push the date, fix the issue, and try again.
The temptation to push through with one or two items unresolved is enormous, especially when the team is tired and the next campaign is looming. Don’t. A single bad send to 40,000 people is harder to recover from than a one-week delay.
The Cost of Getting This Wrong
A bad email migration is not just an annoying technical problem. It is a business problem.
Deliverability damage takes months to recover. A sharp drop in open rates signals to inbox providers that something changed — and not in a good way. Rebuilding sender reputation takes consistent positive engagement over time. You cannot rush it.
List damage is often permanent. If you email suppressed contacts and generate spam complaints, some of those contacts are gone. Not just disengaged — actively hostile. Conversion rates on a damaged list are lower even after you clean it up.
Legal exposure is real. Emailing unsubscribed contacts is not a grey area. GDPR, POPIA, CAN-SPAM — the details differ by jurisdiction but the principle is universal. Your suppression list is a legal obligation, not just a deliverability best practice.
The migrations that fail are never missing resources. They are missing a sequence. Someone decided to figure it out as they went, and the cost of that decision showed up later.
One More Thing
If you are planning a migration and the timing feels impossible — 11 active campaigns, 30 emails planned, list of 40,000 — you do not need a window of calm. That window will not come.
You need the right sequence, executed in the right order, with go/no-go criteria you actually enforce.
We migrated mid-month. The April calendar ran on schedule. The list came through intact.
It is not magic. It is just the correct order of operations.
