Public cloud is the default recommendation in most migration conversations, often correctly — but treating it as the universal answer produces predictable, expensive surprises for the specific workloads where it genuinely isn't the best fit.
Data gravity is the most common practical constraint: an application that processes large volumes of data alongside other systems that remain on-premises will pay for that separation twice over, in egress charges moving data out and in latency moving it back and forth for every transaction that spans the boundary. The economics only work if the workload's data genuinely belongs where you're moving it, not just the compute.
Latency-sensitive workloads tied to a physical site — manufacturing control systems, point-of-sale infrastructure, anything where a network blip has an immediate operational consequence — are a second category where a site-local footprint, whether that's Azure Local, a hyperconverged on-premises platform, or simply staying put, genuinely outperforms a public-cloud region that might be hundreds of kilometres away.
Licensing and commercial terms are the third, less technical constraint: some enterprise software licensing is structured in ways that make a public-cloud deployment materially more expensive than the on-premises equivalent, independent of the actual infrastructure cost, and that math needs to be run explicitly rather than assumed away.
None of this is an argument against public cloud generally — it remains the right answer for a large share of workloads, particularly anything that benefits from elastic scale or managed platform services. It's an argument for making the decision per workload, based on its actual constraints, rather than as a single organisation-wide destination decided once and applied uniformly regardless of what each system actually needs.
All technical perspectives