Writing a cloud roadmap people will actually follow

Most cloud roadmaps die in the deck they were born in. They get built by people who will not do the work, they run eighteen months, and by month four the business has changed enough that nobody references them again. Here is how to write one that survives contact with a sprint board.

Start with the thing that is actually hurting

Not "digital transformation." Something specific: the bill went up 40% and nobody can say why, releases take three weeks because one person does them by hand, or the auditor asked a question you could not answer.

If you cannot name the pain in one sentence, you are not ready to write a roadmap. You are ready to go talk to the people running the systems.

Write down what you have before you plan what you want

The inventory is the boring half and it is where roadmaps go wrong. For each application you need four facts: who owns it, what it talks to, what happens if it is down for an hour, and whether anyone has touched the code in the past year.

That last one decides more than people expect. An application nobody has changed in two years is not a migration candidate, it is a retirement candidate, and finding three of those is worth more than any rearchitecture.

Sequence by risk, not by ambition

The instinct is to start with the flagship workload because it has the biggest payoff. Start with something smaller that exercises the same path: the same networking, the same identity setup, the same deployment pipeline. You want to discover the surprises on a system where being wrong is survivable.

First 90 days: the parts everything else sits on

Accounts and organisational structure, identity, networking, logging, and a deployment pipeline that one person can run and another can read. Nothing user-facing ships in this window. Say that out loud to stakeholders up front, or month three will feel like failure.

Months 4 to 6: one real workload, end to end

Pick something with genuine users and modest blast radius. Take it all the way: migrated, monitored, on-call, cost-attributed. Half-migrations are the most expensive state to sit in, because you pay for both sides.

Months 7 onward: repeat, and cut

By now the pattern is known and the pace picks up. This is also when you go back and delete the things the first pass left behind. Budget time for it explicitly, because nobody volunteers to remove infrastructure.

Pick metrics you cannot argue with

"Improved agility" is not a metric. Deploys per week, time from merge to production, cost per environment per month, and how long a restore takes are metrics. Record all four before you start, or you will have no way to show the work paid off.

Revisit it quarterly, on purpose

A roadmap is a current best guess, not a contract. Put a recurring hour in the calendar to re-read it and cross things out. The ones that survive three reviews were always the ones that mattered.

If you want a second pair of eyes

We build these with clients as a short engagement: interviews with the people running the systems, an inventory you keep, and a sequenced plan with the first 90 days written in enough detail to start on Monday.