Migrating engagement platforms without a dark month

Every platform migration plan we are shown has the same shape. Eight weeks of build, a cut-over weekend, then a few weeks described as stabilisation. Somewhere in that period, usually without anyone writing it down, the programme stops sending.

The gap gets called a quiet phase. In practice it is a month in which nobody receives a welcome journey, no baskets are recovered, and the reactivation series does not run. The revenue does not come back later, because the customers it would have reached moved on.

A dark month is a planning decision rather than a technical requirement. Nothing about replacing an engagement platform requires you to stop talking to customers, provided the old system stays switched on while the new one earns its traffic.

The dark month comes from cutting over all at once

Big-bang cut-over is attractive because it is simple to describe and easy to put on a plan. One date, one switch, one set of approvals.

It also concentrates every risk on a single weekend. Templates, data feeds, journey logic, sending reputation, integrations and reporting all change at once, and when something misbehaves on the Monday there is no way to tell which change caused it.

The response is always the same: pause sends until it is sorted. That pause is the dark month, and it is produced by the plan, not by the platform.

The alternative is to treat migration as a traffic-shifting exercise. Both systems run. Programmes move over one at a time, in an order you choose. The old platform keeps sending everything that has not moved yet, and stays available as a rollback until the last programme is across.

Run both, and move one programme at a time

Parallel running costs a few weeks of double licensing. That is almost always cheaper than the sends you would otherwise lose, and the comparison is worth putting in the business case explicitly.

Move programmes in order of risk and volume, lowest first:

1. A single low-volume triggered message, such as a review request, to prove the end-to-end path.
2. Transactional and service messages, if they are in scope, since the content is stable and the audiences are small per send.
3. Triggered lifecycle journeys: welcome, basket, replenishment. These carry most of the value and benefit from careful attention.
4. Segmented broadcasts to engaged recipients.
5. Full-file broadcasts, last, once the sending reputation on the new platform is established.

One rule holds the whole thing together: a programme lives in exactly one platform at any moment. Never run the same journey in both, because the suppression logic in each system cannot see the other, and customers receive everything twice.

Turn the old version off at the moment the new one goes live, in the same working session, with both people in the same call.

Warm the new sending identity with traffic you already trust

New sending infrastructure has no reputation. Mailbox providers judge it on early behaviour, and the fastest way to fail is to send a large promotional broadcast to a cold list on day one.

IP warming is why the migration order above starts with triggered messages. Transactional and lifecycle traffic has excellent engagement, small daily volumes and predictable patterns, which is exactly what a new sending identity needs to establish itself.

The practice we follow:

• Start with your most engaged recipients, defined by opens and clicks in the last thirty days, and widen gradually.
• Increase daily volume in steps, holding at each step long enough to see the result rather than pushing through a schedule.
• Watch delivery by mailbox provider, not as a blended figure. Providers respond to new senders differently and at different speeds.
• Keep authentication records for the new platform published and verified before the first send, including the return-path domain.
• Stop increasing volume the moment complaint or bounce rates move, and hold until they settle.

Plan a realistic number of weeks, and do not let a launch date compress it. Reputation damage during warming takes far longer to repair than the schedule you were protecting.

The choice between a new domain and your existing sending domain deserves an explicit decision. Keeping the domain and changing the underlying infrastructure carries over some history, but it also means a problem during warming touches mail you already depend on. Whichever you choose, write down the reason, because someone will ask in six months.

Port the data model, not the campaign library

The instinct is to recreate what exists. That is how programmes arrive on a new platform carrying the same two hundred templates, forty of which nobody has sent in two years.

Migration is the one moment when deleting things is easy to approve. Inventory every message, mark each keep, rebuild or retire, and expect a third of the library to be retirable. Rebuild only what earns its place.

Data is the opposite: it needs more care than people budget for, not less. Start from the single customer view rather than from the old platform's field list, because that list encodes years of workarounds.

Write a data contract for the new platform before any field is mapped. Field name, type, allowed values, refresh frequency, owner, and the source system. Anything without an owner does not get created.

Feed it the way you feed everything else. If profile and audience data already arrives through reverse ETL from the warehouse, point that pipeline at the new destination and keep a single definition of each attribute. Migrations that let the new platform compute its own version of a segment produce two numbers for the same thing within a quarter.

Where there is no warehouse to work from, the approach in building a single customer view without a CDP still gives you one place to define identity before the mapping starts.

Decide the cut-over rules and the rollback in advance

Each programme move needs three things agreed in writing beforehand. What must be true to go live. What you will watch for the first seventy-two hours. And what would make you switch back.

Rollback is the one people skip, usually because the old platform is still running and everyone assumes reverting is obvious. It is not obvious at three in the afternoon when a journey is misfiring and two teams disagree about whether it is serious.

Name the specific numbers. Delivery rate below a stated floor, complaint rate above a stated ceiling, or a volume that differs from forecast by more than an agreed margin. Name the person who calls it, and keep the old journey in a paused state rather than deleted until the new one has run for a full cycle.

Then keep the deliverability dashboard from the old platform alive for a quarter after the last programme moves. It is the only baseline you will have when someone asks whether things got better or worse.