Effective Cloud Strategy: Four Takeaways from Customers Who Got It Right

We have been doing cloud migrations since the cloud was called "hosted services" and people were still arguing about whether running anything outside your own data center was a security risk. Over twenty-three years, some customers have genuinely won with the cloud — faster delivery, lower costs, better resilience — and some have just shifted their problems from one data center to another and gotten a larger bill. The difference between the two groups is not technical skill. It is four things the winners did and the losers did not.

1. They Picked a Target State, Not a Migration

The customers who got it right started with a clear picture of what "done" looked like. Not "moved to Azure" — that is a task, not an outcome. Something more like: "Our 50 business applications run on a mix of SaaS (where it exists), managed services (where we have scale), and private cloud infrastructure (for everything else). We spend 40 percent less on infrastructure, we can deploy new apps in weeks instead of quarters, and our team is spending 70 percent of its time on product work instead of plumbing."

The target state has three useful properties. It is measurable, so you can tell if you are getting there. It is boundary-setting, so you can say "no, that does not belong in the target state" when a vendor tries to upsell you. And it is honest about the trade-offs — nobody who has done this seriously thinks the answer is "everything in one place on one vendor."

The customers who got it wrong started with "we need a cloud strategy" and ended up with a pile of migrated VMs, a bigger bill, and a team that was not sure what was different. The migration was the whole plan, so when the migration finished, they were done, except nothing was actually better.

Write the target state before you write the migration plan. If you cannot articulate what "done" looks like in a paragraph, you do not have a strategy yet. You have a project.

2. They Moved Applications, Not Servers

The second thing the winners did was organize the migration around applications, not servers. This sounds obvious, and it is not. The natural way to scope a migration project is by infrastructure — "we have 400 servers to move, let's do 50 per month for eight months." The better way is by application — "we have 50 applications, let's do them one at a time starting with the easiest, and for each one we will decide whether to retire, replace, rehost, replatform, or refactor it."

The difference matters because infrastructure-centric migrations miss the biggest wins. Every application portfolio has ten to twenty percent of applications that should simply be decommissioned — nobody uses them, the last user retired, the business process has changed, or the SaaS replacement is already in place. Infrastructure-centric migrations lift and shift those to the cloud instead of retiring them, because nobody asked the question. That is pure waste.

Application-centric migrations also force the hard conversations. "This application is five years past end of life, the vendor is gone, the documentation does not exist, and the last person who understood it retired. What do we want to do with it?" That conversation is uncomfortable, but it is the conversation that creates value. Delaying it by moving the server to the cloud just means you have the same conversation in three years, with a monthly cloud bill now attached to the problem.

The winners had an application portfolio review as phase zero. The losers had a server inventory spreadsheet.

3. They Built a FinOps Practice Before the Bills Got Big

The single most consistent pattern across customers who got cloud economics right is that they built a cost management practice on day one. Not a tool. Not a dashboard. A practice: a named owner, a monthly cadence of cost reviews, tagging discipline, budget alerts, and the authority to kill zombie resources.

The specific practices that work are boring and easy to copy. Tag everything with owner, environment, and cost center. Review unattached disks, stopped instances, and idle load balancers monthly. Reserve instances for predictable workloads once you have six months of usage data. Use savings plans for the parts of your footprint that are committed. Alert on spend anomalies daily. Make the bill visible to the people who can do something about it.

The failure mode is equally consistent. Customers who do not build FinOps early end up with a bill that is 40 to 60 percent above what it should be, and by the time they notice, the remediation is a quarter of work nobody wants to do. The resources with no tags belong to someone who left the company. The reserved instances they did buy cover the wrong families. The lift-and-shifted VMs are oversized because the original on-prem hardware was oversized and nobody right-sized during the migration.

FinOps is not a tool purchase. It is a practice. Build it on day one, even if it is just one person reviewing the bill for an hour every Friday.

4. They Kept Operations Skills On the Team

The pitch for cloud migration often includes "we can reduce our operations headcount because the cloud provider will handle everything." This is partially true for some services and dangerously wrong for others. Managed database services genuinely reduce the operations burden. Managed Kubernetes does not — it just moves the burden around. Lambda functions are low-ops until you have two hundred of them talking to each other, at which point they are just a different kind of ops.

The customers who got it right kept their operations skills on the team and redirected them. Instead of racking servers, the team was tuning cost, tuning performance, building automation, and owning reliability. They spent less time on the physical layer and more time on the parts of the stack that directly affected customer experience.

The customers who got it wrong cut their operations team during the migration, believed the cloud provider would handle everything, and discovered eighteen months later that they had no one who understood why their application was slow, why their bill was growing, or why their incidents were lasting longer than they used to. Hiring back that expertise at market rates took another year and cost more than the original team.

You need fewer people to run a cloud environment than a physical one. You do not need zero, and the people you have need to be more skilled, not less. Budget for that reality.

What We'd Actually Do

For a customer starting a cloud journey today, we would spend the first 60 days on target state definition and application portfolio review, the next 60 days on FinOps foundations and identity/security baseline, and only then begin moving workloads. We would pick the easiest applications first to build momentum and skills, we would keep hybrid as a default posture (not everything belongs in the cloud), and we would measure success in business outcomes, not in "percentage migrated."

Three Takeaways

1. Define the target state in a paragraph before you touch a single VM. If you can't, you are not ready.
2. Migrate applications, not servers. The ten percent you should retire is where the biggest savings live.
3. FinOps and retained ops skills are not optional. The cloud does not manage itself, and the bills get big faster than anyone expects.