Cloud Strategy Roadmap
Definition
Cloud Strategy Roadmap
A cloud strategy roadmap is your own sequenced plan for a cloud programme: which workloads move, in what order, by when, and against what business case. It decides order and timing for one named company, and nobody else can write it for you.
A roadmap is not a migration strategy. The migration strategy decides what happens to each individual workload — the roadmap decides which of those workloads goes first, and in which quarter.
It is also not a published framework. Most roadmaps borrow their shape from one: Amazon Web Services dates its Cloud Adoption Framework to 22 November 2021 and pitches it as a way to evaluate and improve your cloud readiness.
Policy can set the default before a roadmap starts. The UK government introduced a Cloud First policy in 2013 and its guidance, last updated on 19 June 2023, says public sector bodies should default to Public Cloud first.
Key takeaways
- A cloud strategy roadmap answers order and timing, which is a different job from deciding what happens to each workload.
- The roadmap is company-specific: a published framework can shape it, but cannot write it.
- Each wave on a roadmap carries its own business case, named owner and exit criteria.
- The UK government’s Cloud First policy, introduced in 2013, is an example of a default that a roadmap has to work within.
How it works
A roadmap groups workloads into waves and gives each wave a window, an owner and a reason. Read left to right, it tells you what happens next. Read top to bottom, it tells you why the order is that way.
The columns matter more than the graphics. Most roadmaps that survive contact with a delivery team record the same five things.
| Column | What it records |
|---|---|
| Wave | the group of workloads moving together |
| Window | the quarter or month the wave lands in |
| Owner | the named person accountable for the wave |
| Business case | the saving or capability the wave buys |
| Exit criteria | what proves the wave is actually finished |
A cloud roadmap has to sit underneath the corporate level strategy rather than beside it — if the two disagree, the roadmap is the one that is wrong.
Where a division competes is business level strategy, and that shapes the order. The systems behind a growing product line move before the ones behind a shrinking one.
Every wave needs a business case of its own: what it costs, what it saves, and what it lets the business do next.
The target-state drawing is an enterprise blueprint. The roadmap is the order in which you build towards it, so the two documents only make sense together.
Large programmes are often run as program outsourcing, with a partner holding the plan across waves. The roadmap then becomes the shared artefact both sides argue over.
Waves are grouped by something, and the grouping is the real decision. The common choices are by business unit, by data-centre lease, by technical dependency, or by risk appetite.
Dependencies decide more than preference does. If a reporting system reads from three databases, those three move first or the reporting breaks on cutover night.
A roadmap is also a communications document. Half its value is that a finance director, an engineer and a supplier can all read the same page and argue about the same dates.
Keep the first wave small. Wave one exists to prove the plan works, not to move the hardest system in the building.
Budget follows the waves rather than the calendar year. A roadmap that ignores the financial cycle will have its middle waves quietly deferred by somebody in finance.
Dates slip, and a roadmap that hides that is useless. The useful version carries the slip in the open and re-sequences the waves behind it.
Examples
Roadmaps are usually private documents, so the public examples tend to be the policies and frameworks that constrain them. Two are worth reading before you draft your own, and both are free.
The UK government’s Cloud First policy is the constraint example. Introduced in 2013 and still maintained, it makes public cloud the default for central government and asks bodies choosing otherwise to evidence the decision.
The AWS Cloud Adoption Framework, published on 22 November 2021, is the shape example. It gives you stages and readiness questions, then stops — the sequencing is yours to write.
A retailer exiting a leased data centre in 2026 builds waves around the lease break date. The business case for wave one is simply the rent that stops — nothing more complicated than that.
A manufacturer with plants in three countries sequences by site rather than by system, because the local network work is the long pole in every wave.
A bank does the opposite. Its first wave is a low-risk internal reporting system, chosen because the point of wave one is proving the controls work.
A public sector body starts from the policy default and works backwards, listing only the workloads where staying put can actually be evidenced.
Related terms
These five terms sit around a cloud strategy roadmap. Two describe the strategy layers it has to answer to, one is the target picture it builds toward, one is the delivery discipline, and one is a way of paying for waves.
- Strategy Implementation: the discipline of turning any written plan into delivered work.
- Milestone Based Pricing: a payment structure that pays a partner as each wave completes.
- Corporate Level Strategy: the firm-wide direction a cloud roadmap has to line up behind.
- Business Case Template: the standard format each wave uses to justify its cost.
- Blueprint Enterprise: the target-state architecture the roadmap sequences its way toward.
FAQ
How far ahead should a cloud strategy roadmap look?
Eighteen to twenty-four months is the usual range, with the first two waves detailed and the rest sketched. Anything beyond that tends to be rewritten before you reach it, so detail is wasted effort.
What is the difference between a roadmap and a migration strategy?
The roadmap sets order and timing across the whole programme. The migration strategy decides what happens to each individual application when its turn comes.
Who should own the roadmap?
Someone inside the business, usually a programme director, even when a partner drafts it. Ownership that sits entirely with a vendor tends to drift toward the vendor’s delivery convenience.
Does a roadmap need a business case per wave?
Yes. A wave without its own case is the first thing cut when budgets tighten, because nobody can say what it was buying.
How often should the roadmap change?
Quarterly is a sensible rhythm, with an unscheduled rewrite whenever a wave slips badly.
Explore more cloud and outsourcing definitions at Outsource Accelerator.
Independent
