Cloud readiness assessment for legacy systems: a practical framework

Most cloud migration plans start with a slide deck and timeline, not evidence. Someone estimates six months, a cost, and Q4 savings. Then the team encounters a 14,000-line stored procedure, a COM+ component three services depend on, and a reporting stack only one person understands. The timeline doubles. The budget request returns to finance.

A cloud readiness assessment is a structured, evidence-based process that scores your infrastructure, applications, security, team skills, operations, and cost governance before migration spending begins. For legacy systems, it replaces anecdotal confidence with a defensible picture of what you have and what migration will actually cost.

What you'll find here:

• A working definition of cloud readiness assessment for legacy systems
• A six-dimension scoring framework for your portfolio
• How to map every workload to a 6R disposition using assessment outputs
• What a real legacy-to-cloud assessment looks like end to end, with a case reference
• Decision criteria for self-assessment versus external expertise

What is a cloud readiness assessment (and why generic checklists fail legacy systems)

A cloud readiness assessment evaluates your IT estate across multiple dimensions, scores each workload's migration risk, and produces a prioritized roadmap before migration dollars are spent. It answers directly: can this workload move to the cloud, under what conditions, at what cost, and with what risk?

Vendor tools like AWS Cloud Readiness Assessment Tool (CART) and Azure's Strategic Migration Assessment and Readiness Tool (SMART) offer useful entry points. They generate baseline scores in 5 to 15 minutes and map to cloud adoption frameworks. For greenfield or loosely coupled apps, that's often enough to start planning.

Legacy systems present a different problem. A monolith with undocumented dependencies, a brittle data warehouse running proprietary SQL extensions, Windows-specific components like MSMQ or DCOM, and a team that's never written Terraform—none of this surfaces in a 15-minute quiz. The failure mode is predictable: teams enter migration with anecdotal confidence, hit hidden dependencies or compliance walls mid-project, and stall. A legacy cloud readiness assessment must go deeper than any generic checklist.

You're assessing whether the organization, its technology, its people, and its financial controls are ready for a fundamentally different operating model.

The six dimensions of a legacy cloud readiness assessment

This framework gives you a repeatable structure for scoring any legacy workload. Each dimension includes what to assess, how to score it (low, medium, or high risk), and one concrete indicator separating real readiness from guesswork.

1. Application architecture and dependency mapping

Inventory every application in scope: runtime, framework version (.NET Framework 4.5 vs .NET 6, Java 8 vs Java 17), and hosting model (IIS, Windows Service, COM+). Map inter-service and data dependencies. The hard part isn't documented dependencies—it's implicit ones: shared file shares, registry keys, hardcoded IPs, scheduled tasks triggering other processes.

Score by coupling complexity. Loosely coupled services with well-defined APIs score low risk. A shared-state monolith with undocumented integrations scores high risk. One concrete indicator: the number of undocumented external service calls discovered during static analysis. If that number surprises the team, the application isn't ready for lift-and-shift.

2. Data and analytics subsystem readiness

Data warehouses, ETL pipelines, and reporting stacks deserve their own readiness track. Practitioners consistently identify these as the highest-risk component in legacy migrations. The application tier might move cleanly; the analytics tier almost never does without dedicated assessment.

Check database engine version, stored procedure count, proprietary SQL extensions, BI tool licensing and cloud compatibility, and data governance documentation. Score governance maturity and migration feasibility separately. A data warehouse with 500 stored procedures using vendor-specific syntax and no data lineage documentation is high risk regardless of application tier cleanliness.

Techstack's Analytics Subsystem for a Sales Engagement Platform case is instructive. A legacy analytics audit uncovered pipeline complexity that changed migration sequencing. The analytics tier was decoupled and migrated to Amazon Redshift before the application tier, reducing risk for both workstreams.

3. Infrastructure and operational observability

Inventory your servers, OS versions, virtualization layer, storage dependencies, and network topology. The bigger question is observability. Does the team have metrics, logs, and traces for production workloads today? If you can't see how the system behaves on-prem, you won't see it in the cloud.

Score by documented runbooks, monitoring coverage, and incident mean-time-to-resolution (MTTR) history. Flag Windows-specific components with no cloud equivalent: scheduled tasks via Task Scheduler, DCOM dependencies, MSMQ queues. Each requires its own migration plan.

