Table of Contents
Why a Cloud Migration Readiness Assessment?
The temptation is real: cloud providers promise cost savings, scalability, and innovation at the push of a button. But reality often tells a different story. According to Gartner, approximately 30% of all cloud migration projects fail due to inadequate preparation — not the technology itself. Organizations that jump into migration without a structured assessment routinely experience budget overruns of 50% or more.
A Cloud Migration Readiness Assessment is not bureaucratic overhead — it is a strategic investment. It answers the fundamental question: Is your organization — technically, organizationally, and operationally — ready for cloud operations? The answer determines whether your migration becomes a success or remains an expensive experiment.
The most common causes of failed migrations are alarmingly predictable: lack of cost transparency, underestimated dependencies between systems, insufficient cloud skills within the team, and unclear responsibilities. All of these risks can be identified and addressed early through a systematic assessment.
In practice, we see the same pattern repeatedly: organizations migrate their first workloads to the cloud successfully, celebrate the apparent victory — then discover six months later that monthly cloud costs are three times the original on-premises expenses. The reason? They moved servers but neither adapted their architecture nor modernized their operational processes. A readiness assessment would have exposed this discrepancy before the first resource was provisioned.
30% of all cloud migrations fail due to inadequate preparation. A structured assessment reduces this risk by up to 70%.
The 6R Strategy: Understanding Migration Paths
Before evaluating individual workloads, you need to understand which migration paths are available. The 6R model, established by Gartner, provides a proven framework for determining the right strategy for each application. Not every application belongs in the cloud — and not every one needs to be rebuilt from scratch.
Choosing the right migration path has massive implications for cost, timeline, and risk. Rehosting a legacy application can be completed in weeks but delivers minimal cloud benefits. A full refactoring takes months but enables significantly lower operational costs and greater agility in the long run. The art lies in finding the right balance for each application.
- 1Rehost (Lift & Shift): The fastest option — applications are moved 1:1 to cloud VMs. Ideal for datacenter consolidations and as a first step when timelines are tight. Downside: Minimal cloud-native benefits, potentially higher costs from overprovisioning.
- 2Replatform (Lift, Tinker & Shift): Minor optimizations during migration — such as switching from a self-managed database to a managed service like RDS or Cloud SQL. Good effort-to-benefit ratio with moderate risk.
- 3Repurchase (Drop & Shop): Replacing an existing application with a SaaS solution. Typical example: A self-hosted email server is replaced by Microsoft 365. Sensible for commodity applications that provide no competitive advantage.
- 4Refactor (Re-Architect): The application is re-architected for the cloud — microservices, containers, serverless. Highest effort but also the highest long-term benefit. Recommended for strategically important applications with a long expected lifespan.
- 5Retire: Decommissioning applications that are no longer needed. In practice, assessments reveal a surprising number of systems that nobody actively uses but that continue to incur infrastructure costs. Migration is the ideal time for this cleanup.
- 6Retain: A deliberate decision to keep certain workloads on-premises for now. This may be for regulatory reasons, due to lack of cloud support, or simply because the business case for migration does not exist.
15 Questions for Your Cloud Readiness
The following 15 questions form the core of every Cloud Migration Readiness Assessment. They are organized into five dimensions that together paint a complete picture of your migration capability. Answer each question honestly — sugarcoating will come back to haunt you during execution.
Each question includes pointers on what constitutes a good answer and where typical pitfalls lurk. Use the assessment as a basis for discussion with your leadership team, not as a solo self-assessment by the IT department.
Strategy & Business Case (Questions 1–3)
Question 1: What are your concrete business drivers for cloud migration? — A cloud migration needs a clear business case beyond "everyone is doing it." Legitimate drivers include cost optimization, scalability for growing business, accelerating innovation, or replacing aging infrastructure. If your only driver is "the CTO heard about it at a conference," you should pause. The best migrations are driven by measurable business goals: 30% shorter time-to-market, 40% reduction in infrastructure costs, or 99.99% availability for business-critical systems.
Question 2: Have you completed a full Total Cost of Ownership (TCO) analysis? — The TCO analysis is the most common weak point in cloud business cases. Many organizations compare only server costs — on-premises hardware versus cloud VMs. This systematically overlooks hidden costs: data transfer fees (egress), logging and monitoring costs, premium support contracts, training expenses, and productivity loss during migration. An honest TCO analysis spans at least 3 years and accounts for both direct and indirect costs. Only then does it become clear whether the cloud is actually cheaper — or whether the value lies in other areas.
Question 3: What does your migration timeline look like — and is it realistic? — "We want to be fully in the cloud within six months" is a statement we hear regularly as consultants — and one that almost always leads to disappointment. A realistic timeline accounts for not just the technical migration but also change management, training, testing phases, and running both environments in parallel. For mid-sized companies with 20–50 applications, a migration timeline of 12–18 months is realistic. Large enterprises with hundreds of applications and complex dependencies should plan for 2–3 years.
Technical Readiness (Questions 4–6)
Question 4: Do you have complete visibility into your current IT landscape? — You can only migrate what you know about. This sounds trivial but is far from it. In many organizations, shadow IT systems, undocumented database connections, and legacy applications whose responsible owner left the company long ago are common. A complete application portfolio assessment — including all dependencies, data flows, and integrations — is the indispensable foundation of any migration. Tools like AWS Migration Hub, Azure Migrate, or independent discovery tools help with automated inventory.
Question 5: Which workloads are cloud-ready — and which are not? — Not every application can be seamlessly moved to the cloud. Mainframe applications, software with hardware-bound licenses, or systems with extreme latency requirements are typical candidates that require special attention. Evaluate each workload against criteria such as: statelessness (stateless vs. stateful), licensing model (BYOL-capable?), dependency on specific hardware, performance requirements, and data sensitivity. This evaluation provides the basis for 6R assignment.
Question 6: Do you know all dependencies between your systems? — The most underestimated dimension of any cloud migration is dependencies. An application rarely operates in isolation — it communicates with databases, API gateways, message queues, shared filesystems, and other applications. If you migrate System A to the cloud but System B (which supplies data to A) remains on-premises, you create a hybrid situation with latency problems and complexity. Dependency mapping — ideally tool-assisted and captured over several weeks — is essential.
Security & Compliance (Questions 7–9)
Question 7: What compliance requirements apply to your data and applications? — Regulatory requirements can significantly constrain a cloud migration or force specific architectural decisions. GDPR, industry-specific regulations (financial services, healthcare, critical infrastructure), and contractual obligations toward customers define the framework. Clarify early on: Which data may go to the cloud? Which cloud regions are permissible? Are there retention requirements that mandate specific storage classes? What certifications must the cloud provider hold?
Question 8: How will you handle data sovereignty and data residency? — The question of where your data is physically stored is not purely technical — it is legal and strategic. For European companies, GDPR and the Schrems II ruling impose strict requirements. AWS, Azure, and GCP all offer data centers in Frankfurt and other EU locations, but not every service is available in every region. Check for each workload: Is an EU region sufficient? Must it be a specific country? Is there data that must remain on-premises? Sovereign cloud offerings such as T-Systems Sovereign Cloud powered by Google Cloud explicitly address this topic.
Question 9: What does your current security baseline look like? — Before talking about cloud security, you need to know your current security baseline. Many organizations project security expectations onto the cloud that they never achieved on-premises. Document: How does your identity and access management work today? How are secrets (credentials, API keys) managed? What encryption standards are in place? What do your incident response processes look like? The shared responsibility model means the provider secures the infrastructure — but you are responsible for configuring your resources. Misconfigurations in IAM policies or open S3 buckets are the most common cause of cloud security incidents.
Organization & Skills (Questions 10–12)
Question 10: Does your team have sufficient cloud competencies? — Technology is only as good as the people operating it. An honest skill-gap analysis is often the uncomfortable part of the assessment — but the most important one. Evaluate your team on: experience with Infrastructure-as-Code (Terraform, CloudFormation), container orchestration (Kubernetes, ECS), cloud networking (VPCs, peering, Transit Gateway), cloud security (IAM, security groups, KMS), and cloud-native development (serverless, managed services). Identify not just knowledge gaps but also bottlenecks: If only one person on the team knows Terraform, that is a single point of failure.
Question 11: Who owns the migration — and does that person have decision-making authority? — Cloud migrations rarely fail due to technical problems and frequently due to organizational ones. Without a dedicated migration owner with clear decision-making authority and sufficient budget, projects stall in endless coordination loops. The ideal migration owner sits at the intersection of IT and business, has access to the C-level, and can coordinate cross-functional teams. In larger organizations, a Cloud Center of Excellence (CCoE) is recommended — defining best practices, establishing governance frameworks, and enabling internal teams.
Question 12: What training is needed — and how will you provide it? — The transformation to cloud-based operations requires not just new technical skills but a fundamental shift in how IT is operated. Provisioning in minutes instead of weeks, pay-per-use instead of capacity planning, Infrastructure-as-Code instead of ticket-based changes. Allocate dedicated training budgets — for both cloud provider certifications (AWS Solutions Architect, Azure Administrator) and internal workshops, pair programming, and hands-on labs. A rule of thumb: Budget 10–15% of the migration cost for training and enablement.
Operations & Governance (Questions 13–15)
Question 13: How will you monitor and control your cloud costs? — Cloud costs are variable, granular, and — if uncontrolled — explosive. Without a structured FinOps framework, you will discover within a few months that your cloud bill significantly exceeds projections. Implement from day one: tagging standards for all resources, budget alerts at the project and team level, automated rightsizing for over-provisioned instances, and regular cost reviews. Tools like AWS Cost Explorer, Azure Cost Management, or third-party solutions like Spot.io and Infracost support you in this effort. Experience shows: organizations that implement FinOps from the start save an average of 25–35% compared to those that address the topic only after migration.
Question 14: What is your backup and disaster recovery strategy in the cloud? — "The cloud is redundant anyway" — this misconception has cost many organizations dearly. Yes, cloud providers offer highly available infrastructure. But data loss from accidental deletion, ransomware, or configuration errors is possible in the cloud too. Define for each workload: RPO (Recovery Point Objective) and RTO (Recovery Time Objective), backup frequency and retention period, cross-region or cross-account backup strategy, and regular disaster recovery tests. Services like AWS Backup, Azure Site Recovery, or Veeam for multi-cloud cover the technical side — but the strategy must come from you.
Question 15: How will you govern multi-cloud and hybrid scenarios? — The reality for most organizations is not "one cloud" but a mix of AWS, Azure, Google Cloud, SaaS applications, and on-premises remnants. This heterogeneity demands clear governance: Who decides which workload runs on which provider? How do you ensure consistent security policies across all environments? How do you avoid vendor lock-in while still leveraging provider-specific managed services? Define clear guardrails, rely on Infrastructure-as-Code for portability, and invest in a cloud management platform that gives you a unified view across all environments.
Cloud Migration Readiness Matrix
The following matrix provides a quick orientation for assessing your readiness in each dimension. Use it as a discussion basis within your migration team. Be honest in your evaluation — every yellow or red rating is an opportunity for improvement, not a deficiency.
The goal is not to be "Green" in every dimension immediately. Many organizations deliberately begin their migration with a mix of green and yellow ratings — what matters is that red areas are addressed before migration begins.
| Area | Ready (Green) | Partially Ready (Yellow) | Not Ready (Red) |
|---|---|---|---|
| Strategy & Business Case | Clear business objectives defined, TCO analysis completed, realistic timeline | Business objectives present but imprecise, TCO only partially calculated | No clear objectives, migration purely technology-driven, no TCO analysis |
| Technical Readiness | Complete application portfolio, dependencies mapped, 6R assignment completed | Application portfolio partially captured, some dependencies unclear | No overview of IT landscape, shadow IT, no dependency analysis |
| Security & Compliance | Compliance requirements documented, security baseline defined, shared responsibility understood | Compliance requirements known but not fully documented | No compliance analysis, no security baseline, shared responsibility unclear |
| Organization & Skills | Cloud skills in team, dedicated migration owner, training plan in place | Some cloud skills present, owner named but not fully dedicated | No cloud competency, no owner, no training budget |
| Operations & Governance | FinOps established, DR strategy defined, multi-cloud governance in place | Initial FinOps approaches, DR strategy in progress | No cost control planned, no DR concept, no governance |
The Most Common Cloud Migration Mistakes
From hundreds of migration projects we have supported, clear patterns have emerged. The following mistakes appear again and again — and they are all avoidable if you know what to look for.
- 1Lift & Shift as a permanent solution: Many organizations migrate via rehost and leave it at that. What was intended as a quick first step becomes the permanent state. The result: higher costs than on-premises with none of the cloud benefits. Plan a modernization roadmap from the outset that follows the initial rehost.
- 2Underestimating cloud costs: The monthly bill is not just compute and storage. Data transfer costs, logging, monitoring, premium support, and idle resources add up fast. Implement FinOps before provisioning the first resource, not after.
- 3Security as an afterthought: "We will handle that after migration" — a statement that regularly leads to security incidents. Cloud security must be integrated from day one: least-privilege IAM, encryption at rest and in transit, network segmentation, and automated compliance monitoring.
- 4Insufficient training: Teams migrating without adequate cloud knowledge make expensive mistakes. Oversized instances, misconfigured security groups, missing backups — all consequences of insufficient expertise. Invest in training before investing in cloud infrastructure.
- 5No exit plan: Vendor lock-in is a real risk. Organizations that rely exclusively on proprietary services from a single provider face significant switching costs later. Define an exit strategy — not because you intend to switch providers, but because having the option strengthens your negotiating position.
- 6Big-bang instead of wave migration: Attempting to migrate all systems simultaneously overwhelms any organization. Successful migrations work in waves: less critical workloads first as proof-of-concept, then progressively more critical systems. Each wave delivers insights for the next.
- 7No rollback plan: What happens if the migration of a critical system fails? Without a defined rollback plan, you are choosing between a non-functioning cloud system and an already decommissioned on-premises system. For every migrated workload, a tested rollback plan must exist.
- 8Ignoring organizational change: Cloud changes not just technology but the entire IT organization. Operations becomes DevOps, capacity planning becomes FinOps, ticket-based changes become self-service. Organizations that ignore this cultural transformation will not sustain the technical migration.
Next Steps: From Assessment to Roadmap
An assessment is only as valuable as the actions derived from it. The following steps translate your readiness evaluation into a concrete migration roadmap.
Start with prioritization: Which red areas from the readiness matrix are showstoppers? These must be addressed before the first migration begins. Typical showstoppers include unresolved compliance questions, insufficient skills in the core team, and a nonexistent business case.
Define migration waves: Group your applications into 3–5 waves, starting with low-risk, high-value workloads. The first wave serves as a pilot project — here you gain experience, validate your processes, and build confidence. Each subsequent wave becomes more efficient because you learn from previous ones.
Build a landing zone: Before the first workload is migrated, your cloud environment must be ready. A landing zone encompasses: account structure (multi-account or single account with project separation), network design (VPC layout, connectivity to on-premises), identity federation (SSO, roles, policies), logging and monitoring (centralized logging, alerting), and security guardrails (SCPs, Azure Policies). Services like AWS Control Tower or Azure Landing Zones accelerate this setup.
Establish a governance framework: Define clear rules for cloud usage — from naming conventions and tagging standards to change management processes. This framework grows with your cloud maturity and prevents the cloud environment from becoming an ungoverned sprawl.
Plan for parallel operations: During migration, you temporarily operate two environments. Budget for the costs — and define clear criteria for when on-premises systems are decommissioned. A typical parallel operation period lasts 3–6 months per migration wave.
Conclusion
A cloud migration is not an IT project — it is a business transformation. Technology is only part of the equation. Strategy, organization, skills, security, and governance must all receive equal attention.
The 15 questions in this assessment cover the most critical dimensions. If you cannot confidently answer more than five of them, your organization is not yet ready for migration — and that is perfectly fine. Better to identify gaps now than to discover them painfully in the middle of migration.
Use the readiness matrix as a starting point, create a realistic plan to close the identified gaps, and begin your migration only when you have achieved at least "Yellow" in all five dimensions. A well-prepared migration may take longer in the planning phase — but delivers results faster during execution.
Cloud migration is not a sprint but a marathon. And as with any marathon: preparation determines success.
Sources & References
The cloud strategies and best practices referenced in this article are based on the following sources:
- AWS Well-Architected Framework: https://aws.amazon.com/architecture/well-architected/
- Azure Cloud Adoption Framework: https://azure.microsoft.com/en-us/solutions/cloud-enablement/cloud-adoption-framework
- Gartner 6R Migration Model: https://www.gartner.com/en/documents/3873016
- AWS Migration Hub: https://aws.amazon.com/migration-hub/
- FinOps Foundation: https://www.finops.org/
Key Takeaways
- 30% of all cloud migrations fail due to inadequate preparation — a structured readiness assessment is not optional, it is mandatory.
- Not every workload belongs in the cloud. The 6R strategy helps determine the right migration path for each application.
- Cloud costs are systematically underestimated. An honest TCO analysis spanning at least 3 years is the foundation of any business case.
- Skills are the most common bottleneck. Invest 10–15% of the migration budget in training and enablement.
- Migrate in waves, not as a big bang. Each wave delivers insights that make the next one more efficient.
- Governance and FinOps must be in place before the first migration — not as an afterthought after the first surprisingly high cloud bill.
Related Assessment Templates
Frequently Asked Questions
Duration depends heavily on scope and complexity. For a mid-sized company with 20–50 applications, plan for 12–18 months — from the initial assessment phase to full cloud operations. Large enterprises with several hundred applications, complex legacy systems, and strict compliance requirements typically need 2–3 years. Importantly, these timeframes include not just the technical migration but also preparation, training, testing, and the stabilization phase after migration. The most common mistake is budgeting only for the actual migration time and ignoring the effort for preparation and follow-up. A pilot migration of individual workloads, however, can be completed in as little as 4–8 weeks.
A reliable cost estimate without knowledge of your specific environment is not possible — but typical ranges can be identified. For a mid-sized company, the pure migration costs (consulting, tools, parallel operations) range from EUR 100,000–500,000. In addition, ongoing cloud costs may be 20–40% above or below previous on-premises costs depending on the degree of optimization. The key is a holistic view: beyond direct costs, you must account for training effort, productivity loss during the transition, process adaptation, and potentially required refactoring work. Organizations that implement a FinOps framework from the start save 25–35% in the long run compared to those without structured cost management.
The answer "it depends" is unsatisfying but honest. AWS has the broadest service portfolio and the largest community — ideal for organizations with diverse technical requirements. Azure is the natural choice for Microsoft-centric organizations (Active Directory, Office 365, .NET) and offers excellent hybrid cloud integration. Google Cloud excels at data analytics, machine learning, and Kubernetes-native workloads. In practice, many organizations use more than one provider. More decisive than the provider itself are factors such as: existing skills on the team, current licensing contracts, specific service requirements, and data center availability in relevant regions. Avoid dogmatic decisions — choose pragmatically based on your concrete requirements.
Technically yes, practically only with significant effort. Repatriation — migrating back from cloud to on-premises — is possible but costly and complex. Costs often exceed the original migration costs since you need to procure hardware again, build data center capacity, and retrain your teams for on-premises operations. Studies indicate that approximately 10–15% of organizations have repatriated individual workloads — usually due to unexpected costs or compliance requirements. The best protection against repatriation is a thorough readiness assessment before migration. If you still need an exit plan: rely on open standards (containers, Kubernetes), avoid excessive use of proprietary services, and document your architecture carefully.
Lift-and-shift (rehost) means moving an application 1:1 to cloud infrastructure — the application itself is not changed. Instead of running on a physical server in your own data center, it runs on a virtual machine in the cloud. This is fast, inexpensive, and low-risk — but leverages almost no cloud benefits. Cloud-native, on the other hand, means architecting an application to fully exploit the strengths of the cloud: microservices, containers, serverless computing, managed databases, auto-scaling. Cloud-native applications are more elastic, cost-efficient, and resilient — but require significantly more development effort. In practice, we recommend a staged approach: first migrate via lift-and-shift, then progressively modernize toward cloud-native. This avoids big-bang risks and allows you to demonstrate value at every stage.
Not strictly required, but in most cases advisable — especially if this is your first major cloud migration. External consultants bring two things that are often missing internally: experience from dozens of comparable projects and an unbiased view of your organization. They recognize pitfalls that your internal team might overlook due to lack of experience and can bring proven frameworks and tools that accelerate the process. However, the migration should not be entirely delegated to external consultants. Your internal team must be able to independently operate the cloud environment after migration. The ideal approach is a knowledge transfer model: external consultants lead the planning and first migration waves while simultaneously building and enabling your internal team. From wave 2 or 3 onward, your team takes the lead — consultants are available only in an advisory capacity.