Why CIOs are moving their workloads back on-prem
Cloud repatriation is gaining ground as CIOs weigh cost, performance and control in deciding where individual workloads belong.

After many years of sending workloads into public clouds, a growing number of enterprises are bringing selected workloads back in-house, bucking a trend that until recently seemed irreversible. Today, CIOs and other IT leaders are repatriating certain workloads from public cloud back to on-premises or private cloud infrastructure.
The trend has nothing to do with cloud failure — it's a move toward optimization, enhanced performance requirements and greater strategic control.
While the cloud has brought convenience to managing infrastructure, data centers and hosting services, it never really saved money, explained Scott Miserendino, CTO at security services firm DataBee, a Comcast company. "Whatever efficiencies were gained were consumed as profit by the hyperscalers," he said.
Miserendino noted that achieving reliable cost estimation for cloud workloads has always been difficult, but with more workloads using larger data sets — often located in various cloud environments — cost estimates versus realized costs are diverging more drastically than ever. This is especially true for egress costs — the cost of moving data between workloads hosted by different cloud providers or within private cloud environments.
For the past decade, "cloud-first" was the default, said Kelly Raskovich, an associate director at Deloitte Consulting. That's changing, not because organizations are abandoning the cloud, but because they're becoming more deliberate about where workloads run, she said.
"I think of this as being 'cloud-smart,' placing each workload in the environment that best balances cost, performance, security and risk," Raskovich said.
The economics of moving workloads back
Cost predictability, or lack thereof, is a major transition consideration, Raskovich said. "Many enterprises have experienced sticker-shock from variable cloud operating expenses, particularly data egress charges and the ongoing cost of running steady-state workloads in a dynamic cloud environment." She noted that for applications with a consistent demand, an on-premises infrastructure can provide greater cost visibility and control.
Beyond egress fees and related costs, there are other obstacles that must be carefully weighed against the long-term benefits of moving workloads back on-premises.
Consider, for instance, the recent memory and RAM shortages, which have increased hardware costs significantly. There are also several one-time migration costs to consider, including building or expanding infrastructure, potential downtime during migration, data transfer costs, application remediation and IT training. These factors require careful planning and total cost of ownership analysis.
Move the workload, don't redesign it, advised Ran Aroussi, technical co-founder and CTO at VarOps, which builds and deploys AI systems. "Lift first, measure second and optimize third," he said. "Teams that combine the migration with an architecture rewrite can never tell which change caused which outcome."
Instrument carefully before you move, Aroussi said, because you can't prove a migration worked without a baseline.
"If you don't have a baseline for latency, cost-per-request, error rate and actual utilization, then after the migration, you're simply arguing about opinions," he said.
Moving back requires different skills
A shift back to on-prem fundamentally alters the skills your team needs, Raskovich warned. Over the last few years, engineers have been upskilled in cloud architecture, FinOps and cloud-native services. Repatriation, however, requires a resurgence of traditional infrastructure engineering, physical networking and hardware lifecycle management. This can cause anxiety among some team members who may feel that taking a step away from the cloud is a step backward in their careers.
"As leaders, we have to reframe this trend," she said. "Hybrid architecture is the future, and engineers who understand both cloud-native and on-prem environments are now some of the most valuable talent in the jobs market."
Self-hosting creates a lot of new work, and infrastructure management teams have gotten used to using the easy button, Miserendino said. Self-hosting also requires more thought be given to business continuity and technical failure resiliency.
"For some critical workloads, resiliency requirements necessitate multiple, geographically dispersed data centers, which can be difficult to manage and keep synchronized," he said.
"Hybrid architecture is the future, and engineers who understand both cloud-native and on-prem environments are now some of the most valuable talent in the jobs market." — Kelly Raskovich, associate director, Deloitte Consulting
Cloud for elasticity, on-prem for consistency, edge for immediacy
Raskovich stressed that cloud repatriation doesn't mean the cloud is going away.
"It reflects a more mature market and a more disciplined way of thinking about infrastructure," she said. "What we're now seeing is the normalization of a strategic hybrid model in which workloads are placed in the environment that makes the most sense financially, technically and operationally."
Raskovich believes that the future lies in a three-tier model, including the cloud for elasticity, on-premises for consistency and the edge for immediacy. "CIOs are no longer treating the cloud as an automatic destination, but rather as an operating model," she said. "We're finally positioning workloads where the technology best supports the use case."
Cloud computing was never the universal silver bullet, although it was often promoted as such, Aroussi said.
"The workload is now finding the place it should have been at, and for a lot of AI work, that place was never the public cloud," he said.
The question that should be asked now, Aroussi said, isn't on-prem versus cloud, but what data a system needs access to. "Answer that honestly, and the hosting decision usually makes itself," he said.





.png?width=800&auto=webp&quality=80&disable=upscale)


