From repatriation to replatforming: The cloud story no one wants to tell

I’ve walked into infrastructure review meetings expecting to talk about AI acceleration, only to spend the entire time on a different problem: Why the cloud footprint kept growing even though application demand had flattened. Teams had modernized aggressively. Platform leaders were confident, and contracts were up to date. Yet, spend curves no longer matched business growth.

More concerning, new AI workloads were forcing questions we thought had already been answered about where systems belonged. That shift changed how I think about cloud strategy. The issue wasn’t whether we were “cloud-first” or not. It was whether we had designed for movement at all. That was the moment I stopped treating workload placement as a destination and started treating it as a reversible operating capability.

When the cloud stopped feeling permanent

Early cloud programs were driven by urgency. On-prem provisioning was slow, capital cycles were painful, and engineering teams needed speed. Cloud solved those problems almost immediately. What it didn’t solve was discipline. We built for velocity, not longevity. Cost attribution lagged. Data gravity went unmeasured. Compliance controls were layered on after the fact, and once workloads stabilized, few teams revisited the original placement assumptions. Over time, cloud quietly shifted from a friction reducer to another fixed cost.

When I began mapping placement decisions to operational behavior, a pattern emerged. Only a fraction of workloads truly benefited from elasticity. Most were steady-state systems with predictable demand, fixed data gravity, and tightening regulatory requirements. IDC’s research on missed expectations in cloud computing validated our internal observations: most repatriation is selective, not ideological, with organizations moving specific workloads to improve cost predictability, governance, and operational fit rather than abandoning cloud altogether. That insight forced a reset. We weren’t reversing decisions; we were correcting assumptions. I no longer believe the cloud was wrong—permanence was the flawed assumption.

How AI and regulation rewired infrastructure assumptions

Nothing exposed the limits of default cloud placement faster than production AI. Early experimentation worked beautifully with burst training jobs, proof-of-concept pipelines, and ephemeral datasets. Once models moved into daily operations, the economics changed. Inference loads stabilized, data volumes exploded, and GPU utilization became a first-order variable. Teams found themselves paying for capacity that wasn’t elastic at all.

At the same time, regulatory expectations tightened. It was no longer sufficient to claim that data was encrypted or compliant. Leaders had to demonstrate where encryption keys were controlled, how cross-domain data flowed and which systems retained sensitive artifacts. Those were not policy questions. They were platform questions. BCG’s research on cloud sovereignty and governance mirrored this experience, showing that placement decisions are increasingly shaped by regulatory posture and operational waste as much as by technical capability. McKinsey’s analysis of AI-driven infrastructure demand further clarified what many teams were struggling to quantify: high-density compute behaves differently, with power efficiency, data locality and predictable utilization mattering more than theoretical elasticity. For us, hybrid stopped being transitional and became structural.

Turning replatforming into an operating capability

After the debate over workload location faded, the real work began. The priority shifted from cloud versus on-prem to enabling the organization to change its mind without starting over—and designing for reversibility.

To bring rigor without ideology, I began evaluating major systems across five dimensions: cost behavior under steady demand, data gravity and movement friction, compliance sensitivity, performance profile and operational maturity. The score didn’t dictate placement. It dictated attention, with systems showing volatile cost behavior or tightening regulatory exposure flagged for deeper replatforming investment.

Cost also became an architectural constraint. For years, cost management had lived in finance. That had to change. We embedded cost visibility directly into engineering workflows, so platform decisions were informed before spend occurred rather than after. McKinsey’s FinOps research reinforced this direction, arguing that sustainable cloud governance only works when cost controls are embedded in delivery pipelines rather than retrofitted during quarterly reviews.

We decoupled data from compute wherever possible, not just for portability, but to preserve placement optionality. Movement became expected, and we assumed workloads would move again and designed them accordingly.

To understand whether this was becoming a real operating capability, we also changed what we measured. Instead of tracking how many systems were “in the cloud,” we tracked placement reversals executed without incident, the time required to relocate high-value workloads, unit economics stability over six-month cycles, reductions in compliance exceptions tied to infrastructure , and AI workload cost predictability. Those indicators revealed whether replatforming was becoming a true operating capability rather than a one-time project.

What this all adds up to

Repatriation is not retreat. Replatforming is not indecision. Together, they signal maturity, not ideology. As 2026 approaches, outperforming organizations will be defined by how deliberately they decide and how easily they adapt as conditions shift. That is the cloud story no one wants to tell.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?