What Moving to the Cloud Actually Means

The marketing version is a migration. The operational version is a re-plumbing of every dependency your workload has ever taken for granted.

The Physical Exchange

When a workload moves to a hyperscaler, the first thing that changes is custody of the metal. Your servers — or your colocation racks — are replaced by virtual machines running on hardware you will never see, in a building you will never visit, operated by a staff you will never meet. That is not a complaint; how a hyperscaler's datacentre differs from yours covers the operational gulf in detail. The point here is narrower: custody matters because every assumption your software makes about physical resources is now wrong.

On-premises, a virtual machine might share a host with three others. In a hyperscaler, it shares with dozens, on hardware generations you cannot choose and cannot pin. CPU clock speeds, NUMA topology, memory bandwidth — all of it varies between regions, between availability zones, and between successive launches of what looks like the same instance type. Software that was tuned to specific hardware will not perform identically. Latency-sensitive applications that relied on predictable L3 cache behaviour will notice first.

Storage changes more dramatically than compute. On-premises, even a virtualised workload typically reaches block storage over a fabric with bounded, observable latency. In every major hyperscaler, the default block device is network-attached: the volume sits elsewhere in the building, and every read and write crosses an internal network. The latency floor is higher, the variance is wider, and the throughput ceiling is an instance-level quota as much as a disk-level one. Your database's write-ahead log, your search index's merge operations, your messaging broker's persistence layer — all of them now run across a network call that used to be a local bus transfer.

The Networking Inversion

On a corporate network or in a well-run colocation, east-west traffic — server to server within the same environment — is essentially free and fast. Bandwidth is provisioned in bulk; there is no per-byte accounting for traffic that stays inside the rack or the building.

Cloud networking inverts this. Inside a single availability zone, VM-to-VM traffic is fast and unmetered within the provider's fabric. The moment you cross an availability zone boundary — which resilience architecture will eventually require — you pay per gigabyte. Cross a region, and the charge rises further. Leave the provider's network entirely, and you hit egress pricing, which is where organisations most reliably discover that their architecture has been implicitly subsidised by on-premises bandwidth they never had to account for.

The practical consequence: an application that was designed as a cluster of services chatting freely across a flat network now needs explicit topology awareness. Which services must be co-located in the same AZ to avoid inter-zone charges? Which calls are latency-sensitive enough that AZ separation is unacceptable regardless of cost? These questions do not appear in migration planning decks. They appear in the first billing cycle.

DNS and name resolution change too, in ways that sting quietly. On-premises, name resolution usually happens in milliseconds against an authoritative server on the same LAN. In a VPC, every DNS query hits the provider's resolver, which adds a small but non-zero hop. Applications that resolve hostnames inside tight loops — a pattern that works fine on a LAN — can accumulate meaningful latency. The fix is caching, which requires code changes, which means the migration is already not a lift.

The Dependency Chain

A workload is not a binary. It is a graph of dependencies: databases, caches, message queues, file shares, authentication services, certificate authorities, monitoring agents, NTP servers, and whatever internal APIs the application calls before it can serve its first request. Each of those dependencies has an assumed location, an assumed latency, and an assumed availability. Moving the application without moving or replacing the dependencies means that latency and availability are now determined by the weakest cross-environment link.

This is the operational version of what marketing calls "hybrid." In practice, hybrid frequently means an application in a cloud VPC making synchronous calls back to an on-premises database over a VPN tunnel, where the tunnel's latency, jitter, and occasional rekeying events are now part of the application's critical path. The database did not move; its response time did.

Authentication is a common pinch point. Many enterprise applications authenticate against an on-premises Active Directory or LDAP server. In the cloud, those calls now traverse a VPN or Direct Connect link. If that link degrades during a deployment or a failover test, authentication fails, and the application stops serving users — not because cloud infrastructure failed, but because a dependency the migration plan treated as background infrastructure is now load-bearing in a way it never was before.

The fix to all of this is to migrate the dependency alongside the workload, or replace it with a managed cloud equivalent. Managed databases, managed caches, cloud-native identity providers, cloud-native certificate management — these are the real migration work. The compute move is the easy part. Every team that has moved a non-trivial application says this, and every team that has not yet moved one tends not to believe it.

What Changes at the Control Layer

On-premises, infrastructure is configured by people walking to racks, or by automation talking to APIs your team built. In cloud, the control plane — the system that creates, modifies, and destroys resources — is a provider-operated API. That is simultaneously more powerful and more fragile in a specific way: the control plane and the data plane are separate, and they fail separately.

A running virtual machine can continue running while the EC2 or Compute Engine control plane is degraded. You cannot launch new instances, cannot resize, cannot reboot — but existing instances stay up. This split is important for understanding outage behaviour. What looks like "the cloud is down" from a monitoring dashboard may be a control-plane event that leaves your running workload intact but removes your ability to respond to it operationally. RTO planning that assumes you can always scale horizontally under load has a dependency on control-plane availability that is easy to miss.

IAM — identity and access management — is the control layer's control layer, and it deserves its own sentence. Every API call your infrastructure makes authenticates against IAM. A misconfigured role, an expired credential, or a permission boundary applied by a platform team without announcement can silently deny operations that worked yesterday. Unlike a hardware failure, which is usually loud, IAM failures often surface as timeouts or vague SDK errors that take time to diagnose correctly.

On a corporate network or in a well-run colocation, east-west traffic — server to server within the same environment — is essentially free and fast.

What It Actually Takes

The operational story of cloud migration is not about servers becoming someone else's problem. It is about re-examining every assumption a workload makes about its environment: where storage is, how fast the network is, where its dependencies live, and who controls the machinery that keeps it running. The compute move is visible and fast. The dependency re-plumbing is invisible and slow. The teams that plan for both tend to arrive at a working system. The teams that plan only for the first tend to discover the second under pressure.