ESP Migration to Klaviyo, Braze, Iterable or Customer.io

A platform move runs six weeks end to end here, and about half of that happens before a single message leaves the new system. The two things most likely to break in a migration are not the flows. They are the proof of consent attached to each profile and the sending reputation attached to your domain. Both survive if the sequence is right, and both are slow and expensive to rebuild if it is not. What moves first: The consent record. For every profile that means the timestamp, the capture source URL, the IP if you hold it, and the exact wording shown at the point of capture. Article 7(1) of the GDPR puts the burden of demonstrating consent on you, and an export of addresses with a subscribed flag demonstrates nothing. Each platform stores this differently. Braze wants subscription groups rather than a custom attribute, or its own compliance tooling cannot see the state. Customer.io holds unsubscribe on the person object. Iterable separates channels from message types. Mapping this wrong is the failure I find most often, and it stays invisible until an access request arrives. Then the suppression history. Hard bounces, complaints, global unsubscribes and manual blocks are imported before the first send, not after. Most migrations carry the active list and leave the suppression file behind. Mailing a two-year-old complaint in week one is how a new subdomain dies. Authentication and warmup: A new sending subdomain, SPF, DKIM at 2048-bit, and a DMARC record that starts at p=none and moves to quarantine only after two weeks of clean aggregate reports. One-click unsubscribe headers per RFC 8058, required of bulk senders by Gmail and Yahoo since February 2024. Volume ramps across four weeks, opening with profiles that engaged in the last 30 days and doubling every second day rather than every day, with Google Postmaster Tools and Microsoft SNDS read each morning. A dedicated IP earns its place above roughly 100,000 sends a month on a steady weekly cadence. Below that a shared pool will treat you better than your own volume can. The event schema: Event names and properties are settled before flows are rebuilt, because renaming them a year later means losing the history behind them. The set differs by account. A beauty brand needs product, variant, shade and unit size on the purchase event. A fintech needs account created, identity verification submitted and first funded as distinct events carrying reason codes. A nonprofit needs one-off and recurring gifts separated at the event rather than inferred later. Identity resolution is settled at the same time: the largest source of duplicate profiles I find is an external ID assigned at web signup and again at app install. Cutover: Two weeks of parallel running, old platform still sending while the new one takes a growing share, with a documented rollback point held until the final week. Not included: Creative rebuilds, template coding and copy are separate engagements. SMS and push are not built inside a migration. I do not work in Salesforce Marketing Cloud or Adobe Campaign, in either direction. And a list you cannot evidence consent for does not move. It gets a re-permission campaign from the old platform, or it stays behind. Who this is not for: Anyone who needs the cutover finished in under a month, or landing inside a peak trading quarter. Anyone whose reason for moving is the licence fee alone. How it is judged: Seed-list inbox placement before and after, delivered and complaint rates at Postmaster, and revenue per recipient on the engaged band held flat or better across the cutover, compared against both the four preceding weeks and the same weeks a year earlier.