Moving workloads to the cloud is not a single decision — it is the result of dozens of smaller decisions made under pressure, with incomplete data, and competing stakeholder expectations. The cloud migration assessment is the process that transforms those decisions from gut instinct into structured analysis. Done well, it tells you what to move, when, at what cost, and in what order. Done poorly — or skipped altogether — it is the single most reliable predictor of a migration that runs over budget, misses its timeline, and delivers infrastructure that is harder to operate than what it replaced.
In twelve-plus years of advising engineering teams across Europe, the most consistent pattern I see is this: organisations that invest two to four weeks in a rigorous assessment routinely achieve better financial outcomes than those who spend months in ad hoc discovery. This guide distils the frameworks, methodology, and practical lessons that shape how we run assessments at Gart Solutions — alongside real client results that demonstrate what a disciplined process produces in practice.
TL;DR
- AWS Cloud Adoption Framework (CAF) structures readiness across six perspectives: Business, People, Governance, Platform, Security, and Operations.
- Every application in your portfolio needs a strategy from the 7Rs: Retire, Retain, Rehost, Relocate, Replatform, Repurchase, or Refactor.
- TCO modelling must include compute, storage, networking, licensing, transition costs, and “bubble costs” during parallel operations.
- Zombie machines, incomplete discovery windows, perimeter-security bias, and licence mismanagement are all detectable — and fixable — at assessment.
- Gart Solutions has delivered 25% monthly AWS cost reductions (Datamaran) and 81% compute savings (Thai jewelry manufacturer/Azure) through structured assessment.
Why the assessment phase defines migration outcomes
The impetus for cloud migration typically comes from the top: consolidate data centres, reduce capital expenditure, improve agility. But executive mandates rarely arrive with the technical nuance required to act on them. The assessment phase is where that nuance is established.
A thorough assessment serves at least three purposes. First, it creates an authoritative inventory of what you actually have — not what your asset management system claims. Shadow IT is endemic in enterprise environments; automated discovery routinely surfaces 15–20% more servers and services than documented. Second, it assigns a migration strategy to each workload before anyone touches infrastructure. Third, it produces the financial model that converts “we want to move to cloud” into “here is the three-year TCO delta and the payback period.”
Organisations that treat migration as a structured, iterative journey consistently realise higher long-term value than those who treat it as a one-time lift-and-shift exercise. The difference is not talent — it is process.
The strategic foundation: AWS Cloud Adoption Framework
The AWS Cloud Adoption Framework (CAF) is the most widely adopted model for structuring a cloud readiness assessment. It defines six organisational perspectives, each owned by a distinct set of stakeholders:
| Perspective | Primary Stakeholders | Core Focus |
|---|---|---|
| Business | CEO, CFO | Aligning cloud investment with business strategy and value realisation |
| People | CPO, HR | Culture of continuous learning; organisational change management |
| Governance | CRO, CDO | Risk management, programme governance, compliance frameworks |
| Platform | CTO, Architecture Leads | Designing scalable, enterprise-grade cloud platforms |
| Security | CISO | Confidentiality, integrity, availability; access controls; encryption |
| Operations | VP Engineering, SRE | Site reliability, ITSM, service delivery at scale |
The CAF matters because it forces the conversation beyond infrastructure. The People perspective alone addresses a factor that industry data suggests accounts for nearly 45% of total migration spend when change management is handled poorly. If your assessment only covers servers and databases, it is covering less than half the problem.
The operational tool that makes CAF actionable is the Cloud Readiness Assessment (CRA), which evaluates an organisation against 47 specific capabilities and produces a Cloud Adoption Readiness Tool (CART) report. That report tells you, capability by capability, what gaps exist before full-scale migration begins — and in what order to close them.
The CAF assessment follows a four-phase cycle: Envision (link migration to strategic objectives), Align (map capability gaps and cross-organisational dependencies), Launch (run production pilots to demonstrate value), and Scale (expand pilots enterprise-wide). This cycle prevents analysis paralysis by decomposing an overwhelming undertaking into manageable, validated steps.
The 7Rs: assigning a strategy to every workload
A cloud migration assessment is not complete until every application in the portfolio has a clearly assigned migration strategy. The 7Rs framework — evolved from Gartner’s original 5Rs — is the industry standard for making those assignments.
| Strategy | What It Means | Best For | Primary Benefit |
|---|---|---|---|
| Retire | Decommission obsolete or redundant applications | Legacy systems no longer adding business value | Immediate reduction in licensing, maintenance, and compute costs |
| Retain | Keep on-premises, at least for now | Regulatory/latency constraints; applications slated for future replacement | Stability for complex or tightly regulated systems |
| Rehost | Lift-and-shift — move as-is, no code changes | Tight deadlines; stable legacy applications; data centre exit pressure | Fastest migration path; minimal disruption |
| Relocate | Move VMs at hypervisor level without OS changes | VMware workloads moving to VMware Cloud on AWS / Azure VMware Solution | Zero application changes; operational consistency maintained |
| Replatform | Targeted optimisations to leverage managed cloud services | Moving from self-managed DB to Amazon RDS or Azure SQL | Reduced management overhead; improved performance; minimal code changes |
| Repurchase | Replace with SaaS equivalent | On-premises CRM/HR moving to Salesforce or Workday | Modern features; elimination of maintenance costs |
| Refactor | Full architectural redesign to cloud-native | Mission-critical apps requiring maximum scalability or resilience | Highest long-term ROI; true cloud-native capabilities |
A pragmatic approach for most enterprise portfolios: rehost stable workloads to exit the data centre on schedule, replatform moderate-complexity applications where managed services offer clear operational savings, and refactor only the systems where cloud-native capability is a genuine competitive differentiator. Most portfolios end up using all seven strategies in different proportions.
🗺️ Unsure which strategy applies to your application portfolio? Gart Solutions runs vendor-neutral cloud migration assessments that assign a 7Rs strategy to every workload — with a financial rationale attached. Explore our migration assessment practice →
Technical discovery: seeing what you actually have
You cannot assess what you cannot see. Technical discovery is the process of building a complete, accurate picture of existing infrastructure — and it is almost always more complex than stakeholders expect.
Automated discovery and the shadow IT problem
Manual discovery is too slow and too error-prone for any environment above 50 servers. Automated discovery tools scan the infrastructure and capture real-time performance baselines: CPU and memory utilisation, disk I/O patterns, network throughput, peak versus average load. More importantly, they surface shadow IT — resources that exist but are undocumented. These often carry significant security and compliance exposure that was previously invisible to the organisation.
| Discovery Dimension | Data Points Captured | Recommended Tooling |
|---|---|---|
| Infrastructure | OS types, patch levels, hardware specs, utilisation patterns | AWS Application Discovery Service, Azure Migrate, Device42 |
| Application | Language stack, runtime dependencies, configurations | AppDynamics, Datadog, Dynatrace |
| Interdependencies | TCP connections, database calls, API call latency | Device42, Azure Migrate Service Map, Faddom |
| Network Performance | Peak bandwidth, ingress/egress throughput, latency benchmarks | Prometheus, Grafana, Jaeger |
Dependency mapping: the step most teams underestimate
Applications do not run in isolation. Dependency mapping — visualising which services communicate with which, over what protocols — is essential for defining “migration waves”: groups of tightly coupled services that must move together to avoid breaking integrations. In large-scale migrations, proper dependency analysis can save hundreds of hours of manual effort and prevent unexpected outages during cutover. Tools like Device42 automatically generate move groups from observed communication patterns, dramatically reducing the planning burden.
Discovery window length: why 30 days is the minimum
A discovery scan conducted over three to five days will miss peak load periods — end-of-month financial processing, seasonal retail spikes, end-of-quarter reporting. Right-sizing recommendations built on incomplete utilisation data will be dangerously inaccurate, leading to performance degradation once workloads face real production load in the cloud. Minimum recommended discovery window: 30 days, capturing at least one full business cycle.
Financial modelling: building the business case
The financial component of the assessment typically determines whether the project secures executive approval. A well-constructed business case compares the Total Cost of Ownership (TCO) of current on-premises operations against projected cloud expenditure over a three-to-five-year horizon.
What TCO must include
Direct costs — hardware procurement, software licensing, power and cooling — are usually straightforward. The costs that get missed are indirect: productivity lost to unplanned downtime, administrative overhead of managing aging infrastructure, and the opportunity cost of engineering time spent on undifferentiated heavy lifting rather than product development. The full formula:
- Migration transition costs include: Tooling licences, external consulting fees, and internal staff training.
- Long-term perspective: Model all costs over a 3–5 year horizon to capture the true ROI, rather than just Year 1.
Bubble costs: the overlooked budget line
Most organisations encounter a temporary cost increase immediately after migration. This is driven by “bubble costs” — the period when both on-premises and cloud systems run simultaneously to maintain business continuity during cutover. Research suggests these overlap charges account for nearly 17% of total cost overruns when not modelled in advance. Budget for them explicitly, and set a clear cutover deadline to limit their duration.
Right-sizing and zombie machine elimination
Pre-migration compute reduction from zombie machine removal
Annual compute savings from proper right-sizing
Cloud licensing cost reduction via Azure Hybrid Benefit
Storage cost savings from cold/archival tier migration
From assessment to results: real client examples
Theory is useful. Concrete outcomes are more persuasive — both for building internal business cases and for understanding what disciplined assessment actually produces in practice.
Datamaran: AWS Infrastructure Optimisation and Disaster Recovery
Datamaran is a global ESG analytics platform processing thousands of regulatory documents daily using advanced NLP models. As AI workloads grew, Gart Solutions identified key cost drivers: RDS PostgreSQL ($1,721/mo) and SageMaker ($1,452/mo).
We delivered a multi-region DR architecture via Terraform, implemented Savings Plans and Spot Instances, and automated backup policies to secure their posture.
Thai Jewelry Manufacturer: 81% Cost Reduction with Azure Spot VMs
A leading Thai jewelry manufacturer needed to process 2TB of daily video data for real-time AI insights. Their initial on-demand compute costs reached $5,363/month for VMSS workloads.
By redesigning the architecture around Azure Spot VMs and building graceful interruption handling into the pipeline, we reduced VMSS costs from $4,700/month to just $430/month.
Both cases illustrate the same principle: the assessment phase is where cost reduction opportunities are identified. Migration execution is how they are realised.
Security, compliance, and the shared responsibility model
Every cloud migration assessment must include a security and compliance track. The cloud introduces the shared responsibility model: the provider is responsible for the security of the cloud (physical infrastructure, hypervisor, networking), while the organisation remains responsible for security in the cloud (application code, access management, data protection, configuration).
That distinction has direct implications for what the assessment must evaluate:
- Identity and Access Management (IAM): Are permissions scoped to least privilege? Excessive permissions granted during migration — often as a temporary shortcut — are a persistent source of insider threat and accidental data exposure.
- Data classification and residency: What sensitivity level applies to each dataset? For regulated industries, verify that the target cloud provider supports geographic constraints and meets applicable standards — HIPAA, GDPR, ISO 27001, SOC 2.
- Network configuration: Open storage buckets, improperly scoped security groups, and overly permissive firewall rules are the leading causes of cloud-related data breaches. These are detectable during assessment.
- Zero Trust posture: In a cloud environment, the network perimeter is meaningless. Identity-centric Zero Trust — where every connection is treated as potentially hostile — should be the target architecture from Day 1.
🔒 Compliance requirements shaping your migration architecture? Gart Solutions’ architects help regulated organisations map cloud provider capabilities to specific compliance frameworks — GDPR, HIPAA, ISO 27001, and SOC 2. Explore our compliance audit practice →
The human dimension: skills gaps and change management
Technical readiness is necessary but not sufficient. Organisations consistently underestimate the human side of cloud adoption — and consistently pay for it. A cloud migration assessment should include an honest inventory of current cloud skills within the IT team. Gaps in cloud architecture, security engineering, and DevOps automation are common in organisations migrating from on-premises environments.
The most effective structural response is a Cloud Centre of Excellence (CoE) — a cross-functional group comprising senior leadership, technology leads, and line-of-business owners who set standards for cloud adoption across the organisation. The CoE prevents migration from becoming a siloed IT project and ensures decisions are made with full business context.
The assessment should also produce a concrete training plan: target certifications by role, a timeline for achieving them, and “learning sandbox” environments where teams can experiment with cloud-native tooling without risk to production systems. Neglecting this produces predictable outcomes: resistance, decreased post-migration productivity, and proliferation of shadow IT as users find workarounds to unfamiliar workflows.
Common pitfalls and how to avoid them
Despite mature frameworks and sophisticated tooling, a significant proportion of migration projects miss their timelines or budgets. The failures share common patterns:
| Pitfall | Operational Impact | Mitigation Strategy |
|---|---|---|
| Bubble cost neglect | Budget overruns of 15–20% in initial migration phase | Model parallel operation costs explicitly; set a hard cutover deadline. |
| Analysis paralysis | Months of discovery with no workloads migrated; missed window | Time-box the assessment; start migrating the first wave within 8 weeks. |
| Incomplete discovery window | Right-sizing failures; performance degradation in production | Minimum 30-day discovery window covering at least one full business cycle. |
| Perimeter-security bias | Misconfigurations; open storage buckets; insider threat exposure | Design Zero Trust IAM architecture from Day 1 of assessment planning. |
| Licence mismanagement | Unplanned licensing fees; post-migration cost surprises | Conduct a Licensing Health Check before finalising target architecture. |
| Skill gap denial | Low adoption; decreased productivity; Shadow IT proliferation | Establish CoE and mandate cloud training before the first migration wave. |
Sustainability: quantifying the green cloud benefit
Environmental, social, and governance (ESG) performance is an increasingly material factor in cloud migration decisions. Public cloud infrastructure is up to 4.1× more energy-efficient than traditional on-premises data centres, driven by higher server utilisation rates, advanced cooling, and purpose-built silicon such as AWS Graviton.
For organisations with ESG commitments, quantifying this benefit belongs in the migration business case. The Software Carbon Intensity (SCI) standard from the Green Software Foundation provides a methodology for calculating carbon emissions per functional unit — per user, per API call, or per transaction. A practical step during assessment: identify “carbon hotspots” — workloads consuming excessive energy due to overprovisioning or inefficient code — and prioritise their migration to cloud regions powered by high proportions of renewable energy.
Cloud migration assessment checklist
Cloud migration assessment as the highest-leverage investment in migration
The cloud migration assessment is not a gate to pass through before the real work begins. It is the real work — or at least the work that determines whether everything that follows succeeds or fails.
A rigorous assessment clarifies which workloads to migrate and when, which strategy to apply to each, what the honest financial picture looks like over a three-to-five-year horizon, where security and compliance risks lie, and what organisational capabilities must be built before migration can scale. The organisations that treat assessment as a genuine investment — not a box to tick — emerge from migration with infrastructure that is genuinely cheaper, more resilient, and more capable of supporting product development than what they started with.
See how we can help to overcome your challenges
