Launch Playbook for Platform Migrations

A platform migration is not a feature launch. It is a request — sometimes a demand — that paying customers rebuild a workflow they already trust. The launch is judged less on novelty and more on whether the seventh email about the cutover sounds like it came from the same company as the first.

3.1×

Most migration launches fail the trust test in the first two weeks. Marketing wants the upgrade narrative — "the new platform unlocks…" — and engineering wants the deprecation notice. The PMM sits between them and ships a hybrid that reads as enthusiasm masking a deadline. Customers notice. Renewal conversations get harder.

This playbook treats a migration launch as a sequenced trust exercise. The product is the same company asking the same buyer to do more work. The launch's job is to make that work feel small, predictable, and worth it.

A migration launch is not a story about what's new. It is a story about what stays the same.

What makes migrations different from feature launches

A feature launch tells customers about something they don't have yet. A migration tells customers something they already have is going away. The two require opposite emotional defaults.

Feature launches lean on excitement, scarcity of competitive advantage, and FOMO. Migration launches lean on continuity, predictability, and refusal of surprise. Mix them up — open the announcement with "we're excited to introduce…" — and the customer's first reaction is "what are they hiding?"

The right mental model: a migration is closer to a hospital telling a patient about a procedure than a startup telling a prospect about a product. The information needs to be complete, the timeline needs to be honest, and the person delivering it needs to look like a professional, not a marketer.

The trust mechanic that does the work

Migrations succeed when three things are true throughout the launch window:

1. The customer can predict what happens next.
2. The customer can find the same information in the same place every time they look.
3. The customer can reach a human who knows their account when something breaks.

That third one is the hidden lever. Migration emails read fine in a marketing review and read like spam to a customer who's been on the platform for four years. The fix is not better copy. The fix is making sure the CSM, AE, or support engineer attached to the account is in the loop before the email goes out — and is briefed enough to answer the first inbound call without checking a doc.

The sequence that holds together

A migration launch runs across a defined window — typically sixty to one hundred and twenty days from announcement to forced cutover. The work is to sequence customer communication so that no audience receives information out of order, and no audience is surprised.

The timeline above is illustrative — your specific dates depend on the technical lift, the contract terms, and how disruptive the change is. What matters is that the dates are named publicly, in writing, on day zero, and they don't slip without an explicit, named, customer-facing acknowledgement.

Step-by-step playbook

What goes in the announcement email

The first email is the document the entire launch will be measured against. Six weeks later, when a customer is frustrated, they will scroll back to it and see whether it was honest.

The day-zero announcement email

C—

The thing nobody told me before my first migration: the customer's threshold for marketing language is roughly zero. The first time you write 'we're thrilled' in a deprecation email, half your audience reads it as a tell that you know the news is bad.

The competitive-differentiation angle

Migrations are also the moment competitors call your customers. A clean migration narrative is a competitive moat — a messy one is an opening. PMMs running the launch should brief sales on the two or three competitor talk tracks that will appear in week two and how to respond. The response is rarely "we're better" — it's "here's the timeline, here's the support, and here's why the migration is faster than a re-evaluation."

The customer's calculus during a migration is: stay and do the work, or evaluate alternatives and do more work. Your job is not to convince them you are better than the alternative. Your job is to make the cost of staying visibly, predictably small.

We retained 94% of accounts through a forced migration. The thing that worked was not the product — it was that every customer-facing person told them the same dates in the same words for ninety days.

The download

The template below is the structure we use with clients running platform migrations. Fork it, change the dates, and use it as the working doc for your cross-functional team.

What to do Monday

If a migration is on your roadmap in the next two quarters, schedule a sixty-minute meeting with product, legal, and customer success this week. The agenda is one item: write down the deprecation policy in a single document. Don't draft an email, don't open the brand guidelines, don't think about subject lines. Get the policy right first. The rest of the playbook only works if the foundation it sits on is the same answer six months from now as it is today.