Migrating Workloads and Performance Issues in Public Cloud
This blog from ScotlandIS member Pulsant’s technology director looks at the costs and performance challenges involved in moving workloads to the public cloud.
When on-premises capacity runs short, public cloud tends to be the first option infrastructure teams reach for. It is quick to provision, removes the hardware procurement problem, and sidesteps the question of what to do with an ageing estate.
What it does not settle is whether migrated workloads will perform as the business requires once they are live in production, or whether the recovery design has kept pace with where services now sit.
Two pressures are making that question harder to defer. Memory costs have risen sharply, complicating hardware refresh for organisations still running significant on-premises infrastructure. And businesses that moved workloads to public cloud are increasingly finding that production performance does not match what testing suggested.
Here, Steve Spittal, Technology Director at Pulsant, offers his insights.
Why on-premises refresh is no longer straightforward
For infrastructure teams trying to add headroom to existing environments, the memory market has created a genuine constraint. Gartner forecasts DRAM prices will rise 125% across 2026, with no meaningful correction expected before late 2027. The Register reported in January that Samsung has already raised server memory prices by up to 60% and that, combined with 2025 increases, costs could nearly double by mid-year. AI infrastructure is consuming an outsized share of available memory supply, leaving enterprise hardware refresh competing for components at elevated prices with extended lead times.
Running out of on-premises headroom is a legitimate operational problem. Migrating to cloud to escape it is a reasonable short-term response. The difficulty is that urgency tends to compress the evaluation of whether public cloud is actually the right long-term home for each workload being moved.
Production reveals what testing does not
Performance problems after migration typically surface under real conditions rather than in controlled testing. Production volumes, live data, and the full web of service dependencies behave differently at scale. For latency-sensitive workloads in particular, the distance between where a service runs and where its users are located has a direct effect on response times that pre-migration benchmarks rarely capture.
Training workloads can stay in large, centralised environments, but inference demands proximity to users and data. IDC research vice president Dave McCarthy observed in December that edge computing will be required to address latency and privacy as AI shifts from training to inference. Deloitte’s 2026 technology outlook estimates inference will account for roughly two-thirds of all AI compute by year end, up from a third in 2023.
A workload can be well-provisioned and fully managed in a hyperscale environment and still sit too far from the users and data it serves.
Recovery planning stays with the customer, not the platform
Resilient infrastructure and a tested recovery plan are not the same thing. Microsoft’s shared responsibility guidance for Azure reliability states clearly that while the platform provides infrastructure availability, configuring and testing a disaster recovery strategy matched to specific business objectives remains the customer’s responsibility.
Recovery failures rarely stem from a complete platform outage. More often they come from failover processes that have never been tested at the right scale; recovery environments that are geographically remote from operations; or restored services that no longer reflect the production state the business depends on. Migrating a workload without revisiting the recovery design carries those risks forward.
“We speak to businesses regularly that assumed their cloud provider’s resilience model covered their recovery needs,” says Steve Spittal, Technology Director at Pulsant. “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.”
Placing workloads according to what they require
Hybrid infrastructure has come back into focus because most estates contain workloads with genuinely different requirements. A front-end service with unpredictable traffic spikes suits the elasticity of public cloud. A latency-sensitive application or AI inference workload may need to sit closer to users, because routing requests to a distant cloud region adds delay that real-time processing cannot absorb. A recovery environment needs geographic separation from production while remaining operationally reachable. Regulated data may need to be held in a jurisdiction that can be clearly evidenced to auditors. Treating all as equivalent, and placing them in the same environment by default, is where performance problems and recovery gaps accumulate.
Pulsant operates 14 UK data centres across a UK national footprint, giving businesses genuine flexibility over where workloads and recovery environments sit. For organisations with data residency requirements, a UK colocation model makes jurisdiction easier to demonstrate than infrastructure spread across hyperscale regions. Edge Fabric provides private, high-bandwidth, low-latency connectivity between sites and clouds, keeping a distributed model operationally coherent.
Public cloud has a legitimate role in most enterprise infrastructure strategies. The more useful question is which workloads belong there, and which need a private environment with tighter controls over data placement, performance, and recover.