4. Security posture and compliance controls

Assess data classification first. Which workloads touch PII, PHI, or financial data subject to HIPAA, SOC 2, or PCI-DSS? Then evaluate identity and access management maturity, encryption at rest and in transit, secrets management, and data sovereignty requirements.

Score on documentation. Documented compliance controls with clear ownership score low risk. Undocumented, implicit controls score high risk and require remediation before migration. One recurring failure: treating cloud security like on-prem perimeter security. The shared responsibility model creates gaps that don't exist in traditional data centers, catching teams late in projects when compliance audits block deployment.

5. Team skills and DevOps maturity

Assess cloud platform experience (AWS or Azure certifications, or hands-on project work), containerization knowledge, Infrastructure as Code adoption (Terraform, Bicep, CloudFormation), and CI/CD pipeline maturity. Don't rely on self-reported confidence. Score DevOps maturity using observable proxies: deployment frequency, lead time for changes, and change failure rate.

A team that can't run IaC in production will struggle regardless of cloud choice. This dimension gates the operating model decision. Low DevOps maturity means managed services and significant training investment, not self-managed Kubernetes.

6. Cost governance and FinOps readiness

Build total cost of ownership scenarios for each workload tier: compute, storage, egress, and licensing. Windows Server and SQL Server licensing alone can change migration economics depending on bring-your-own-license versus cloud-native options.

Assess FinOps capability directly. Does the organization have tagging standards, budget alerts, and a named owner for cloud spend? Documented cost baselines with rightsizing models score low risk. No cost baseline, no tagging, and no spend ownership mean high risk for post-migration bill shock. The output should be cost-versus-performance analysis per workload, not a single migration cost estimate.

Scoring and risk classification: turning assessment data into decisions

A cloud readiness assessment produces dimension-level scores for every workload. Aggregate those scores into a portfolio-level readiness view and risk heatmap that leadership can act on.

Use three risk tiers:

• Low risk: migrate with confidence. These workloads are loosely coupled, well-documented, and the team can operate them in the cloud.
• Medium risk: migrate with targeted remediation. Specific issues (compliance gap, missing observability, licensing question) need resolution before or during migration.
• High risk: retain, refactor, or retire. Do not lift-and-shift. Deep coupling, undocumented dependencies, regulatory exposure, or technical debt make direct moves dangerous.

Scoring directly produces a 6R disposition for every application:

Rehost — low risk, low complexity. Applies when an app runs cleanly on cloud infrastructure with minimal changes.

Replatform — low-to-medium risk, moderate complexity. Applies when an app needs minor adjustments: a managed database, a container runtime.

Refactor — high complexity, high business value. Applies when an app needs rearchitecting but is too valuable to retire.

Repurchase — any risk level, COTS replacement viable. Applies when a SaaS product replaces the custom-built system.

Retain — high risk, low business value for moving. Applies when it's cheaper to keep the system on-prem than migrate it.

Retire — redundant or obsolete. Applies when the workload should simply be decommissioned.

The risk heatmap is a leadership communication tool. It translates "our app estate is complex" into "here are the three workloads we can move in Q3 and the two that need six months of remediation first." If your assessment doesn't produce this specificity, it hasn't done its job.

What a cloud readiness assessment actually looks like end to end

A cloud readiness assessment for a mid-size legacy portfolio typically takes two to four weeks and runs through six phases: scoping and stakeholder interviews, automated discovery and inventory, questionnaire-based scoring across six dimensions, risk classification and 6R mapping, TCO modeling, and roadmap delivery with a leadership debrief.

Tooling supports discovery but doesn't replace judgment. Azure Migrate and AWS Application Discovery Service can inventory infrastructure and surface basic dependency information. These tools are useful starting points for servers, databases, and network connections. They do not assess DevOps maturity, FinOps capability, stored procedure complexity, or analytics governance. Those require structured interviews, code analysis, and operational review.

The Techstack Analytics Subsystem for a Sales Engagement Platform case shows this in practice. The assessment uncovered data pipeline complexity that changed migration sequencing. The original plan assumed the application and analytics tiers would migrate together. The assessment revealed that the analytics subsystem had deep dependencies and governance issues that made a joint move too risky. The team decoupled the analytics tier and migrated it to Redshift first, giving them a working cloud-based analytics layer before the rest of the estate moved and reducing risk for both workstreams.

