Where should your cloud workloads really live?
Part 1 of 3: Repatriation and redistribution
Why it matters
- Cloud migration has outgrown the standard seven Rs framework
- The existing framework doesn't address today's multicloud sprawl, repatriation costs, or federal reauthorization timelines
- Cloud portfolios need ongoing reassessment as costs, requirements and mission needs change
Part 1 of the How Cloud Migration Outgrew the Seven Rs series, examining how today's hybrid, multicloud and mission-driven environments require additional migration strategies that complement the original framework.
Why the seven Rs of cloud migration need to evolve
Cloud migration conversations often begin with the familiar language of the “Rs”: rehost, replatform, repurchase, refactor/rearchitect, relocate, retain, and retire.
Gartner introduced the framework in the early 2010s, which included a five-strategy model for application migration (rehost, revise, refactor/rearchitect, rebuild, and replace). In the late 2010s, AWS expanded the model and refined the terminology, codifying the seven “R” currently in use.
The framework served as the model for how to categorize and rationalize movement, reduce ambiguity, and turn a complex transformation into a set of actionable paths.
But over time, useful frameworks can become limiting, lulling users into complacency until it quietly narrows the conversation.
As we’ve touched upon, cloud migration is more than deciding where an application should go. It must involve people, processes, visibility, and, ultimately, what the organization should become once it gets there.
That’s where the traditional seven R’s can start to feel incomplete.
Why modern cloud migration goes beyond the seven Rs
Simply put, the seven Rs were developed for a different era. Few could have anticipated today’s realities: industry organizations bring back workloads that turned out to be cheaper on-prem; portfolios spread across multiple clouds by accident rather than design; federal environments where reauthorization timelines dictate modernization schedules; integration layers that have outlived the applications they were built to connect; and workloads that require remediation before any migration strategy can even be applied.
In that sense, the seven R’s should not be treated as the end of the cloud migration conversation but rather as a starting point. As cloud strategies mature, organizations face decisions that extend beyond the original framework.
In this blog, we’ll discuss two additional R’s – repatriation and redistribution – and why they’re essential considerations in modern cloud portfolios.
What is cloud repatriation?
Repatriation is the decision to reinstitute a workload from the cloud to on-premises or private infrastructure. Economics usually factors in repatriation because the data that came in after the migration told a different story than the estimates that preceded it. Whether the cloud bill arrived and the egress fees were higher than expected, the reserved capacity commitment did not match actual utilization, or the licensing stack that was manageable on-prem became a different conversation when the cloud vendor's pricing was applied at scale, something dramatically changed.
When does cloud repatriation make sense?
To be clear, moving back to escape a poorly planned migration does not fix weak dependency mapping, cost governance, testing, or operating-model design. In fact, it only relocates those problems. Genuine repatriation starts with evidence and ends with a documented business case.
The hardest conversation is often cultural. The stakeholder who championed cloud may hear repatriation as repudiation. Instead, it should be framed instead as portfolio management: buying was right with yesterday’s information; selling may be right with today’s.
What is cloud redistribution?
Redistribution is the migration strategy for workloads already in the cloud but inaccurately placed. It describes rebalancing a multicloud portfolio, where you move a workload from one cloud provider to another because the compliance posture, pricing model, service capability, or authorization tier of the target provider better serves the workload's actual requirements.
How multicloud environments become complex over time
Realistically, multicloud isn’t a strategy that most organizations choose. It’s more of a fait accompli that’s often birthed from departmental autonomy, specialized tools specifically designed for a cloud, and/or acquisitions.
One team needed a specific analytics service. Another inherited a cloud environment through acquisition. A third chose the provider that solved the problem in front of them. Years later, the portfolio audit reveals three clouds, five regions, multiple tooling stacks, separate security models, overlapping contracts, and no single explanation for why the workload sits where it does.
When should organizations redistribute cloud workloads?
Every organization should ask if its current distribution is serving the workload, mission, and business case.
A workload may need a FedRAMP authorization level, data-residency posture, GPU capability, AI service, network model, or pricing structure that its current provider does not offer well enough. Or the organization may discover that operating three clouds is not three times as hard as operating one. It is closer to five or six times, because expertise, tooling, governance, security, billing, and incident response do not transfer cleanly across providers.
Redistribution is still a cloud migration
Discovery, dependency mapping, data movement, cutover, and decommissioning all matter. The difference is tooling, and cloud-to-cloud movement introduces its own friction: egress charges, cross-provider transfer timelines, compliance revalidation, and provider-specific services that do not translate neatly.
The infrastructure-as-code (IaC) layer is where redistribution projects either run smoothly or grind to a halt. An organization that invested in cloud-agnostic IaC tooling (i.e.,Terraform configurations that describe infrastructure in provider-neutral terms, deployment pipelines that can target multiple environments) finds that a cloud-to-cloud move is largely a configuration exercise. An organization whose infrastructure is expressed in provider-specific tooling faces a translation problem on top of the migration problem.
What are the risks of cloud redistribution?
A workload built deeply into one provider’s managed services may be portable in theory but it’s sticky in practice. The business case must include migration cost, retraining, tooling, transition overhead, and the new operating model. Be wary of chasing a cheaper monthly bill.
Good redistribution lands the workload in the cloud where it performs better, complies more cleanly, costs less to operate, and fits the portfolio strategy.
How cloud portfolio optimization becomes an ongoing process
Redistribution is part of a broader cloud modernization lifecycle. It begins with gaining visibility into your environment, continues with asking strategic placement decisions, and evolves through ongoing portfolio optimization. Regular redistribution reviews help ensure cloud investments remain aligned with changing mission and business needs. portfolio that’s consistently aligned with current requirements rather.
For federal and mission-focused organizations, these decisions are rarely just technical. They involve authorization timelines, data movement constraints, cost governance, operational readiness, and mission risk. Leidos helps organizations assess these tradeoffs across the full portfolio so migration decisions are grounded in evidence, not cloud orthodoxy.
Continue reading the How Cloud Migration Outgrew the Seven Rs series:
Part 1 | Repatriation and redistribution: Where should your cloud workloads really live?
Part 2 | Remediation and reauthorization: Preparing applications for continuous modernization
Part 3 | Reintegration and rightsizing: Optimizing cloud portfolios for long-term value
Three things to remember
- Repatriation reverses cloud moves when real costs—egress fees, licensing, capacity—contradict original estimates.
- Redistribute rebalances workloads across clouds when compliance, pricing, or capability needs outgrow the current provider.
- Multicloud usually isn't strategy—it's often accidental sprawl from acquisitions, autonomy, and one-off decisions.
