Hypotheses for modernization services

Modernization buyers don't suffer from old technology. They suffer from what old technology does to their plans. Write your hypothesis about the plan, and you'll sound like someone who's been through one.

"Your legacy systems are holding you back" is the opener every modernization firm sends. It's true and useless. The buyer knows. That's why they're modernizing.

Where the misery actually lives

The pain in modernization almost never sits in the code. It sits in the people and the plan around the code.

The plan was scoped before the current leader arrived, and it's bigger than the budget. The team that knows the old system is retiring or leaving. Nobody documented what the old system actually does, so every requirement turns into an archaeology dig. The business won't freeze changes, so the target keeps moving. Running two systems side by side costs more than anyone planned for.

Those are the hypotheses that land. They're specific, they're common and a buyer living through one will recognize it in a line.

Pick the hypothesis from the signals

The research tells you which misery to guess.

A new CIO plus a modernization program named in the 10-K points to the inherited plan. They didn't scope it, and now they own it.

A cluster of job posts for engineers who know the old platform points to knowledge loss. Nobody hires for a dying language when the people who know it are staying.

A cluster of posts for the new platform plus a few for the old one points to the parallel run. They're staffing both sides at once.

A restructuring or cost program points to budget pressure on a program that was approved in better times.

Match the signal to the misery. Don't guess at random. More on reading those signals in legacy systems in a 10-K are an invitation.

Write for the seat

The same program hurts differently depending on who you write to.

The CIO feels the plan and the board. They'll be asked about the date and the budget.

The champion, often a director running the program day to day, feels the tradeoffs. Scope versus speed. Which business unit goes first.

The technical lead feels the system. The undocumented integrations, the data migration, the cutover weekend.

Write each of them their own hypothesis. Same program, three different miseries.

An example

Say a regional insurer's 10-K describes a multi-year program to replace its policy administration system, and the company has posted four roles for engineers with experience on the old mainframe platform.

The 10-K commits to replacing the policy administration system, and your team just posted four roles for engineers on the current mainframe platform. Hiring for the old system in the middle of a replacement usually means the people who know it best are leaving before it's off. My guess is the migration timeline depends on knowledge that's walking out the door. Is that close, or is the harder problem somewhere else?

That's written for the program director. It names two public facts, connects them in a way most vendors wouldn't and guesses a problem that keeps program directors up at night.

Make it easy to be wrong

Modernization buyers love to correct vendors. They've heard every pitch, and they know their program better than you.

That's your advantage. A precise wrong guess gets a reply. "Actually, the mainframe team is staying. The problem is the business won't stop requesting changes to the old system." Now you know the real misery, and you got it from the person who owns it.

A vague guess gets nothing. "Is modernization a priority?" can't be wrong, so nobody bothers to answer. The misery hypothesis, explained goes deeper on why precision earns replies.

What to leave out

Leave out the target architecture. Cloud native, microservices, event driven. The buyer has picked a direction or will pick one with their own architects.

Leave out timelines and promises. "We can cut your migration time in half" is a claim nobody believes in a first message.

And leave out the methodology slide. Every modernization firm has a five-phase approach with a clever name. Nobody's reading it.

Guess the misery around the program, not the technology inside it, and modernization buyers will tell you what's really going on.