Cloud Migration Step by Step: A Framework for CTOs

Why most cloud migrations blow their budget

38% of cloud migrations exceed the initial budget by more than 20%, according to Flexera 2024. The cause is not technical. It is that companies start migrating without a clear decision framework, pushed by vendor pressure or the vague notion that they “should be in the cloud.”

A well-executed cloud migration reduces operational costs, improves scalability, and accelerates time-to-market. A poorly planned one generates unexpected costs, performance degradation, and frustrated teams. The difference is not in the chosen technology. It is in the quality of the preparation.

Phase 1: assessment without self-deception

Before moving anything, you need a brutally honest inventory of what you have. Not what you think you have. What you actually have.

Application inventory. Every application with its dependencies, data volumes, traffic patterns, latency requirements, and regulatory constraints. We have seen organizations discover during migration that a critical application depended on a library that only worked on Windows Server 2012. That kind of surprise is avoided in the assessment.

Dependency analysis. Applications do not live in isolation. An ERP talks to a CRM, which talks to an invoicing system, which talks to a bank. The dependency graph determines what can move independently and what must move together.

Current cost baseline. The real cost of your on-premise infrastructure includes hardware, licenses, electricity, cooling, physical space, and the time of the team that maintains it. Many companies underestimate this cost because it is spread across different cost centers. Without a reliable baseline, you cannot compare against cloud.

Regulatory requirements. Data residency, sector compliance (PCI-DSS for payments, HIPAA for healthcare, financial regulation), and internal security policies. These requirements can eliminate cloud options or regions before you start.

Phase 2: the 6Rs decision framework

Not all applications deserve the same treatment. AWS’s 6Rs (originally from Gartner) provide a decision framework:

Rehost (lift-and-shift). Move the application as-is to cloud, typically to VMs. Fastest and lowest-risk option. Does not capture cloud-native benefits, but gets you out of the datacenter. Makes sense for stable applications you will not modify soon.

Replatform (lift-and-reshape). Small optimizations during migration: move the database to a managed service (RDS instead of MySQL on a VM), use a native load balancer, externalize session management to ElastiCache. Moderate effort, immediate operational benefit.

Refactor. Redesign the application to leverage cloud-native services: containers, serverless, managed queues, specialized databases. Highest long-term benefit, highest short-term cost. Only makes sense for applications with active development and a long useful life ahead.

Repurchase. Replace the application with SaaS. Your on-premise CRM with Salesforce. Your email with Google Workspace. Not a technical migration — a business decision.

Retire. Turn off the application. Every organization has applications nobody uses but nobody dares to shut down. The assessment is the time to identify them. In our experience, 10-20% of inventoried applications are retirement candidates.

Retain. Leave it where it is. Some applications have constraints that make migration impractical or uneconomical in the short term. Mainframes, applications with specific hardware dependencies, or systems with licensing contracts that penalize migration.

The typical distribution we see in European mid-market companies: 40% rehost, 25% replatform, 15% refactor, 10% repurchase, 5% retire, 5% retain. But every organization is different, and forcing an “ideal” distribution is a mistake.

Phase 3: realistic cost modeling

Cloud cost modeling has traps that vendor calculators do not make obvious.

Compute cost. On-demand prices are the reference, but nobody should pay on-demand for stable workloads. Reserved Instances (1 or 3 years) or Savings Plans reduce compute costs by 30-60%. The key is right-sizing: over-provisioning in cloud is as easy (and expensive) as on-premise. A FinOps framework helps control these costs from day one.

Data cost. Data egress (data leaving the cloud) has a cost. And it can be significant. An application serving 10TB of data per month to external users will generate an egress bill that surprises. This is the most underestimated cost in initial estimates.

Storage cost. Looks cheap per GB, and it is. But data grows, and lifecycle policies that delete old data are rarely implemented. We have seen organizations whose S3 costs grew 15% monthly for two years because nobody configured lifecycle policies.

Hidden costs. Premium support, networking services (NAT gateways, Transit Gateways, elastic IPs), logging and monitoring at scale, and inter-AZ transfer. These costs add 15-25% on top of the base estimate if not explicitly modeled.

A realistic cost model projects over 3 years, includes optimistic, realistic, and pessimistic scenarios, and is reviewed quarterly against actual spend. Anything less rigorous is an invitation to surprises.

Phase 4: wave-based execution

Migration executes in waves, not big bang. Each wave is a group of applications that move together, selected by:

• Mutual dependencies (must move together)
• Business criticality (start with the least critical)
• Technical complexity (start with the simplest)
• Team impact (do not overload a single team)

Wave 0: proof of concept. One or two non-critical applications to validate the base infrastructure, deployment pipelines, networking, security, and operational processes. This wave takes 4-6 weeks and its primary goal is learning, not migrating.

Waves 1-N: incremental migration. Each wave migrates 3-8 applications in 2-4 weeks. Each wave has its own rollback plan. Rollback is not “turn the old server back on” (though sometimes it is). It is a documented, tested procedure that allows reverting if something goes wrong.

Post-migration. After each wave: functional validation, performance testing, cost review against estimates, and team retrospective. Lessons from each wave feed the planning for the next.

The traps nobody mentions

The vendor “cloud premium.” The sales team at AWS, Azure, or GCP will propose premium managed services for everything. Some are worth it (managed databases, almost always). Others are unnecessarily expensive for what they offer. Evaluate each managed service against the open-source or self-managed alternative. Sometimes the price difference is 5x.

Progressive vendor lock-in. Every proprietary service you use is an anchor. To understand the real implications of lock-in, see our analysis on multi-cloud strategy. Lambda ties you to AWS. Cloud Functions ties you to GCP. Azure Functions ties you to Azure. This does not mean you should avoid them (sometimes the productivity justifies it), but you should be conscious of the exit cost.

Migrating the team. Your operations team knows how to manage physical servers and VMware. Cloud requires different competencies: IaC, virtual networking, IAM, managed services. Without serious training (not 45-minute webinars, but weeks of hands-on training), the technical migration will complete but operations will be fragile.

Networking. Connectivity between your residual on-premise environment and cloud (VPN, Direct Connect/ExpressRoute) is the most technically underestimated component. Latency issues, DNS, and inter-environment routing cause more post-migration incidents than any other factor.

A cloud migration is an operational transformation project, not an infrastructure project. The technology is the easy part. The people, the processes, and the architecture decisions are what determine whether it goes well or becomes a source of problems for years.