Every serious build we ship starts with a cloud-first premise: the system is designed for the public cloud, and any on-prem component is a conscious exception. The reason isn't cost, because the cloud isn't always cheaper. It's leverage. A cloud-first system compounds — you add capacity, regions, and compliance zones in hours, not quarters.
What cloud-first actually requires
A cloud-first architecture is boring on a good day. Stateless services behind a managed load balancer. State living in managed databases with managed failover. Networking expressed in code. Observability wired in from the first deploy. The discipline is in refusing to take shortcuts that tie your system to a server, a cron, or a person.
Where teams get stuck
Most migrations stall at the workloads with the ugliest state: a legacy monolith writing to a file share, a reporting stack that assumes direct SQL access, a scheduled job that hardcodes a hostname. We've found it faster to rewrite these during a migration than to lift-and-shift them forward and deal with the same problems in the new environment.
What to do this quarter
If you're still in the planning phase, pick one workload, not the easiest one, not the hardest one — the one that's blocking another team. Define what 'done' looks like in a written runbook. Give yourself ninety days. What you learn migrating that workload will shape how you do the next twenty.
