What breaks when you switch email platforms

What travels with you

One thing migrates cleanly: your subscriber list, as a CSV export from your current platform. Most major ESPs let you export a file with email address, first name, tags, and custom fields. That file is the foundation of your import on the new side.

Two items that must travel with it but are easy to miss:

• Your unsubscribe list. Export it separately and suppress those addresses on the new platform before sending anything. Failing to do this means you will email people who already opted out, which violates CAN-SPAM and GDPR and will trigger spam complaints on a fresh IP that has no reputation buffer yet.
• Your hard bounce list. Same logic: import as suppressed. A high bounce rate on a warming IP is the fastest way to land in the spam folder.

Tags and custom fields also travel in the CSV, but only if your destination platform uses the same field names or you remap them during import. Do this mapping before import.

What breaks

1. In-flight automation sequences

Any subscriber currently in the middle of a multi-step sequence will not receive the remaining emails once you cut over. The new platform has no record of where they were in the sequence. This is the highest-stakes breakage because it is invisible: nothing throws an error, the subscriber just stops hearing from you mid-onboarding or mid-drip.

The standard fix is to keep your old ESP running in parallel for any active automation until every subscriber in those sequences has finished. Only then do you shut down the old account. Depending on sequence length, this parallel period can run two to eight weeks.

2. Engagement history

Your historical open rates, click rates, subscriber engagement scores, and campaign performance data do not migrate. They live inside the old ESP's database. You can export summary reports from the old platform for your own records, but the new platform starts with a blank slate. This matters for segmentation: if you have been segmenting by engagement level (active vs. cold subscribers), you will need to re-establish that signal by running sends on the new platform before your segments are meaningful again.

3. Sender reputation and IP warm-up

This is the breakage with the longest recovery time. Every ESP sends from a pool of IP addresses. Your sending history, complaint rate, and inbox placement rate are tied to those IPs rather than to your domain name. When you move to a new platform, you move to a different IP pool. From Gmail's and Yahoo's perspective, you are a new sender.

A new IP sending at full volume immediately is a spam signal. The standard approach is a warm-up: start with a small daily send (a few hundred emails), gradually increase over two to six weeks, and monitor inbox placement at each step. On shared IP pools — typical for lists under roughly 50,000 subscribers — the ESP handles warm-up internally. On dedicated IPs, you manage it manually.

The risk window is the first two to four weeks: this is when your inbox placement is lowest and your complaint rate signal matters most. Do not send to your coldest or least-engaged subscribers during warm-up. Start with the segment most likely to open and engage.

4. DNS authentication records

SPF and DKIM records are ESP-specific. Your current ESP gave you specific values to add at your DNS host when you set it up. Your new ESP will give you different values. You must update them before the new ESP can send on behalf of your domain. If you send before updating, your emails will fail DKIM authentication and inbox placement will suffer immediately. DMARC is domain-level and typically does not need to change, but verify with your new provider.

Our deliverability setup guide covers SPF, DKIM, and DMARC in detail, including the specific steps we ran for fieldtestedhq.com.

5. Automation logic and sequences

Beyond the in-flight breakage, your automation workflows do not export in any portable format. Mailchimp automations cannot be imported into Kit. Kit automations cannot be imported into MailerLite. Every sequence, trigger, conditional, and step must be reconstructed from scratch in the new platform's interface. For a simple welcome sequence this takes an hour or two. For a complex behavioral automation with multiple branches, plan for a day or more per automation.

Before starting the migration, document every active automation: trigger, number of steps, timing, branching logic, and tags applied at each step. This documentation is your rebuild spec and helps you spot gaps when the new version goes live.

6. Segments and tags

Segments that are based on engagement history (opened in last 30 days, clicked a specific link) cannot migrate because the engagement history does not migrate. Segments based on tags or custom fields can migrate if the underlying data is in your CSV export. Re-verify every segment definition on the new platform before it runs any automated or scheduled send.

7. Forms and landing pages

