Launch Playbook for Platform Migrations

A platform migration launch is the only kind of launch where your most engaged customers are the ones most likely to churn. Treat it like a feature announcement and you'll lose accounts that have been with you for four years. Treat it like a trust event — sequenced, evidenced, with a credible rollback story — and you'll come out the other side with retention intact and a cleaner architecture to sell against.

By "platform migration" we mean the class of launches where existing customers must move from one technical foundation to another: a v1-to-v2 rebuild, a database engine swap that changes query behavior, a deprecation of a legacy API, a re-platforming after an acquisition, or a shift from self-hosted to multi-tenant. Not a UI refresh. Not a feature flag. The kind of launch where someone has to schedule a maintenance window.

The buyer's first question isn't "what's new." It's "what breaks, and when."

What makes migration launches different

The standard launch playbook — tease, announce, amplify, sustain — assumes a net-new audience that wants a reason to care. Migration launches invert that. Your audience already cares, has built workflows on top of the old thing, and is reading every word for evidence that you understand what you're about to do to their Tuesday.

Three structural differences shape everything downstream:

1. The primary audience is internal to your install base. Net-new prospects are a distant second concern. Get the install base wrong and the prospects read the support forum and disappear.
2. The risk story is the value story. "What we did to make this safe" is more persuasive than "what's better now." Buyers extrapolate: a vendor careless with migrations will be careless with everything.
3. The clock is asymmetric. You have months of internal lead time. Customers have whatever notice you give them, plus the time their internal change-management process needs. Announce too late and you're the vendor that broke their roadmap.

62%

The sequence

A migration launch runs longer than a feature launch and front-loads the trust-building work. The shape below assumes a six-month window from internal lock-in to general migration availability. Compress or stretch proportionally — the order matters more than the absolute durations.

The most common mistake is collapsing T-180 through T-90 into a single "we'll announce when we're ready" window. Customers read the silence as either incompetence or bad news being prepared. Pre-announcing under NDA to a council of ten is cheap insurance — they will catch the timeline assumptions you missed, and they become your reference customers when the public announcement lands.

Step-by-step playbook

What to put in the announcement post

The structure of the public announcement is itself a trust signal. Buyers and customers can tell within a paragraph whether you've thought about them or about your own roadmap.

What customers actually read for

In post-migration interviews across roughly forty B2B SaaS accounts, the customers who reported the highest trust in the vendor afterward consistently cited the same handful of signals — none of which were the new platform's headline features.

DO

I knew it was going to be fine when their announcement post had a section called "what to do if the migration fails." Every other vendor pretends that won't happen. The fact that they wrote down the answer meant they'd already thought about it.

Trust signals customers actually look for

Message consistency across the migration window

A migration launch runs through more channels and over more time than a feature launch. Drift is inevitable unless you actively manage it. The product blog says one timeline, the support docs say another, the AE on a renewal call quotes a third — and the customer's faith in the migration evaporates.

Three message-consistency disciplines worth enforcing:

• One source of truth for the timeline. A single internal page with the dates, the open questions, and the last-updated stamp. Every customer-facing channel pulls from it. When the timeline changes, that page changes first and everything else follows within 24 hours.
• A weekly migration FAQ update. During the active window, the FAQ is a living document. New questions surface in support tickets, get added within days, and the update goes to the account team before customers find them on their own.
• An "ask me anything" with the engineering lead. Halfway through the migration window, host a 45-minute live session with the head of platform engineering. No prepared deck — just questions from customers. The vendors who do this report measurably higher post-migration NPS than the ones who don't.

The single thing that saved the migration was making our head of engineering visible. Customers stopped escalating to me because they trusted the person actually doing the work.

The template

The migration launch template below packages this playbook into a working artifact: a timeline worksheet, an announcement-post outline, an account risk-scoring template, and a stuck-accounts standup agenda. Copy it, fill it for your specific migration, and circulate it to your launch team before you write any external copy.

What to do Monday

Pull your install base into a spreadsheet and score every account on five dimensions: integration depth, contract size, renewal date, custom configuration count, and CSM relationship strength. The 15-20% in the top quartile are your customer council and your assisted-migration cohort. Brief them under NDA two months before anyone else hears a word. Their feedback will shape the announcement, the tooling, and the timeline — and they'll be the reference customers you point to when the public announcement lands. Everything else in the playbook follows from getting that list right.