Cloud — Frequently Asked Questions
Honest answers on cloud adoption — whether it is cheaper, lift-and-shift versus refactoring, multi-cloud and lock-in, what drives the bill, and when staying on-premise is the right call.
The business case#
Is the cloud cheaper?#
Not automatically, and often not at all for a steady, well-understood workload that you already run efficiently on hardware you already own.
What the cloud actually sells is elasticity and time. You stop buying capacity for a peak you hit twice a year, you stop waiting weeks for hardware, and you stop staffing tasks — patching, replacing disks, capacity planning — that produce nothing a customer sees. If those matter to you, it is a good deal. If your load is flat and predictable and your team already handles infrastructure well, the arithmetic can go the other way.
Be precise about which benefit you are buying, because the cost case and the speed case lead to different architectures.
What is the most common reason a migration disappoints?#
Moving everything as-is and expecting cloud economics. A virtual machine that ran at 8% utilisation in your data centre costs the same in the cloud running at 8% — except now you pay monthly and visibly.
The savings come from what the move enables afterwards: right-sizing, shutting down non-production overnight, managed services that replace work, and retiring things nobody needed. Those are follow-up projects. Budget for them, or the business case stays theoretical.
How do we decide what to move first?#
Something real enough to teach you and small enough to survive being wrong. Not the most critical system, and not a toy nobody uses — the first has too much risk and the second teaches nothing about your actual constraints.
Start every assessment with the retire question. On most lists, a meaningful fraction of applications have no real users, and turning one off is cheaper than any migration pattern.
Migration approach#
Lift-and-shift or refactor?#
Usually lift-and-shift first, then improve — but with eyes open about what that means. Moving as-is gets you off the old platform quickly and separates two risks that are painful to debug together: "does it work in the new place" and "does the rewritten version work at all".
Refactor first when the application cannot run as-is, when its licensing follows it and is punitive, or when it is about to be substantially rewritten anyway.
What rarely works is refactoring during the cutover. When something breaks at 02:00 you need to know whether it is the move or the change.
How long should we keep the old environment?#
Longer than feels necessary, and with a fixed decommission date written down. Weeks, not days. Problems show up on the first month-end close, the first quarterly job, the first heavy usage day — none of which happen in the first 48 hours.
Then actually decommission it. The failure mode at the other end is paying for both for a year because nobody wanted to sign the shutdown.
Cost#
What actually drives the bill?#
Compute you forgot to turn off, data transfer — especially egress and cross-zone — storage that accumulates without lifecycle rules, over-provisioned databases, and non-production environments running at production size around the clock.
Notice that four of the five are ownership problems, not pricing problems. Tag everything with an owner and an environment from day one; without that, cost investigation is archaeology.
Why did our bill go up after we "optimised"?#
Common causes: logging and monitoring turned up during the migration and never turned back down; a managed service billing per request against traffic nobody had measured; backups retained indefinitely; or a caching layer added that reduced database load and added a whole new service.
Check the itemised breakdown month over month rather than the total. The total tells you that something changed; only the breakdown tells you what.
Does FinOps mean a tool?#
It means someone owns the number. A dashboard nobody is accountable for changes nothing. The useful minimum is a tagging standard that is enforced, a monthly review with the people who own the workloads, and a budget alert that reaches a human who can act.
Lock-in and multi-cloud#
How worried should we be about lock-in?#
Worried enough to keep your data portable and your core business logic free of provider-specific assumptions. Not so worried that you refuse managed services and rebuild them yourself — that is paying a permanent tax to insure against a move most organisations never make.
The heaviest lock-in is rarely a compute API. It is data gravity and the operational habits your team builds. Know your exit cost, write it down, and revisit it when it changes.
Should we run multi-cloud?#
Only with a specific reason: a regulatory requirement, a customer contract, or a genuine capability only available elsewhere. Multi-cloud for resilience usually delivers the lowest common denominator of both platforms, doubles the operational surface, and splits scarce expertise in half.
Most teams asking for multi-cloud want a stronger negotiating position or protection from an outage. The first is a commercial conversation; the second is usually better answered by using more than one region properly and testing failover.
What about hybrid?#
Legitimate and common — data that cannot move for legal reasons, hardware that is not amortised, latency-bound systems near a physical process. Design the boundary deliberately: what crosses, how often, how much it costs in transfer, and what happens when the link is down. The connection between the two halves is where hybrid architectures fail.
Operating#
What changes for the team?#
Infrastructure becomes something engineers change with code and a review, which is faster and requires more discipline. Access control, cost and configuration drift all become continuous concerns rather than procurement events.
Skills matter more than tools: the fastest way to a bad cloud estate is a team that was never given time to learn the platform, reproducing on-premise patterns with cloud pricing.
When is staying on-premise the right answer?#
When load is flat and hardware is already paid for; when data cannot legally leave a facility; when latency to physical equipment rules it out; or when the operations team is genuinely good at this and the migration would consume a year of capacity for a benefit nobody has quantified.
"Because everyone else is" is not a reason. Write the assessment, compare the numbers honestly, and be willing to conclude that some workloads stay where they are.