Optimizing cloud portfolios for long-term value
Part 3 of 3: Reintegration and rightsizing
Why it matters
- Cloud migration has outgrown the standard seven Rs framework
- Reintegration and rightsizing can improve cloud performance, efficiency and cost control
- Cloud migration success depends on what happens after workloads move
Part 3 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.
Reintegration: The cloud migration strategy nobody wants to own
The cloud migration framework tends to make the work sound cleaner than it is. Rehost. Replatform. Refactor. Retire, and so on. Each “R” is simplified, suggesting a concrete decision about an application. But migrations are rarely a straight line. In fact, most fail because those involved underestimated what happens between applications. After a decade of applications moving at a mixed pace into mixed environments, their connections and connectivity can become severely degraded, which ultimately determines whether the program succeeds or fails.
For that reason, we need another “R”. Enter reintegration.
Why cloud migration creates reintegration challenges
Reintegration is the strategy of connecting how systems communicate after the migration scattered them across cloud, on-premises, hybrid, and multicloud environments. It is not about moving the application itself, but rather rebuilding the connective tissue: APIs, message buses, data pipelines, scheduled jobs, file drops, authentication paths, brittle adapters, and silent dependencies that accumulated over the years.
Almost every meaningful cloud migration creates reintegration work. A workload moves to the cloud, but two of the systems it calls remain on-prem. A batch job starts writing to object storage, but the downstream consumer still polls a shared file path. A synchronous call that worked over a low-latency LAN suddenly crosses a slower, less predictable network path. An authentication pattern that assumed a shared security boundary breaks the moment one endpoint leaves the data center.
Individually, these look like configuration problems. Together, they reveal architectural gaps that traditional migration planning often overlooks.
That distinction matters because configuration is usually fixable - sometimes quickly. That’s not true with architecture. The most expensive reintegration failures are usually discovered during cutover when a team learns at 3 a.m. that system A cannot authenticate to system B. Or when a temporary adapter is the only thing holding a business process together. At that point, the problem is no longer technical debt. It becomes an operational, schedule, and mission risk.
How does cloud reintegration work?
Good reintegration works in layers. First comes transport: network paths, private endpoints, VPNs, express routes, gateways, and security boundaries. Then comes protocol: whether a synchronous call should become asynchronous, whether retry logic and circuit breakers are needed, whether chatty REST patterns can survive new latency. Finally comes contract: explicit APIs, versioned schemas, idempotency guarantees, and authentication patterns that allow systems to evolve independently.
Reintegration is product architecture. And that can be difficult because it forces organizations to discuss who owns the spaces between systems. In mature environments, that ownership is explicit; someone is responsible for the contracts, the patterns, the catalog, and the response when the connection breaks.
The tough talk(s): Why cloud reintegration needs clear ownership
In many enterprises, reintegration has grown informally, one point-to-point dependency at a time, until the architecture depends on pathways no single team governs. Each application team may make a rational decision for its own workload, yet the combined effect can be a portfolio that no longer functions coherently. That is why reintegration ownership cannot be an afterthought or a review function. It needs authority, funding, and a role in planning before migration waves are locked.
If no one owns it, then everyone pays for it.
Migration programs should weigh applications not only by internal complexity, but by integration density. A modest application with ten critical cross-system dependencies may be riskier than a complex application with few external edges. Wave plans that ignore those edges are not sequencing migration. They are sequencing breakage.
What good looks like is simple to describe and hard to achieve: documented paths, owned contracts, monitored integrations, clear failure modes, temporary bridges with expiration dates, and an integration architect with authority before wave plans are finalized.
The end state of cloud migration is bigger than applications running somewhere new. It is a portfolio whose connections are intentional rather than accidental. Reintegrate is the discipline that gets you there.
Now, let’s conclude the series with rightsizing, our final “R”.
Why rightsizing matters after cloud migration
As you know, cloud migration is a continuous process. Once workloads are moved, platforms stabilized, and legacy environments reduced, it’s easy to think the “hard work” is over. But if those workloads are left unsupervised, then the very premise of migrating to save money is undermined. That’s why we need to talk about rightsizing.
What is cloud rightsizing?
Rightsizing is the ongoing discipline of matching cloud resource consumption to actual workload requirements. Given the dynamic nature and size of workloads, it’s critical that we continuously monitor their use so we can answer the age-old question, “Where is that charge coming from?”
Why cloud migration doesn't end when workloads move
Most migration frameworks focus on where a workload should go and how it should get there. Rehost. Replatform. Refactor. Retire. Those are important decisions, but they are not enough.
Rightsizing keeps an eye on the ball, allowing teams to gauge its use and allocate an appropriate dollar amount that keeps it operating efficiently. Since most migration estimates are intentionally conservative, the cost of over-provisioning is considered as a line item that can be addressed later. But too often, later never comes. However, the bill always does.
What are the three cycles of cloud rightsizing?
A mature rightsizing practice works across three time horizons.
- Continuous optimization
Cloud-native tools and financial operations (FinOps) platforms monitor utilization, pricing, storage patterns, and reservation coverage. They generate recommendations for instance changes, storage tiering, scaling policies, and purchasing adjustments. In immature organizations, those recommendations accumulate unread. In mature organizations, they become part of a weekly optimization queue. - Quarterly architectural review
Teams look beyond individual recommendations and examine patterns such as which workloads have predictable peaks, which ones run idle overnight, and which batch processes need significant capacity over a burst of time, then require nothing. These observations could shape decisions regarding reserved capacity, autoscaling, and modernization priorities. - Annual portfolio review
Business conditions change. Applications generally grow, stabilize, shrink, or linger long after what’s required. An annual review asks whether the cloud resource model still reflects business priorities and gives you data to adjust now while planning for the future.
How FinOps supports effective cloud rightsizing
Engineering teams are often cautious about rightsizing for good reason. A recommendation based on average CPU utilization may look obvious until the application hits a P99 spike and performance collapses during a critical business window.
Rightsizing requires performance baselines, workload context, and validation before change. In keeping with FinOps practices, rightsizing works best when treated as an operating discipline shared by engineering, finance, and the business.
That said, it’s important to be open and transparent about which department is doing what.
A strong FinOps practice closes the gap by making cloud spend visible, understandable, and actionable. Engineers see cost as an operating signal. Finance understands the technical drivers behind the invoice. Business leaders can connect capacity decisions to business outcomes.
Rightsizing becomes most powerful when it stops being a cleanup exercise and becomes continuously integrated into how the organization manages technology investments.
Why cloud migration and optimization should work together
Different teams usually perform cloud migration and cloud optimization on different timelines, with different vocabularies and different budgets. It would be wise to end that practice. Migration gets the workload to the right place, while rightsizing keeps it operating correctly once it’s there.
Why the seven Rs are no longer enough for cloud migration
The seven Rs remain a useful foundation, but foundations are not finished buildings. Modern portfolios need a broader vocabulary, one that accounts for cost reality, authorization constraints, integration risk, remediation debt, and continuous optimization. By adding repatriate, redistribute, remediate, reintegrate, and rightsize, organizations are better positioned to use what they have and possibly anticipate what’s coming.
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
- Cloud migrations aren't static, so the framework and strategies that we use to discuss it must also expand.
2. If nobody owns reintegration, everyone pays for it—usually during a 3 a.m. cutover crisis.
3. Cloud migration without rightsizing is akin to moving the same waste to a fancier address.
