A roadmap is a set of commitments, not a picture
Many migration plans are a coloured timeline with five arrows on it. They look convincing in a board pack and fall apart in week three, because they say nothing about who decides to roll back, what a successful cutover looks like, or what happens when a vendor takes six weeks to confirm a licence.
The roadmap we produce is the second stage of our cloud migration service. It consumes the output of the readiness assessment and gives engineering, finance and the business something they can commit to.
What good looks like
- Phase zero is the foundation: the landing zone, connectivity and identity. No workload wave starts before these are ready.
- Waves are small enough to rehearse and recover from.
- Each wave names its owner, its cutover method, its test plan and its rollback trigger.
- Risks are written as sentences with owners, not as traffic lights alone.
- The plan accounts for people: change freezes, holidays, on-call load, training.
How we build the waves
Start from dependency groups
The assessment gives us groups of systems that talk to each other. A wave is one or more of those groups. Splitting a group across waves is allowed, but it means traffic between the old and new locations for a while, and that has latency, bandwidth and security consequences. We make that choice deliberately and plan the network path for it.
Order by learning and by risk
The first wave should be boring on purpose. A internal tool or a test environment lets the team practise replication, cutover, validation and rollback with low stakes. The middle waves carry the bulk of the estate. The final waves hold the systems where the business has the least tolerance, usually the primary transactional databases and the customer-facing platform.
Pick a cutover pattern per group
| Pattern | How it works | Use when |
|---|---|---|
| Replicate and switch | Continuous replication, short final sync, switch traffic | Servers and databases with a small downtime window |
| Parallel run | Both sides serve, compare results, then retire the old | Systems where correctness must be proven |
| Phased traffic shift | Weighted routing moves a percentage at a time | Stateless web tiers, APIs |
| Scheduled downtime | Stop, copy, start | Small or rarely used systems where simplicity wins |
The methods used for servers and databases differ, and the roadmap states which applies to which wave.
Rating risk so it drives action
We score each wave on a short list of factors. A compact way to hold this in version control is a table that sits next to the plan:
wave: 3
workloads: [billing-api, billing-db, invoice-worker]
cutover: replicate-and-switch
window: "Sat 22:00 to Sun 02:00 local"
rollback_trigger: "error rate above agreed threshold for 15 minutes after switch"
decision_maker: "Head of Engineering"
risks:
- id: R1
text: "Replication lag at final sync exceeds window"
likelihood: medium
impact: high
mitigation: "Rehearse final sync twice; pre-seed with full load a week prior"
owner: "DBA lead"
- id: R2
text: "Downstream partner IP allow-list not updated"
likelihood: medium
impact: medium
mitigation: "Partner notified 4 weeks ahead; test from new egress IPs"
owner: "Integration lead"
The format matters less than the habit: every risk has a mitigation, an owner and a point at which it is reviewed. Risks that cannot be mitigated are accepted by a named person, in writing.
Timelines: the work that is easy to forget
A realistic timeline contains items that never appear in a technical plan:
- Security and architecture review of the landing zone before it hosts production.
- Change approval lead times and freeze periods such as financial year end or retail peaks.
- Procurement for circuits and licences, which can run for weeks.
- Rehearsals for each wave, including at least one full rollback.
- A parallel run period before decommissioning the old environment.
- Hypercare after cutover, when the team watches the new platform closely.
We tell clients plainly when a date they want is unrealistic and show what would have to be true for it to hold.
Decisions and trade-offs
Big bang or waves. A single weekend cutover sounds efficient and rarely is. It puts the whole business on one rollback decision. Waves cost more elapsed time and a longer period of hybrid connectivity, but each failure is contained. For tiny estates a single move is reasonable.
Speed or modernisation. Combining the move with a redesign doubles the risk surface. We usually separate them and plan modernisation after stability, as described in the 6Rs classification.
When not to start. If the business cannot name owners for its main applications, or a major release or audit falls in the same window, the right roadmap decision is to wait and fix the preconditions first.
Common failure modes
- Optimistic estimates for testing, which is where waves lose time.
- Roadmaps owned by the consultant rather than the client. We hand ownership to your programme lead from day one.
- No exit criteria for the hybrid period, so old and new run side by side indefinitely and costs double.
- Rollback plans that exist on paper but have never been rehearsed.
Delivery and handover
You receive the roadmap in the tools your team already uses, whether Jira, Azure DevOps Boards or a plain repository of Markdown and YAML. We run a walkthrough with engineering and leadership, record the assumptions, and agree a cadence for reforecasting. Delivery models are described on our engagement models page.
How to tell it is working
Wave one finishes close to its estimate, and the variance is understood. Stakeholders can answer “what is next and what could stop it” without asking us. Rollback criteria have been tested at least once. The hybrid period has an end date that is being met. To talk through your own plan, book a consultation.