Cloud Readiness Assessment Calculator
Score how ready an estate is for cloud and edge delivery, then estimate migration waves and elapsed months.
Inputs
Unmapped dependencies are the usual cause of a rolled-back wave.
Cacheable traffic can move to a CDN on day one, before anything is re-platformed.
Cloud Readiness Score
52.8/ 100
Grade
D — Weak
Technical Readiness
43.0/ 100
Operational Readiness
63.0/ 100
People Readiness
50.0/ 100
Traffic Movable to the Edge Immediately
55.0%
Migration Waves
10
Estimated Elapsed Time
13.6months
Do This First
Raise infrastructure-as-code coverage and containerise the next wave's workloads
Step by step
Values used
Applications in scope = 120 applications; Applications fully inventoried = 70 %; Applications with mapped dependencies = 55 %; Workloads already containerised = 35 %; Infrastructure defined as code = 45 %; Traffic that is cacheable static content = 55 %; Engineers with hands-on cloud experience = 50 %; Workloads with a cleared compliance path = 65 %; Applications per migration wave = 12 applications; Weeks per wave = 4 weeks
Cloud Readiness Assessment
readiness = technical × 0.35 + operational × 0.40 + people × 0.25; waves = ceil(applications ÷ applications per wave); elapsed months = waves × weeks per wave × friction ÷ 4.345, where friction = 1 + (100 − readiness) ÷ 100.
Cloud Readiness Score
= 52.8 / 100
Grade
= D — Weak
Technical Readiness
= 43.0 / 100
Operational Readiness
= 63.0 / 100
People Readiness
= 50.0 / 100
Traffic Movable to the Edge Immediately
= 55.0
How it works
The three pillars are scored from coverage percentages you can gather from a CMDB, a pipeline audit and a skills survey, with operational readiness weighted highest because an unmapped dependency is what rolls a wave back. The wave count comes from raw application count, and the friction multiplier stretches the schedule as readiness falls — a 50-point estate takes half again as long per wave as a 100-point one. Migration plans slip because the wave schedule was drawn from application count alone, ignoring that low readiness makes every wave slower. The cacheable-traffic figure is the exception worth acting on immediately: putting a CDN in front of static content improves latency and origin load before a single workload is re-platformed.
Formula
Cloud Readiness Assessment
readiness = technical × 0.35 + operational × 0.40 + people × 0.25; waves = ceil(applications ÷ applications per wave); elapsed months = waves × weeks per wave × friction ÷ 4.345, where friction = 1 + (100 − readiness) ÷ 100.
- technical readiness
- Containerisation, infrastructure-as-code and cacheable traffic share
- operational readiness
- Inventory, dependency mapping and a cleared compliance path
- friction
- Schedule multiplier that grows as readiness falls, up to 2× at zero readiness
Frequently Asked Questions
How is Cloud Readiness Assessment calculated?
readiness = technical × 0.35 + operational × 0.40 + people × 0.25; waves = ceil(applications ÷ applications per wave); elapsed months = waves × weeks per wave × friction ÷ 4.345, where friction = 1 + (100 − readiness) ÷ 100. The three pillars are scored from coverage percentages you can gather from a CMDB, a pipeline audit and a skills survey, with operational readiness weighted highest because an unmapped dependency is what rolls a wave back. The wave count comes from raw application count, and the friction multiplier stretches the schedule as readiness falls — a 50-point estate takes half again as long per wave as a 100-point one.
Why does Cloud Readiness Assessment matter?
Migration plans slip because the wave schedule was drawn from application count alone, ignoring that low readiness makes every wave slower. The cacheable-traffic figure is the exception worth acting on immediately: putting a CDN in front of static content improves latency and origin load before a single workload is re-platformed.
What values do I need to enter?
This calculator takes 10 inputs: Applications in scope, Applications fully inventoried, Applications with mapped dependencies, Workloads already containerised, Infrastructure defined as code, Traffic that is cacheable static content, Engineers with hands-on cloud experience, Workloads with a cleared compliance path, Applications per migration wave, Weeks per wave. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.