Organizations modernize legacy infrastructure for sound reasons: lower cost, better performance, elastic scale, stronger disaster recovery, and earlier ROI. Yet many find the move is not cost-effective, or that it obstructs the very transformation it was meant to enable. They finish the technical migration, but the savings never materialize, and they end up maintaining two environments instead of one.
The reason is rarely the cloud. Legacy systems cannot move cleanly because they are not encapsulated: their components are entangled through buses, APIs, connectors, and shared data into a dependency network no single team or vendor owns. The most dangerous dependencies live in the gray area between components, where each vendor’s piece works in isolation yet the integrated whole fails because nobody owns the path between them.
Migration fails when it is treated as a technology event rather than a change to how the business and its systems are structured.
The Impacts
Applied to an unencapsulated system landscape, migration produces predictable failures. Companies recreate the monolith in the cloud, lifting everything onto SaaS, customizing it region by region, and leaving processes and org design untouched, so the same tangle reassembles in a costlier place. And the data center will not die: a single missed gray-area dependency, a hardwired payment-processor or compliance connection that cannot be re-pointed, can force an organization to carry physical infrastructure for years.
The market is voting with its feet:
- 21% of workloads repatriated, often because applications were never refactored for the cloud (Flexera 2025) [1]
- 86% of CIOs planning to move some workloads back, the highest on record (Barclays, Q4 2024) [2]
- 85% of enterprises now say legacy systems block their AI adoption [4]. The same entanglement that strands a data center also strands the data and architecture modern AI depends on.
When the business case is funded by retiring the data center, one unowned dependency can erase the entire ROI.
Building on the November 2023 Conversation
This piece extends a November 2023 conversation in which LiminalArc’s Mike Cottmeyer and Dennis Stevens diagnosed the same problem: dependency is the obstacle, the gray area is where migrations fail, and organizations recreate the monolith when they move technology without changing the business. That diagnosis holds. What has changed since is the cure, not the problem. What was once invisible can now be made clearer with AI capabilities. Repatriation has moved from informal observation to measured trend, and AI has transformed the economics of the solution. What follows carries their thinking forward.
The Solution: Where to Draw the Boundary
If the problem is structural, the solution cannot be purely technical. It requires changing the operating model, not just the stack. What has always blocked that is cost and feasibility, which is exactly what AI now changes. But first, what makes a boundary real, and where does it belong?
The goal is to encapsulate: to give each component a boundary clean enough that it can change without breaking the others. What cannot yet be encapsulated has to be orchestrated by hand instead, and that orchestration is the cost the work sets out to reduce, not the aim.
Encapsulation is a property of the boundary, not of the technology that crosses it. A bus, an API, or an event stream can each either honor a real boundary or quietly violate one. What matters is whether a component can change behind its boundary without forcing changes on everything connected to it.
The question that matters is where a real boundary belongs, not which integration technology to use. Technology alone does not answer it; an API drawn in the wrong place leaks internals and orchestration just as a shared bus does, and the tangle returns with newer parts. The answer comes from the business. This is where domain-driven design earns its place: a bounded context is precisely that boundary, and the right place to draw it is around a sub-domain: a coherent slice of the business that changes for its own reasons, on its own cadence.
Encapsulate along sub-domain lines and the boundary holds, because the business itself has a seam there; encapsulate along arbitrary technical lines and the dependencies reassemble. The relationships between those contexts then become explicit and owned, closing the gray area no one previously held. The sub-domain is where business meaning and technical boundary coincide.
The AI Inflection
Agentic tools now map dependencies across hundreds of services and run impact analysis, surfacing the cross-system paths once found only at go-live. AI also documents poorly understood code and generates the test scaffolding the model depends on. Studies report 30–60% productivity gains on refactoring and 40–50% faster modernization timelines [3][5].
But AI amplifies whatever structure it is pointed at. Aim it at an unencapsulated monolith and it generates entangled, duplicated, insecure code faster, recreating the rat’s nest at machine speed. AI-generated code was insecure in roughly 45% of cases without explicit security instruction [3]. The gains appear only when AI runs inside a governed, small-batch, dependency-aware workflow.
The Real Outcome: A Changed Operating Model
Of the outcomes AI transformation is meant to deliver, better efficiency, new capabilities, and a changed operating model. It is the last that decides whether the first two endure. Realizing its value requires changing how the business operates: its processes, its decision rights, and above all its roles. A dependency graph that AI mapped in days is inert unless teams, funding, and accountability are restructured around the newly encapsulated capabilities. That means product owners accountable for outcomes rather than projects, and an explicit owner for the gray area that previously had none. Technology change without operating-model change recreates the old constraints.
The Change Model
Begin by stabilizing the system so its hidden dependencies become measurable, then decide deliberately where each decision belongs inside a team, one level up, or at the portfolio tier, pushing decisions up and to the left, early enough to inform budgets. Where a dependency cannot yet be broken, manage it with compensating controls: a deliberately heavier layer of governance and test scaffolding than the end state needs, run in small batches to keep delivery moving. These are scaffolding, not architecture. Like the framework around a building under restoration, they hold things together while the work proceeds and come down as each piece is encapsulated. Orchestration here is a means to an end: it is meant to fall away as boundaries become real, not harden into permanent overhead.
From there, sequence the move: inventory every dependency (AI-accelerated, human-verified); wrap complex, poorly understood logic in containers with disposable test scaffolding so it can move safely; lift and shift where pragmatic, then extract services one sub-domain at a time. Starting with the boundaries that most reduce cost or risk and retiring the surrounding orchestration as each becomes real; and plan for data gravity, treating migration as a series of moves rather than one event [6][7].
The Way Forward
Pulled together, the approach is one repeatable move, applied capability by capability, not as a single grand migration.
Stop migrating applications; start encapsulating capabilities. Modernize one sub-domain at a time, let AI make that affordable, and change the operating model and its roles in step — so cloud economics and AI-readiness are realized together, not traded against each other.
The LiminalArc Point of View
We believe most modernization fails for a single reason: it is owned in pieces. Vendors move the technology, consultants tune the process, and product teams chase features; the failures collect in the seams between them, in the gray area no one owns. Our conviction, formed over more than a decade of moving monolithic organizations toward composable ones, is that technology, organization, product, and business architecture are one system, and must change together. Incrementally, safely, and in small batches.
AI is the catalyst that finally makes this affordable. But a catalyst accelerates a reaction; it does not design one.
Pointed at an unchanged operating model, AI scales the mess. Paired with a disciplined change model, it is why we believe LiminalArc can move an organization to where it wants to be, realizing the cloud economics and the operating-model change together, without recreating the monolith it is trying to leave.
This post comes from our management consulting practice, which specializes in designing and implementing operating models that align governance, processes, and technology to drive measurable business outcomes.
References
[1] Flexera, 2025 State of the Cloud Report, via InfoWorld, “Cloud trends 2025: Repatriation and sustainability make their marks,” March 2025.
[2] Barclays CIO Survey, Q4 2024, as cited in CIO.com and industry coverage of cloud repatriation, 2025–2026.
[3] Altimi, “The AI-Powered Legacy Modernization Playbook,” March 2026 (citing GitHub, Google, GitClear, GitLab DevSecOps, Apiiro, and Gartner data).
[4] Entrans, “Legacy System Modernization Trends 2025–2026”; Gartner agentic-AI projections; Stack Overflow 2025 Developer Survey.
[5] Augment Code, “AI-Powered Legacy Code Refactoring: Implementation Guide,” updated February 2026.
[6] Dave McCrory, “Data Gravity – in the Clouds,” datagravitas.com, December 2010; definition corroborated by TechTarget.
[7] DataStackHub, “50 Cloud Migration Statistics for 2025–2026,” citing data gravity and cost as repatriation drivers.
