Communication Plans for Major System Migrations

Migration communication gets planned like release communication with longer lead times. It isn't the same problem. A release is an event you announce; a migration is a period you have to narrate while people live inside it.

Aldermoor Health ran the old and new billing systems side by side for nine weeks. The comms plan was thorough by release standards: pre-announcement, integrator notice, support brief, status page, a post-cutover summary.

Every message was about the cutover date.

Not one of them answered the question customers actually had for nine weeks, which was am I on the old one or the new one right now? Support fielded four hundred tickets that were all a version of that question. Finance closed two months against a mixed population without knowing it was mixed. The migration itself went fine.

A release has a moment; a migration has a period

The distinction decides what you have to write, and it's why the release communication plan is necessary here but not sufficient.

A release is a point event. Before it, one thing is true; after, another. Your job is to announce it, cover the failure cases, and confirm completion.

A migration has a coexistence window — days or months in which both systems are live and the population is split. During that window there is no single true statement about the system. "The new billing system rounds to the nearest penny" is true for some customers and false for others, and which is which changes weekly.

That produces a class of message a release never needs: stateful communication, where the content depends on which side the reader is on. It's also the class most plans skip entirely, because the release template has no row for it.

The test you can run: for your migration, write the sentence that describes the system's behaviour today. If you can't write one that's true for everybody, you're in a coexistence window and you need messages that say which group the reader is in.

What the window forces you to say

Four questions that a release never has to answer and a migration must, continuously:

The question	Why it only appears in a migration	If you don't answer it
Which system am I on?	The population is split, and people can't tell from the outside	Every support ticket starts with twenty minutes of diagnosis
What's different for me, specifically?	The delta depends on which side you're on	People report correct new behaviour as bugs
When do I move, and can I choose?	Migration is a schedule, not an event	Everyone assumes they're last, and nobody prepares
When does the old one stop?	The old system's death date is the only real deadline	The long tail never moves, and you run two systems forever

The first is the one that costs the most and is cheapest to fix — usually a line in the product itself, or in the account page, rather than an email at all. Aldermoor added a single sentence to the invoice header saying which engine had produced it, and support volume on that question went to near zero.

The fourth is the one that gets deferred, because naming a shutoff date makes it real. It's also the only message that causes anybody to act.

The test: ask your support team what the most common migration question is. If it's "which one am I on", the answer belongs in the product, not in a broadcast.

The deadline message is sent more than once, and it escalates

A release announcement is sent once. A migration deadline that requires customer action has to be sent repeatedly, and each send has to be more specific than the last — because the population that hasn't acted is, by definition, the population the previous message didn't reach.

What worked at Aldermoor, for the integrators who had to change code:

1. T-90: the general notice. Everyone gets it. Names the change, names the shutoff date. Perhaps a third of the population acts on this one, and they're the ones who'd have been fine anyway.

2. T-45: the segmented notice. Sent only to accounts still calling the old endpoint, and it says so — our logs show your integration made 14,000 calls to the old API last week. Specificity is what converts this from noise into a task, and it's only possible because someone ran the query.

3. T-14: the named notice. To a person, not an address. From their account contact where one exists. Fewer than fifty of these, and they get replies.

4. T-0 and after: the enforcement message. What actually happened, what to do now.

Notice that the messages get narrower and more human as the deadline approaches, which is the inverse of how comms usually scale. Broadcasting harder at the end reaches the people who already acted and annoys them.

The test: for your last deadline-driven notice, check whether it was segmented by who had actually acted. An unsegmented reminder is indistinguishable from the first message, so it gets read the same way — which is to say, not.

The last five per cent are named humans

Every migration has a tail: the accounts that don't move no matter how many emails you send. Treating them as an audience is the mistake — they're a list of individuals with individual reasons, and the reasons are usually neither ignorance nor obstinacy.

Aldermoor's final eleven, after nine weeks:

• Four had nobody assigned. The integration's owner had left, and no email was going anywhere a human read.

• Three had a genuine technical blocker — a dependency of their own with a longer timeline.

• Two were waiting because they believed the date would slip, having watched it slip before.

• One had already migrated and was calling the old endpoint from a forgotten test job.

• One never responded and was cut off on the date, which was the correct outcome.

Only the last is a communication failure. The other ten needed different things: an owner found, a date negotiated, a credible commitment, or a query showing them what was still calling. None of that is an email campaign.

The test: take the accounts that haven't moved and ask, per account, why not. If the answer for any of them is "we don't know", that's the finding — you don't have a communication problem there, you have a missing stakeholder.

When it's a release, not a migration

Not everything called a migration has a coexistence window, and running this machinery when there isn't one is how the plan gets a reputation:

• An atomic cutover with no dual-run. Everyone moves in the same window. That's a release with a big blast radius — use the release plan and put the effort into the rollback instead.

• The change is invisible to the user. Swapping a datastore behind an unchanged API needs operational comms, not customer comms.

• The population is one team. Coexistence between two internal groups is a conversation and a shared channel.

• The old system dies the same day. No tail, no deadline campaign, no segmentation. One notice and a status page.

Where the full treatment always earns its cost: anything where customers must take an action, anything with a dual-run longer than a fortnight, and anything where money is calculated differently on the two sides.

The test: does anyone have to do something, and can two people get different answers from the system on the same day? Two yeses means you're running a migration. One or none means you're running a release.

What to change this week

Don't extend the release plan. Add the window.

Write the four coexistence answers for your migration — which system am I on, what's different for me, when do I move, when does the old one stop — and find a home for each that isn't an email. The first one usually belongs in the product; the fourth usually needs a decision nobody has made yet.

Then run the query that segments your deadline notice. The list of who hasn't acted is worth more than any amount of rewriting the message, and it's the same list that tells you whether the tail is eleven people or a thousand.

Aldermoor's next migration ran seven weeks with a dual-run and generated thirty-one support tickets. The invoice header said which engine produced it. The shutoff date was in the first message and never moved.