Data
How to migrate ESPs without data loss
Joey Lee
You’ve made the decision to switch. The hard part is executing the migration without wrecking your deliverability, losing subscriber history, or breaking automations mid-flight.
Some ESP vendor migration guides indicate that the core migration work can be completed in as little as two to four weeks, assuming a straightforward setup. That timeline is fantasy for any program with meaningful complexity. A mid-market migration (100K+ contacts, 10+ active automations, and integrations with at least two other systems) typically takes three to four months when done correctly. Enterprise migrations run four to six months.
The difference between a clean migration and a messy one is preparation. Here’s the playbook.
Data architecture doesn’t translate one-to-one
This is where migrations go wrong before they start. ESPs structure subscriber data fundamentally differently, and assuming you can do a field-to-field export-import is how you end up with broken segments and missing history.
Klaviyo uses a profile-centric model. Every subscriber is a unified profile with properties, events, and list memberships attached directly. Data is flat and denormalized.
Salesforce Marketing Cloud uses relational data extensions, essentially SQL tables. Subscriber data lives across multiple DEs with primary key relationships. A single subscriber’s data might span five or six tables.
Customer.io is event-driven. The subscriber record is lightweight; the real value is in the event stream. Migrating profiles without migrating event history means your behavioral segments won’t work on the new platform.
Braze uses a hybrid model with user profiles, custom attributes, and custom events. It expects data in specific formats, and its real-time processing pipeline means import ordering matters.
Before you export a single record, map the data architecture of your source and destination platforms. Document every custom field, every computed property, every relational join. Build a translation layer: a spreadsheet or data dictionary that maps source fields to destination fields, notes format differences (date formats, boolean representations, array vs. string), and flags fields that have no equivalent.
Suppression lists: the #1 deliverability risk
If you take one thing from this playbook, take this: suppression list migration is the single most common cause of post-migration deliverability collapse.
Your current ESP holds four categories of suppression data, each with different transfer rules:
Hard bounces: Export the full list. These addresses are confirmed invalid and must be suppressed on the new platform before your first send. Sending emails to known hard bounces on a new IP is the fastest way to get blocklisted.
Soft bounces: More nuanced. A soft bounce in Mailchimp might be classified differently in Braze. Export soft bounces with the bounce reason and date. On the new platform, suppress addresses with 3+ recent soft bounces; allow others to attempt delivery.
Spam complaints: Critical. Anyone who marked your email as spam must be suppressed on the new platform. Some ESPs share complaint data through feedback loops; others don’t expose it in exports. Ask your current ESP explicitly for complaint data. Don’t assume it’s in the standard export.
Unsubscribes: These must be honored on the new platform as they are a CAN-SPAM and GDPR requirement. Export unsubscribes with timestamps and channel-level granularity.
DNS and authentication: running dual configurations
During migration, you’ll be sending from both ESPs simultaneously. That means both platforms need valid authentication records.
SPF: You’ll need both ESPs’ SPF includes in your DNS record. The catch: SPF has a 10-lookup limit. If your existing record is already at 8 or 9 lookups, adding the new ESP’s include will push you over. Audit your SPF record before migration. Remove any legacy includes you’re no longer using. If you’re still over the limit, consider SPF flattening (converting includes to direct IP entries) as a temporary measure.
DKIM: Both ESPs need active DKIM signing. Publish the new ESP’s DKIM keys in DNS before you send your first message. After full cutover, keep the old ESP’s DKIM records active for at least two weeks because email forwarding chains and delayed delivery can reference old signatures.
DMARC: If you’re on p=reject, test thoroughly before sending from the new ESP. A misconfigured DKIM setup on the new platform will cause 100% delivery failure for DMARC-enforced domains. For context on how authentication failures cascade, the SFMC infrastructure crisis demonstrated exactly this pattern at scale. Start the new ESP with a test subdomain if possible, verify DMARC alignment passes, then switch to your production sending domain.
IP warming: the real timelines
If your new ESP provides dedicated IPs (which it should, at any meaningful volume), those IPs have no sending reputation. ISPs treat unknown IPs with suspicion.
Week 1: Send to your most engaged subscribers only, specifically those who’ve clicked in the last 30 days. Volume should be 5–15% of your total list. Focus on domains where you have the most subscribers (usually Gmail, Outlook/Hotmail, Yahoo).
Weeks 2–3: Expand to 60-day engaged users. Increase volume by 25–50% per send. Monitor bounce rates and spam placement after every send. If bounce rates exceed 3% or spam placement spikes, slow down.
Weeks 4–6: Expand to 90-day engaged, then full list. By week 6, you should be at full volume on the new IPs. If deliverability metrics are clean, you can accelerate. If not, extend the ramp.
During warming, continue sending your regular campaigns from the old ESP. The warm-up sends should be a subset of your normal sends, not additional messages. For a deeper dive on warming strategy, our IP warm-up guide covers the mechanics in detail. This means coordinating suppression between platforms: subscribers who receive a warming send on the new ESP should be suppressed from the same send on the old ESP.
Automation migration: the in-flight subscriber problem
Every ESP implements flow logic differently. Klaviyo’s conditional splits, SFMC’s Journey Builder decision splits, Customer.io’s workflow rules, and Braze’s Canvas steps all use proprietary logic that doesn’t map directly across platforms. You’re rebuilding automations from scratch on the new platform.
The harder problem is in-flight subscribers. At the moment of cutover, subscribers will be at different stages of active automations, such as being three emails into a seven-email onboarding sequence, 45 minutes into a cart abandonment flow, or midway through a re-engagement series.
Three approaches for handling in-flight subscribers:
Run to completion: Let all active automations finish on the old platform before cutting those flows over to the new one. Cleanest approach, but extends your dual-platform period by weeks.
Hard cutover with entry rules: Stop all flows on the old platform. On the new platform, build entry rules that only capture new triggers. Subscribers who were mid-flow simply stop receiving that sequence. Acceptable for low-stakes flows, risky for revenue-critical ones like cart abandonment.
Mapped re-entry: Export each subscriber’s current position in each flow. On the new platform, build parallel entry points at each stage, and route subscribers to their correct position. Most accurate, but operationally brutal. Only worth it for high-value flows.
Parallel sending and suppression sync
During migration, you’ll be operating two ESPs simultaneously. This creates a real risk of double-sending: the same subscriber receiving the same campaign from both platforms.
Three parallel sending strategies:
List split: Divide your subscriber base. Subscribers A–M send from the new ESP; N–Z from the old. Simple but arbitrary, and prevents A/B testing across the full audience.
Campaign-based split: Migrate specific campaign types first. Transactional emails move first (they’re low-risk and high-volume for IP warming). Promotional campaigns follow. Automation flows migrate last.
Timeline-based cutover: Set a hard date. Everything before that date sends from the old ESP; everything after sends from the new one. Cleanest operationally, but requires confidence in your warming and setup.
Regardless of strategy, you need real-time (or near-real-time) suppression sync between platforms. If a subscriber unsubscribes on the old ESP, that suppression must propagate to the new ESP before the next send. Build this with a webhook or nightly sync, and test it thoroughly before you start parallel operations.
Revenue attribution continuity
Switching ESPs usually means switching UTM structures, tracking pixels, and attribution windows. Your revenue reporting will show a gap during the transition unless you plan for it.
Standardize UTM parameters across both platforms before the migration starts. Use identical utm_source, utm_medium, and utm_campaign conventions. If your old ESP auto-generates UTMs, override them with manual parameters that match the new platform’s structure.
Consider server-side tracking as insurance during cutover. Client-side pixels are vulnerable to the attribution gap when tracking domains change. A server-side event stream (via your CDP or data warehouse) gives you continuity regardless of which ESP is sending.
Hidden costs: the table nobody shows you
Cost category | What vendors say | What actually happens |
Platform overlap | 1 month overlap | 3–4 months at full pricing on both platforms |
Professional services | Optional onboarding | $10K–$75K for mid-market; $100K+ for enterprise |
Integration rewrites | Plug and play APIs | 2–8 weeks of engineering per integration |
Template rebuilds | Import existing HTML | Full rebuild of templates that use platform-specific features |
Training | Self-serve documentation | 2–4 weeks of reduced productivity during team ramp-up |
Revenue impact | Seamless transition | 5–15% revenue dip during warming and cutover period |
Realistic timelines by scale
SMB (under 50K contacts, fewer than 5 automations): 5–6 weeks. Data is simple, automations are few, and IP warming can be compressed.
Mid-market (100K–500K contacts, 10–30 automations): 3–4 months. Data architecture differences are real, automation rebuilds take time, and IP warming can’t be rushed.
Enterprise (500K+ contacts, 30+ automations, multiple business units): 4–6 months minimum. Add additional time for stakeholder alignment, integration rewrites, and phased rollouts across business units.
The teams that migrate successfully aren’t the ones who move fastest. They’re the ones who treat migration as an infrastructure project, complete with a project plan, rollback conditions, and a definition of done that goes beyond “we sent the first email.”
If you’re planning a migration, get in touch to see how we can support you and what we offer to make the transition smoother and more reliable.
