When organisations say they've 'moved to the cloud', they usually mean one of two very different things. Some have lifted and shifted , their workloads now run on cloud VMs instead of on-premises hardware, but the architecture, operating model, and scaling characteristics are unchanged. Others have gone cloud-native , rebuilding or refactoring their systems to exploit managed services, auto-scaling, and cloud-native primitives. The gap between these two approaches determines your elasticity, your operational burden, and ultimately, your ability to compete.
Defining the Terms Precisely
Cloud-hosted means your application runs in the cloud, typically on IaaS (virtual machines). You manage the operating system, runtime, and application stack. You benefit from cloud's economics , pay-per-use, rapid provisioning , but carry significant operational responsibility. Cloud-native means your application is architected to exploit cloud platform services: managed databases, serverless compute, auto-scaling groups, object storage, message queues. You consume capabilities as APIs. The platform manages scaling, patching, and infrastructure reliability.
The Hidden Costs of Cloud-Hosted Approaches
Cloud-hosted workloads appear cheaper on initial analysis. VM instances have predictable hourly rates and no licensing premiums over managed services. But this analysis misses the operational cost. Someone must patch the OS. Someone must configure auto-scaling. Someone must manage the database replication. Someone must respond at 3am when the VM's disk fills. For a team of 50 engineers, these hidden costs are easily $200K-$500K annually in engineer time , often more than the delta between IaaS and PaaS pricing.
When Cloud-Native Makes Sense
Cloud-native approaches pay off when: you need elastic scale (traffic varies by more than 3–5x between peak and trough), your team is small relative to operational scope (fewer than 2 ops engineers per 20 developers), you're building new capabilities rather than migrating existing ones, and you can tolerate some level of vendor dependency. The sweet spots for cloud-native: SaaS platforms, consumer applications, data processing pipelines, and any workload with highly variable load.
When Cloud-Hosted Remains the Right Choice
Cloud-hosted approaches remain appropriate when: you have regulatory requirements that mandate OS-level control, you run proprietary software that cannot be containerised or managed-service-ified, your workload has consistent, predictable load (and auto-scaling provides no value), or you're in a regulated environment where managed services haven't achieved the required compliance certifications. Many financial services and government workloads still legitimately belong in VM-based deployments for these reasons.
The Pragmatic Migration Path
For most organisations, the optimal path is not a binary choice , it's an incremental migration from cloud-hosted toward cloud-native over 12-36 months. Start with the highest-leverage, lowest-risk migrations: move self-managed databases to managed services (RDS, Cloud SQL, Cosmos DB), replace self-managed message brokers with managed queues (SQS, Pub/Sub), and adopt managed Kubernetes (EKS, AKS, GKE) rather than self-managed clusters. Each step reduces operational burden and moves the team toward more strategic work.
Avoiding the Abstraction Layer Trap
A final warning: some organisations adopt cloud-native patterns but wrap everything in abstraction layers to avoid vendor lock-in. The result is maximum complexity with minimum benefit. You get the operational burden of managing your abstraction layer without the simplicity of managed services. Our recommendation: for standard infrastructure (databases, queues, CDN), accept reasonable vendor dependency and use managed services directly. For application code and business logic, maintain portability. The value of cloud-native comes from letting the platform manage infrastructure , not from building infrastructure that happens to live in the cloud.