Lift and Shift Is Not a Cloud Strategy
Moving your servers to someone else's data centre changes who owns the hardware. It does not, on its own, change anything you actually care about.
The most common cloud migration is also the least rewarding: take the servers you have, recreate them as virtual machines at a cloud provider, repoint DNS, done. It is fast, it is low-risk, and it is frequently the right first move.
It also delivers almost none of the benefits people expect. You have the same architecture, the same maintenance burden, and the same scaling limits- now with a monthly bill instead of a capital purchase. Teams that stop here often conclude, reasonably, that cloud is expensive and overhyped.
The benefit was never the location. It was everything you can do once the infrastructure stops being physical.
What you are actually buying
Elasticity. On-premise capacity is sized for your worst hour and paid for during your quietest. Cloud capacity can follow demand- but only if the application can scale horizontally. A single monolithic instance with local session state cannot, no matter where it runs. Elasticity is an architectural property that the cloud enables; it is not a service you subscribe to.
Managed services. The strongest argument for cloud, and the most neglected. A managed database handles patching, replication, failover, and backups. Your team was doing that work- competently, and at the cost of not doing something else. Handing it over is not laziness; it is a decision about where your engineers' attention is scarce.
Delivery speed. If deploying takes an afternoon and a maintenance window, you deploy rarely. Deploy rarely and each release is large, which makes each release risky, which makes you deploy even more rarely. Proper CI/CD breaks that loop. This is often the single largest practical gain of a migration, and it has nothing to do with servers.
Visibility. Centralised logs, metrics, and traces turn "the site feels slow" into a specific query against a specific service. Most teams discover on day one that a problem they had normalised for months was trivially diagnosable.
Decide per workload, not per company
"Should we move to the cloud" is unanswerable. "What should we do with this system" has a real answer, and it differs by system.
Some things should be rehosted- moved as-is because they are stable, unremarkable, and not worth touching. Some should be replatformed- same application, but the database becomes a managed service and the file storage becomes object storage. Some should be rebuilt, because the constraint you are fighting is in the design and moving it changes nothing. And some should be retired, because the review will reveal at least one system that two people use for a report that is also produced elsewhere.
That last category is more common than anyone expects, and it is free.
Cost is a design outcome, not a plan
Cloud bills surprise people, and the surprise is usually architectural rather than commercial. Environments left running overnight. Data transferred across regions unnecessarily. Instances sized for an anticipated peak that never came. Storage tiers that never got tiered.
The fix is neither heroic negotiation nor abandoning the platform. It is tagging resources so you know what belongs to whom, setting budget alerts before the invoice arrives, right-sizing on evidence rather than instinct, and switching off what nobody is using. Cost management is an engineering practice with a finance interface- treat it as either alone and it drifts.
Measure before you move
The most valuable week of any migration is the one spent before it: establishing what current performance actually is, what the system genuinely depends on, and which of those dependencies nobody has documented.
Without that baseline, "is it better now?" becomes a matter of opinion- and opinion is a poor foundation for the next decision.