If you are using your ESP's native forms or landing pages embedded on your site, they stop working when you shut down the old account. Build replacement forms and landing pages on the new platform first, test them, then swap the embed codes on your site. Do not decommission the old forms until the new ones are live and verified.

8. Email templates

Template files are not portable between platforms. The design, layout, and content can be copied manually, but the template must be rebuilt in the new platform's editor. For a newsletter that uses a consistent layout, this is a one-time rebuild. For one with many campaign-specific templates, it is more work.

Re-permissioning: when you need it

Re-permissioning is the process of asking your existing subscribers to actively confirm they still want to hear from you. It is not required for every ESP switch. It is required in two situations:

• Your consent records are incomplete or ambiguous. If subscribers signed up through a flow that did not collect unambiguous consent (pre-checked boxes, an imported cold list, a list purchased from a third party), most compliant ESPs will not let you import those addresses. Kit's policy is explicit: "each person on your list is required to have provided their permission to receive your marketing emails" and, if you lack that documentation, "you may not contact that list via Kit, or any other compliant email marketing provider." (Kit help center, retrieved July 28, 2026.)
• You are moving from a less-strict to a more-strict consent regime. If your previous ESP had loose standards and your new one requires documented double opt-in records, you need to either document existing consent or re-collect it.

If subscribers signed up through a clear opt-in form and you have records of that consent, you do not need to re-permission them when switching ESPs. The consent was given to you as the sender. What travels is the consent itself.

One technical note: Kit automatically marks imported subscribers as confirmed, bypassing double opt-in, even for forms that have it enabled. This makes sense given the consent-already-documented requirement, but it means the platform trusts you to have done the compliance work before import rather than re-running it after.

The Substack edge case: paid subscribers

Switching from Substack introduces a specific complication that does not apply to other platforms. Free subscribers export and re-import cleanly. Paid subscribers are different: their billing relationship is with Substack rather than with you. You can export their email addresses, but you cannot migrate their active subscriptions to a new payment processor on a different platform. Readers who pay via Substack would need to cancel there and re-subscribe on the new platform, which is a real ask with real dropout risk.

This friction is not a Substack policy choice to penalize departing creators; it is a structural consequence of who holds the payment relationship. Our Substack vs Kit fee comparison covers this as part of the broader platform decision.

Migration checklist

The steps below are ordered by dependency. The automation-clarity labels mark what an AI agent can execute headless versus what requires a human action.

Your part: about 30 minutes of direct action. Eight of these twelve steps run without a human in the loop. You step in four times: account creation (step 3), DNS credential access (step 4), send approval for the warm-up window (step 10), and canceling the old account (step 12). The rebuild work in steps 5 and 8 can be AI-driven if your automation builder supports API access or if you are using an AI agent to operate your stack.

How long it takes

The technical setup (steps 1 through 9) can run in a day or two if the automations are simple. IP warm-up is the constraint: it takes two to six weeks depending on list size and engagement level. A list under a few thousand subscribers on a shared IP pool may warm faster than a large list on a dedicated IP.

The parallel-ESP overlap period adds to the clock: if you have a 10-email sequence with 3-day gaps, you are running parallel ESPs for at least 30 days. Budget the total migration window at four to eight weeks, not days.

Sources

• Kit subscriber import policy, consent requirement, double opt-in override: help.kit.com/en/articles/5027047-importing-subscribers-into-kit-what-to-know-faqs, retrieved July 28, 2026. Down-rank: Kit is our affiliate partner; verify independently.
• Kit migration guide (general): help.kit.com/en/articles/4077011-migrating-to-kit-from-another-platform, retrieved July 28, 2026.
• In-flight automation loss, segment rebuild, IP warm-up, DNS requirements: mailerlite.com/blog/esp-migration, retrieved July 28, 2026.
• Historical data loss, IP warm-up timeline, re-permissioning triggers: dyspatch.io/blog/the-ultimate-guide-to-switching-email-service-providers-esps, retrieved July 28, 2026.