That sequencing decision is what a readiness assessment should produce: move these workloads first, remediate these before touching them, and retire those three. A number like "72% ready" doesn't tell you any of that.

AWS cloud readiness assessment vs Azure cloud readiness assessment: what the vendor tools cover (and don't)

AWS CART and Azure SMART are structured entry points. Both are free, fast, and useful for generating an initial alignment score.

AWS CART covers six dimensions: business, people, process, platform, operations, and security, aligning with the AWS Cloud Adoption Framework. It's strong for organizational alignment scoring but weaker on legacy technical debt. It won't tell you how many stored procedures use proprietary syntax or whether your COM+ components have undocumented dependencies.

Azure SMART and Azure Migrate add infrastructure discovery. For Windows/.NET legacy estates, Azure Migrate can inventory VMs, map basic dependencies, and estimate Azure sizing. Microsoft also recommends using Azure Monitor, Resource Graph, and Security Center as part of readiness evaluation. For .NET Framework apps targeting Azure, this toolchain gives you a head start.

Both tools produce generic output for complex legacy estates. They don't score monolith coupling at granular level, assess stored procedure density, or evaluate whether your team can run IaC in production.

Use vendor tools to generate initial alignment scores. Supplement with structured portfolio assessment covering the six dimensions above for estates with legacy monoliths, proprietary data components, or regulated data. Cloud assessment and planning for legacy systems requires both automated discovery and human judgment.

When to run a self-assessment vs engage external expertise

Self-assessment works when your portfolio is well-documented, your team has prior cloud migration experience, you're dealing with fewer than 10 workloads, you don't handle regulated data, and your apps are mostly greenfield or loosely coupled.

External assessment is warranted when any of these are true: undocumented legacy monoliths, regulated data subject to HIPAA, PCI-DSS, or SOC 2, no established DevOps practice, prior failed migration attempts, or this is the organization's first cloud migration.

A mid-market SaaS company with a 12-year-old .NET Framework monolith, a SQL Server data warehouse with 800 stored procedures, and six engineers who've never deployed to AWS will miss things in a self-assessment. Your engineers are too close to the system to see blind spots. They know which workarounds keep it running. They don't always know which will break in a different environment.

Techstack's Software Audit service is designed for this situation. It produces readiness scores across all six dimensions, dependency maps with risk-classified integration points, and a prioritized migration roadmap. The goal is to surface problems internal teams are too close to see, not validate a plan already made.

If you've already decided to migrate and run the assessment to confirm that decision, you're doing it wrong. The assessment should be allowed to say "don't migrate this workload." That's a valid and sometimes correct output.

What a cloud readiness assessment should deliver

A completed cloud readiness assessment produces decision-making artifacts, not a narrative report. The final deliverable should include:

• A readiness score per workload and per dimension, not a single aggregate number
• A dependency map with risk-classified integration points
• A 6R disposition for every application in scope
• A risk heatmap structured for leadership communication
• TCO scenarios per migration path, showing cost differences between rehosting, replatforming, and refactoring
• A sequenced migration roadmap with dependencies and prerequisites visible
• Go/no-go criteria for each workload before migration begins

The output should tell leadership which workloads to move in Q1, which to defer, and which to retire. If it doesn't answer those questions directly, it's incomplete.

Starting your cloud readiness assessment: practical first steps

Step 1: Build the application inventory. Servers, databases, integrations, scheduled jobs, COM components, reporting tools. No assessment is credible without this baseline.

Step 2: Run the six-dimension questionnaire against each workload tier. Architecture, data, infrastructure, security, skills, and cost governance. Score each dimension for each workload.

Step 3: Apply risk scoring and classify every workload into low, medium, or high risk.

Step 4: Map each workload to a 6R disposition and sequence by risk and business criticality. Low-risk, high-value workloads go first. High-risk workloads get remediation plans or retention decisions.

Step 5: Model TCO for shortlisted migration paths. Compare rehost, replatform, and refactor costs. Include licensing, egress, and operational overhead.

Adjust dimension weights to match your regulatory and business context. A healthcare company with HIPAA-regulated data will weight security and compliance far more heavily than a media company with public-facing content.

If your team is ready to move and the portfolio is well-understood, Cloud Migration consulting from Techstack can take it from here. If you need to assess first, start with a Software Audit.