The decision to move workloads to public cloud is often made under pressure. Memory costs are rising sharply, on-premises refresh is becoming expensive, and public cloud removes the procurement problem quickly. What it does not remove is the risk that workloads which performed acceptably in testing will behave differently once live.
Gartner forecasts DRAM prices rising 125% across 2026, with no meaningful correction expected before late 2027. Samsung has already raised server memory prices by up to 60%, according to The Register. For enterprise infrastructure teams trying to add headroom to existing environments, that creates genuine pressure to find alternatives quickly.
Public cloud absorbs that pressure cleanly, up to a point. The difficulty, as Steve Spittal, Technology Director at Pulsant, puts it, is that urgency tends to compress evaluation of whether public cloud is the right long-term home for each workload being moved.
Production environments expose what testing does not. Real-world volumes, live data and the dependencies between services create conditions that pre-migration benchmarks can struggle to replicate. For latency-sensitive applications, the physical distance between a cloud region and end users matters in ways that controlled testing rarely captures.
The same pattern is emerging with AI inference. Deloitte's 2026 technology outlook estimates inference will account for around two-thirds of all AI compute by year end, up from roughly a third in 2023. Unlike training workloads, inference requires proximity to users and data — routing requests through a distant cloud region adds delay that real-time processing cannot absorb.
Recovery design is a separate problem that migration decisions often carry forward unexamined. Microsoft's shared responsibility guidance for Azure reliability states clearly that configuring and testing a disaster recovery strategy matched to specific business objectives remains the customer's responsibility. Spittal describes the pattern he finds regularly:
"We speak to businesses regularly that assumed their cloud provider's resilience model covered their recovery needs. What they find when they test, or when they need to invoke a plan, is that the recovery environment is in a different region, latency is higher than expected, and the restored service does not perform in the way the business requires. Continuity planning has to start with what the business actually needs, then work back to where workloads should sit." — Steve Spittal, Technology Director, Pulsant
The argument for hybrid infrastructure follows from the workload analysis. A front-end service with unpredictable traffic suits cloud elasticity. An inference workload needing low latency may not. Regulated data with residency requirements may need to sit in a jurisdiction that can be evidenced to auditors. Performance gaps and recovery failures tend to accumulate where those distinctions are not made before migration rather than after.
To stay across the latest in cloud, AI and enterprise tech analysis from Compare the Cloud, subscribe to our weekly newsletter at https://www.comparethecloud.net/newsletter
