We swapped the email platform under three live businesses and not one of them went dark. What saved the migration was a decision made long before it: the CRM was never wired to the email tool at all.
Your email service provider does not sit by itself. It is fed by your CRM, your checkout, and your product events, and it feeds engagement data back the other way.
So the moment you decide to replace it, the hard part is rarely choosing the new platform. The pain is in the connections you have to rip out and rebuild by hand.
At Leverage Companies I hit exactly that. I ran marketing across three brands that all sold by phone and lived in Salesforce: Brick City Capital in lending, Leverage Homes in wholesaling, and Deals & Dollars in education.
The email platform underneath all of it had to change while every one of those businesses kept selling. No maintenance window, no pause.
Why we changed platforms
The switch came down to fit. Mailchimp is a strong broadcast tool, and against a Salesforce-driven sales process it was the wrong engine for full-funnel attribution. Iterable modeled the lifecycle and the events the way our funnel actually worked, so we moved.
Both are capable platforms, and the choice was matching the engine to the machine we were building. The interesting problem is mechanical: how do you change one platform without the change reaching the business running on top of it?
What made the move survivable was a decision I had made long before this migration was on the table. When I first connected the brands to email, I did not integrate the CRM straight into the platform. I built a translation layer in between.
Every event that mattered, a new lead, a stage change, a purchase, a consent update, got translated once into a single standard internal format. I called it a canonical envelope: a platform-neutral description of what happened.
On the far side of that envelope sat small per-platform adapters, and each adapter knew how to speak to exactly one downstream tool and nothing else.
The CRM talked to the envelope. The envelope talked to the adapters. The adapters talked to the platforms.
Integrate the platform once and you marry it. Integrate a canonical envelope and every platform becomes an adapter you can swap.
The new platform disagreed about who a person was
A clean architecture does not spare you the specifics of the new tool, and this one had three that mattered.
The first was identity. Its data model treated the email address as the natural key for a profile, and where a business runs on phone calls, an email address is a weak name for a person. The same buyer arrives under two addresses; two people in a household share one.
So profiles were anchored on a stable internal ID instead, with email demoted to an attribute. The real work of deciding who counts as one human lived upstream, in the identity layer I describe in the CDP I built myself.
The second was status. I wanted per-recipient delivery and engagement events flowing back so the CRM knew what each contact had received.
The platform offered no per-recipient webhook for that, so status had to be reconciled a different way, pulled and matched on a schedule rather than pushed one message at a time. Same outcome, different plumbing, and worth knowing before you promise anyone real-time.
The third was the loop. A two-way sync that writes to the CRM and also listens to the CRM will, if you let it, hear its own writes and respond to them without end.
So every write the sync made carried a marker that said this change came from me, ignore it on the way back. Leave that out and the system spends all day arguing with itself.
Run both platforms at once, move one brand at a time
With the plumbing understood, the migration came down to refusing to do it all at once. A hard cutover, old platform dark on Friday and the new one carrying everything on Monday, is the version that ends careers.
Instead both platforms ran live in parallel. The envelope fanned every event to both, so the new platform was already receiving traffic and building genuine sending history while the old one still carried the actual mail.
The anti-abuse industry group M3AAWG advises the same patience in its sending domains best practices, which say a full cutover to a new ESP should only be completed once sending cadence and volume with the new vendor are consistent and sustained.
Then we cut over one brand at a time. Brick City moved first and warmed up on the new platform while the others stayed where they were.
We watched deliverability, engagement, and the sync for that one brand until it was thoroughly boring, and only then moved the next. The old platform stayed switched on the entire time.
A hard cutover is a bet you cannot unwind. Keep the old platform live and it becomes the rollback that makes the whole move safe.
Deliverability got better on fewer sends
The surprise came after the move. On the new platform we sent less mail and reached more inboxes. That is not a paradox once you stop treating volume as the goal.
Inbox placement is a reputation score the mailbox providers keep on you. Google's own guidelines for bulk senders put a number on it, requiring anyone who sends more than 5,000 messages a day to Gmail to keep the spam rate reported in Postmaster Tools below 0.3%.
Three things move that score far more than size does.
First, split your sending subdomains by the job the mail does: one lane for marketing, one for the transactional messages a person is actively waiting on, one for the personal notes a loan officer sends. Let a promotional blast share a lane with a receipt and it drags the receipt down with it.
Yahoo publishes that separation as a rule in its sender best practices, which tell senders not to send bulk or marketing email from the same IPs used for user mail, transactional mail, and alerts.
Second, warm the sending address up with discipline, ramping slowly so the providers meet you as a steady sender building a track record.
Third, gate the list on hygiene, verifying addresses before they are ever mailed so bounces and complaints stay low from the start.
None of that requires more email. It requires the list to stay something people want, which is the same discipline the whole program in rebuilding email into a real channel depends on.
The list got smaller and the inbox opened up. Mailbox providers reward the reputation you build, and reputation answers to structure long before size.
What the envelope bought
The migration ran without a single brand going dark, and the businesses on top of it never felt the platform beneath them change.
That is the payoff of building the integration as an envelope with adapters instead of a direct marriage to one vendor. The email platform became a component you can replace, the way you would replace any other component, without opening up the machine around it.
This is the plumbing under the program I keep pointing operators toward. The identity layer decides who each person is. The lifecycle program decides what they receive.
Both plug into the growth operating system as the owned-channel engine, and the envelope is the joint that lets you change any one of them without breaking the others.
How to make your own ESP swappable
- Put a translation layer between your CRM and your email platform, so every event is described once in a neutral format and adapters handle each tool.
- Confirm how the new platform keys identity. If it leans on the email address, anchor on a stable ID of your own and treat email as an attribute.
- Check whether you get per-recipient status events or have to reconcile on a schedule, before you promise anyone real-time reporting.
- Mark every write your sync makes so the sync never reacts to its own changes and spins into a loop.
- Run both platforms live and cut over one brand or segment at a time, keeping the old one switched on as your rollback.
- Separate sending subdomains by mail type, warm the IP up slowly, and gate the list on verified addresses.
If you are staring down a platform switch and dreading the rewire, this is the kind of migration I plan and run. Let's talk.