Cloud Readiness: The Assessment to Run Before You Migrate

Migrations fail in the assessment, not the cutover

The organizations that end up over budget, behind schedule, or quietly repatriating workloads a year later rarely made a bad cutover decision. They made a bad assumption at the start — that they knew their environment, that lift and shift would just work, that the cloud bill would land near the data center bill. A cloud readiness assessment exists to replace those assumptions with evidence before anyone provisions a single resource.

Done properly, an assessment is not a slide deck that says "yes, migrate." It is a sober inventory of what you run, what depends on what, what it costs today, and which workloads are genuinely ready to move versus which ones will punish you for moving them early. This is the work we do for clients before touching cloud infrastructure, and it is the difference between a migration that lands on plan and one that becomes a standing line item in every status meeting.

What a readiness assessment actually covers

A credible assessment examines seven dimensions. Skip any of them and you have a gap that surfaces later as an outage, a surprise invoice, or a compliance finding.

• Application portfolio and dependencies. Build the inventory from evidence, not the CMDB nobody has updated since 2019. Use agent-based or network-flow discovery over at least two to four weeks to catch month-end and quarterly jobs. The output is a map of which systems talk to which, so you can group workloads that must move together and spot the database, license server, or auth endpoint a "simple" app secretly depends on.
• Data gravity. Large, active datasets pull their consumers toward them. Moving the application while the data stays behind (or the reverse) turns every request into a cross-network round trip. Measure dataset size, change rate, and read/write locality so you know what has to move together and how long the initial transfer will realistically take over your actual bandwidth.
• Licensing. Bring-your-own-license terms, core-based pricing, and virtualization restrictions can make the same software cost dramatically more in a public cloud than on owned hardware. Audit every commercial license for cloud eligibility before you assume it travels.
• Compliance and data residency. Know which workloads carry regulated data — PCI, HIPAA, CJIS, or contractual data-residency clauses — and what that dictates about region, tenancy, and controls. This shapes design, so it belongs in the assessment, not the audit that follows go-live.
• Network. Latency between users, applications, and data determines whether an architecture is viable at all. Capture available bandwidth, round-trip times, and the cost of the interconnect you will need. A workload that assumes sub-millisecond storage latency does not survive a naive move.
• Skills. Cloud operations demand fluency in identity, network design, and infrastructure-as-code that many strong data center teams have not yet built. Assess the gap honestly and plan to close it with training, hiring, or a partner before it becomes the bottleneck.
• Cost baseline. You cannot prove savings you never measured. Capture current fully loaded cost per workload — hardware amortization, licensing, power, floor space, and the labor to run it — as the number every cloud estimate gets compared against.

Figure: readiness reads as a vague question until it resolves into seven auditable dimensions, each with an owner and a finding.

Assign a disposition to every workload

Discovery produces an inventory; the assessment produces a decision for each item. The standard framework is the 6 Rs, and the assessment's job is to place every application in exactly one bucket with a documented rationale.

1. Rehost — move with minimal change. The low-risk default for stable, well-understood systems.
2. Replatform — keep the architecture but swap components for managed services, such as a self-managed database becoming a managed one.
3. Refactor — re-architect for cloud-native patterns. Reserve this for workloads where scalability or release velocity is a real constraint, because it carries the most effort and risk.
4. Repurchase — retire the app in favor of a SaaS equivalent.
5. Retire — decommission it. Discovery typically finds that 10 to 20 percent of what is running has no real users. Turning it off is the cheapest win in the program.
6. Retain — leave it where it is for now. A hybrid cloud design gives latency-bound systems, hardware dependencies, and mid-contract applications a deliberate home instead of an exception nobody planned for.

An unclassified application is an unplanned outage waiting for a maintenance window. Every workload gets a disposition and a named owner, or it does not enter the plan.

Turn findings into a business case

The assessment output has to survive a conversation with finance, so it must speak in money and risk, not architecture diagrams.

• Model total cost of ownership on both sides. Compare the on-premises baseline against a realistic cloud estimate that includes compute, storage, data egress, managed-service premiums, and the operational labor that does not disappear. Egress and inter-region traffic are the line items that most often blow past the forecast.
• Right-size, do not match. Cloud estimates built by mirroring oversized data center hardware are always too high. Base them on the utilization you measured, and factor in reserved or committed-use discounts for steady workloads.
• Name the non-cost benefits plainly. Elasticity, faster provisioning, managed resilience, and exit from a data center lease are real value, but state them as outcomes with owners rather than adjectives.

Build the wave plan

The final artifact is a sequence, not a single event. Group workloads into waves that share dependencies and a maintenance window, and order them so learning comes first and risk comes last.

• Wave 0 is a proof of concept — something real but low-stakes that tests your runbook, network path, and rollback, not just the application.
• Move foundational shared services early — identity, DNS, shared databases — or extend them across a hybrid link so later waves land on solid ground.
• Keep each wave reversible inside one window. If it cannot be rolled back before users arrive, it is too big.

Red flags that mean not-yet

Part of the assessment's value is the authority to say "wait." These findings mean a specific workload, or the whole program, is not ready:

• No accurate inventory. If discovery keeps turning up systems nobody owns, you are not ready to sequence anything.
• Unmapped dependencies. An application whose upstream and downstream calls you cannot see will fail on cutover. Map it or retain it.
• Unresolved compliance or residency questions. Do not migrate regulated data into an architecture whose controls you have not validated. Settle it first, and bake cloud security — least-privilege identity, encryption, segmentation, and continuous posture monitoring — into the landing zone from day one.
• A cost model that only works on paper. If savings depend on discounts you have not committed to or egress you have not measured, the case is not proven.
• A team with no cloud operating experience and no plan to get it. Migrating faster than you can operate safely just relocates the problem.

None of these is permanent. Each is a task with an owner and a date that moves the workload from not-yet to ready.

Where to start

A cloud readiness assessment is inventory built from evidence, a disposition for every workload, a cost baseline you can defend, and the discipline to flag what is not ready. Get that right and the migration itself becomes the easy part.

intSignal runs cloud readiness assessments that produce a defensible business case and a wave plan built around your real dependencies, not a generic template. If you want a candid read on what should move, what should stay, and what has to be fixed first, talk to our cloud team.