A migration announcement is a funded program

When a company announces a cloud move, a mainframe exit, a replatform or a break-up of the monolith into microservices, the decision is already made. The budget is approved. There's a date.

And nobody runs a migration that size alone. The only question is which outside firms get the work.

Why an announcement means money

Companies don't announce migrations they haven't funded. Saying it in public commits leadership to an outcome investors and customers will check on. So by the time it shows up in a press release or an earnings call, the business case has cleared finance and the board has seen it.

That's a different situation from most signals. With margin pressure or a new leader, you're guessing whether spend will follow. With an announced migration, the spend is the announcement.

And the work is big. Inventory and dependency mapping. Data migration. Code conversion or rewrite. Testing at a scale the internal QA team has never run. Running old and new in parallel for months. Retraining the people who knew the old system and decommissioning it after. No internal team has spare capacity for all of that on top of keeping the business running.

Where they announce it

Earnings calls and investor days are where CEOs and CFOs talk about multi-year programs, often with a cost or timing target. Press releases cover the big ones, especially when a hyperscaler or a large platform vendor is part of the story.

10-Ks mention migrations in the business description and in risk factors. A new paragraph about a mainframe exit or cloud transition is a program that just became real.

Vendor case studies and conference talks are underrated. A cloud provider or platform vendor often features a customer early in a migration. Those talks name the program lead and sometimes the timeline.

And job posts tell you which phase they're in. Posts for cloud architects and migration leads mean planning. Posts for site reliability and FinOps roles mean the move is underway and the bills are arriving.

Before the list is set, or after

There are two ways in, and they depend on timing.

The early way is before the partner list is set. Most companies pick a lead systems integrator, often recommended by the platform vendor, and then add specialists. If you catch the announcement in the first weeks, you can still be one of the specialists. Show up with a sharp view on the part of the program most likely to go wrong. Data migration, testing, security and change management are the usual candidates.

The late way is after the lead partner is in place. This is where most sellers give up, and they shouldn't. Lead partners cover the core migration and leave gaps. They rarely cover the industry-specific application work, the analytics layer that has to be rebuilt on the new platform, or the operating model change that comes after. Those gaps are your work. I've written about getting past this moment in When they say we already have a partner.

What to look for in the language

A named target platform and a date is strong. "We expect to complete our migration to the cloud by the end of next year" is a funded program with a deadline.

A dollar figure or savings target is stronger. Someone signed up for that number and will need help hitting it.

"Exploring" or "evaluating" is weaker. That's a company still building the business case. Useful for nurturing, too early for a specific pitch.

Watch for a mainframe exit in particular. Those programs are long and expensive, and the people who understand the old code are often retiring. That's a capacity gap leadership can't hire its way out of. More on reading that kind of language in Legacy systems in a 10-K are an invitation.

Who sits on it

The CIO or CTO owns the program. A named transformation or migration lead usually runs it day to day, and that person is often your best first contact. They feel every slip. The CFO owns the business case and watches the savings line. Enterprise architects decide what moves first and how.

Business unit leaders feel it too. Their applications are moving, and they'll be blamed for any disruption their customers see.

Say a mid-size property and casualty insurer said on its earnings call that it's moving off its mainframe policy system over the next three years. Here's an opener to the head of the migration program.

Your earnings call put a three-year date on the move off the mainframe policy system. That date is now yours to defend every quarter. My guess is the conversion work is planned and the harder part is testing policy logic nobody's documented, with the people who know it close to retirement. Is that close, or is the risk somewhere else?

The hook names the announcement. The trigger is the date they now own. The hypothesis goes straight at the part that usually breaks. The exit leaves room for them to tell you where it actually hurts.

Timing and stacking

The first 90 days after an announcement are when partners get chosen. After that, you're working the gaps. Both are real opportunities. They need different openers.

Stack it with hiring and leadership changes. A migration announcement plus a new CIO plus job posts for a migration lead is a program staffing up right now. That's the account to work this week. For more on the offer side, see Hypotheses for cloud services.

An announced migration is funded, dated and too big for one firm. Get in early, or find what the lead partner left behind.