A cloud readiness assessment is an honest inventory of whether your applications, data, team, and budget are actually prepared to move to the cloud - and most of it you can do yourself in an afternoon, before anyone sells you a workshop. The version vendors offer is real work, but it is also a lead-generation funnel, and the checklist underneath it is not a secret. It is five questions: which apps move well, where the data lives and what it costs to move, whether your team can operate what they build, what the real bill looks like, and which security and compliance constraints are non-negotiable. Answer those honestly and you have done the assessment.
There is nothing wrong with hiring help for a big migration. But walking in having already done the self-assessment means you are buying execution, not paying someone to tell you things you could have written down for free.
Table of contents
- What the assessment is actually for
- Application readiness: what moves, what fights back
- Data gravity and the cost of moving it
- The two things vendors underplay: cost and skills
- Turning the assessment into a decision
- How this fits the rest of the stack
- FAQ
What the assessment is actually for
The point of a readiness assessment is not to produce a glossy report. It is to catch, before you commit, the things that turn a migration into a disaster:
- An app that assumes a fixed local disk and quietly breaks when the machine is ephemeral.
- A database whose egress cost to move dwarfs a year of hosting.
- A team that can write the app but has never operated it in production without a hosting provider’s hand-holding.
- A compliance requirement discovered after the data is already in the wrong region.
Every one of those is cheap to find on paper and expensive to find in production. The assessment is a forcing function to look before you leap. That is the whole value - not the framework, not the maturity model, just the discipline of asking the uncomfortable questions early.
Application readiness: what moves, what fights back
Go through your applications and sort them honestly into three buckets:
- Lift-and-shift ready: stateless, config-driven, no assumptions about the machine underneath. These move with minimal changes.
- Needs work: hardcoded paths, local file storage, in-memory sessions, licences pinned to a MAC address. Movable, but only after refactoring.
- Leave or rebuild: legacy apps so entangled with their current environment that rehosting them is more expensive than replacing them.
The useful output is not a percentage score; it is a list. For each app in the middle bucket, write the specific thing that has to change. “Move sessions to a shared store” and “stop writing uploads to local disk” are the real work items. A maturity score of 3.2 out of 5 tells you nothing you can act on.
Data gravity and the cost of moving it
Data is the part that quietly decides the timeline and the bill. Two questions:
- How much is there, and how do you move it? Terabytes over the public internet take real time and real egress fees from your current provider. Sometimes physical transfer or a staged migration beats a copy-over-the-wire.
- What has to stay where? Data-residency rules (GDPR, healthcare, financial regulation) can force specific regions and rule out others entirely. This is a hard constraint, not a preference.
Data also has gravity: the apps want to be near it, so moving the data often forces the order you move everything else. Map the datastores, their sizes, their residency constraints, and their egress cost first - they will dictate more of the plan than the compute ever does.
The two things vendors underplay: cost and skills
The self-assessment vendors are least motivated to push you on are the two that matter most.
Cost. The cloud is not automatically cheaper. It is cheaper for variable, spiky workloads and often more expensive for steady, predictable ones that a fixed server handles fine. Model your real monthly bill - compute, storage, egress, managed services, support - against what you pay now. If the number is worse, the cloud might still be right for other reasons, but decide that with eyes open.
Skills. Someone has to operate what you deploy - monitoring, incidents, patching, cost control. If your team has never done that without a managed host, that gap is a real project cost. Honest readiness includes “can we run this at 3am”, not just “can we deploy it once”.
Turning the assessment into a decision
The output of all this should be a single, defensible decision with the reasoning attached - not a maturity score. It looks like:
- These apps move now (the ready bucket), in this order (driven by data gravity).
- These need this specific work first (the middle bucket, with the work named).
- These stay or get replaced (the hard bucket).
- The projected cost is X, versus Y today, and here is why the difference is worth it (or why we are doing it anyway).
- These constraints are fixed: regions, compliance, data residency.
That is a plan an engineer can execute and a finance person can sign off. And the single most clarifying step in the whole exercise is putting a real number on the projected bill - because a migration justified on “the cloud is cheaper” that turns out more expensive is the one everyone regrets.
How this fits the rest of the stack
Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.
Useful related references:
- AWS vs Azure vs Google Cloud: Pricing, Services, and the Right Defaults
- AWS vs Google Cloud for Startups: The Bill and the Boring Stuff
- AWS vs Google Cloud for Startups: A Friction-First Comparison
- Getting started with RunxBuild
FAQ
What is a cloud readiness assessment?
It is a structured evaluation of whether your applications, data, team, and budget are prepared to move to the cloud. It sorts apps by how easily they migrate, maps data and its residency constraints, projects the real cost, and identifies skills or compliance gaps - so you find the expensive problems on paper rather than in production.
Can I do a cloud readiness assessment myself?
Yes, and you should do a first pass yourself. The core is five questions - which apps move well, where the data lives and what it costs to move, the projected bill, whether your team can operate it, and which compliance constraints are fixed. Answering those honestly is most of the value; hire help for execution, not for the questions.
What should a cloud readiness assessment include?
Application inventory sorted by migration difficulty, a data map with sizes and residency rules, a projected cost model against current spend, an honest skills-gap review of who will operate the platform, and the fixed security and compliance constraints. The output should be an actionable plan, not a maturity score.
Is moving to the cloud always cheaper?
No. The cloud is usually cheaper for variable, spiky workloads and can be more expensive for steady, predictable ones that a fixed server handles well. Model your real monthly cost - compute, storage, egress, managed services - against current spend before assuming savings, and decide with the actual numbers in front of you.
What is data gravity in a cloud migration?
Data gravity is the tendency for applications and services to want to sit close to the data they use, because moving large datasets is slow and costly. It often dictates the order of a migration - you move the data first (or last), and the apps follow it - and residency rules can force specific regions.