Switching ESP without losing your lifecycle programs

Picture the renewal meeting. Your ESP is up 40% on last year's price, procurement wants a competitive process, and someone asks how long a move would take. The honest answer in most teams is a shrug, because nobody knows how much of the program exists anywhere except inside the platform. Eighteen months of journey logic, audience rules, and templating sits in a builder with no meaningful export. The renewal gets signed. That's not a technology decision, it's a hostage negotiation.

The thing worth noticing is that the platform didn't trap you. The working practice did. Every time a decision got made in a dropdown instead of written down — why this audience, why 48 hours and not 24, why we suppress this cohort — the only record of that decision became a configuration screen you don't own.

So the useful version of "does this work with other CRMs?" is a different question entirely: if we moved ESP next quarter, what percentage of our lifecycle program would we have to invent again from scratch? A team that can answer that with a number has already done the work in this guide. A team that can't is locked in regardless of which vendor they picked.

Sort a lifecycle stack into two buckets: things that are yours and happen to be stored in the ESP, and things that only exist as an artefact of the ESP. The first bucket travels. The second gets rebuilt by hand, every time, at whatever your team's day rate is.

Read that table as a design brief rather than a warning. Nothing in the bottom four rows can be made portable — that's the deal you accept when you buy an orchestration platform, and it's a fair one. What you control is how much of your program sits in the top half.

The architecture that fixes this has one rule: the ESP holds a build, not the original. The original — the specification your build was made from — lives somewhere you own outright. In practice that's a git repo, though a well-disciplined docs space works too. What matters is that it's outside the platform and version-controlled.

Four things belong in it.

There's a single test for whether you have this. Hand a new starter your documentation, don't give them access to the ESP, and ask them to describe how the win-back program works. If they can't, the program lives in the tool and you don't own it. The Template Brain skill is Orbit's protocol for building exactly this layer, derived from the emails you already send rather than from a vendor's template gallery.

One caveat on the data layer, because it's where teams overspend in response to this anxiety. Keeping the brain outside the ESP does not require buying a CDP. It requires knowing where each attribute is authored. If your events originate in your warehouse or product and are pushed to the ESP, they're yours already. If they originate in the ESP's own computation, they aren't. The CRM vs CDP guide covers when the extra layer earns its licence fee.

Content read APIs exist on every major platform. None of them ships an export that another vendor can import. The pattern is uniform enough to state as a rule: content comes out, structure doesn't, and history never does. The differences are in which specific things bite.

Braze. Template HTML is retrievable and Canvas structure is readable through the API, but what you get back is a description of the graph, not something you can feed into another builder. The bigger cost is templating: Braze Liquid is Shopify Liquid plus Braze-specific personalisation tags and Connected Content, so any template carrying conditional logic is a rewrite rather than a copy-paste. Historical event data is the other trap — Currents, the event stream, is licensed separately, so teams who never bought it have no raw event history to take with them. The Liquid reference shows how much platform-specific syntax accumulates in a mature program.

Klaviyo.Strong ecommerce defaults come at a portability cost, because the most useful fields are ones Klaviyo computes for you — predicted order timing, channel affinity, engagement tiers. Those are outputs of their model, not data you provided, and they don't leave. Flow definitions read out through the API and import nowhere.

HubSpot.Workflows sit on top of CRM objects, so the logic is entangled with an object model — deals, pipelines, lifecycle stages — that no consumer ESP has an equivalent of. Moving out isn't a message migration, it's a data model translation. HubL adds the usual templating rewrite on top.

Mailchimp.The audience-centric model is the sharp edge: the same human in two audiences is two contacts with two subscription states. Every user-centric platform you might move to assumes one person, one record. That reconciliation is manual and it's the step teams underestimate.

Salesforce Marketing Cloud.AMPscript and the Data Extension model are both proprietary. SQL query activities are the one genuinely portable artefact in the stack — the logic survives even though the tables it runs against don't.

The worst time to discover what you can't export is the week you've decided to leave. Run this while the current platform is working fine, because everything it surfaces is worth fixing whether or not you ever move.

Each item on that list improves the program you have today. That's the argument for doing it now: none of the work is speculative insurance, and all of it doubles as an exit route. The ESP Migration skill carries the phased execution plan — audit, parallel build, dual-send warm-up, cutover — for when the decision is already made.

Keeping the brain outside the tool has a real price and it's worth naming: you maintain a specification that partly duplicates a UI someone already built for you. Every program change is two edits instead of one. Left unchecked, the spec drifts from the build, and a spec that lies is worse than no spec, because people trust it.

The recommendation, with the trade-off attached: keep the spec layer deliberately thin. Briefs, audience definitions in plain language, the design system in code, the attribute dictionary. Do not mirror the journey graph — box-by-box documentation of a builder is the part that always rots first, and it's the part a competent operator can reconstruct from a good brief anyway. Then gate it: the spec gets updated as part of shipping the change, not afterwards, or it doesn't hold.

Done that way, the answer to "does it only work with Braze?" stops mattering. The programs are described in your own repo, the templates compile from your own components, the audiences are defined in language any platform can implement, and the ESP is the thing that sends. Which is what it was always meant to be. For choosing the next one, the ESP comparison is the honest read on what each platform suits; the lifecycle audit checklist is where to start if you inherited a stack you didn't build.