Integration Is a Flavor of Modernization

Isn't modernization supposed to mean rewriting the old system?

That's the assumption baked into most internal modernization conversations, but it isn't how the field's own reference framework is built. Gartner's application modernization framework lists seven distinct strategies, and Encapsulate ("leverage and extend the application's features by encapsulating its data and functions, making them available as services via an API") is the first one listed, sitting alongside Rehost, Replatform, Refactor, Rearchitect, Rebuild, and Replace as an equally legitimate option, not a placeholder for teams that can't commit to a "real" rewrite.

That distinction matters because of how the conversation usually gets framed internally: API integration gets treated as the thing a team does while planning the eventual rewrite, rather than a modernization strategy that can be the actual, permanent answer for a given system. Gartner's own list doesn't support that hierarchy. The choice among the seven is meant to be made per application, based on its risk profile and business value, not on which option sounds more thorough.

What does Encapsulate actually solve that the other six don't?

Encapsulate is the only one of the seven that leaves both the original code and the original data model completely untouched while still producing something new: a modern, callable interface. Rehost and Replatform move the application without meaningfully changing its interface; Refactor and Rearchitect change the code without necessarily changing what's exposed; Rebuild and Replace both discard the original implementation entirely: one by rewriting it, one by buying or building a substitute. Encapsulate is the strategy that lets a business-logic asset participate in a modern architecture (APIs, events, AI agents) before any decision has been made about whether that asset ever gets touched internally at all.

That ordering has a practical consequence: encapsulation is usually the fastest of the seven to deliver a working result, because it doesn't require understanding, let alone safely reproducing, everything the original code does internally. It only requires understanding what goes in and what comes out.

Why does this matter more right now than it did five years ago?

Because agentic AI has turned "expose it as an API" from a nice-to-have into the literal precondition for whether an AI agent can touch a legacy system at all. One analysis of Deloitte's Tech Trends 2026 research found that 60% of AI leaders now identify legacy system integration as their primary barrier to agentic AI implementation. The constraint has shifted from what a model can reason about to what it can actually reach. Gartner has gone further, predicting that 40% of agentic AI projects will be cancelled by the end of 2027, largely over exactly this kind of infrastructure constraint, and separate research puts the share of enterprises struggling to integrate AI with existing systems at 78%.

The mismatch is structural, not incidental. Legacy systems were built for batch processing and human terminal sessions; agentic AI needs real-time, structured, machine-callable access, and the two don't meet without something in between. As one chief data officer put it in a recent industry interview, if a platform's functionality is "buried and not exposed through the right set of APIs, and through a flexible set of microservices, it'll be hard to deliver agentic experiences," which is practically a definition of what Encapsulate is for. Related reporting on AI agent rollouts finds 70% of developers hit problems integrating agents with existing systems, and 86% of enterprises expect to need a tech-stack upgrade before they can deploy agents at all.

That's the "why now": Encapsulate was already the fastest of the seven strategies for reaching a modern integration surface. Agentic AI just turned reaching one into a precondition for a fast-growing category of new initiatives rather than an optional improvement, so the projects stalling out on "we don't have an API for that" are increasingly AI initiatives, not just digital-channel ones.

Why does the instinct to skip straight to Rebuild or Replace keep causing problems?

Because the constraints that make a full rewrite hard are getting worse while it's being planned, not better. The U.S. software industry had accumulated an estimated $1.52 trillion in technical debt by 2022, and organizations still commonly spend somewhere between 60% and 80% of their IT budgets sustaining what already exists rather than building anything new. Those numbers describe the environment a rewrite has to survive, not just the code it has to replace.

The workforce math compounds it. An estimated 220 billion lines of COBOL remain in active production, reportedly still processing around 95% of ATM card transactions, while roughly 10% of the COBOL workforce retires every year and the average COBOL programmer is about 55 years old. Sixty percent of organizations still running COBOL report that finding skilled developers is their single biggest challenge. A Rebuild strategy needs people who understand the original system well enough to verify the new one actually matches it. That's precisely the population shrinking fastest, at precisely the moment AI agents are raising the bar for what "connected" needs to mean.

None of this makes Rebuild or Replace the wrong choice. It means they're expensive, slow options to reach for by default, for systems where a faster strategy might deliver the same business outcome sooner.

Does the market actually bear this out, or is this just a risk-aversion argument?

The evidence points the same direction. One industry analysis of enterprise modernization spending puts approaches built around exposing existing systems through APIs (squarely Encapsulate territory) at roughly a third of overall modernization strategy share, and organizations report substantial returns from that kind of initiative: 288–362% ROI, with 58% reporting security improvements, 52% reliability gains, and 53% scalability gains after modernizing. Banks specifically report reaching new features roughly 50% faster after this kind of initiative. These figures come from aggregated industry survey data rather than a single controlled study, so they're best read as directional evidence of where value is actually landing, not a precise multiplier any specific project should expect.

How do you actually choose between the seven?

There's no strategy that's correct by default. The right one depends on whether the current code, the current architecture, or the current platform is the actual constraint you're trying to remove.

Strategy	What it does	Best for	Tradeoff
Encapsulate	Exposes existing code and data as APIs or events; nothing underneath changes	Getting a system into a modern architecture fast, before committing to its long-term fate	The original implementation's cost, complexity, and skills dependency don't go away. Only the access pattern changes
Rehost	Moves the application to new infrastructure unchanged	Fast exit from unsupported hardware or hosting	No architectural or interface improvement at all
Replatform	Moves to a new runtime with minimal code change	Similar to Rehost, plus platform-specific optimization	Still no structural improvement; limited to what the new platform allows unchanged
Refactor	Restructures code internally without changing external behavior	Reducing technical debt in code that's staying put	Requires deep, current knowledge of the existing code
Rearchitect	Materially changes the architecture to unlock new capability	Systems whose current design is the actual constraint	Higher effort and risk than Encapsulate; still preserves much of the original logic
Rebuild	Rewrites from scratch, preserving scope and specifications	Systems where the platform or language itself is the blocker	Requires proving new behavior matches old: the hardest thing to get right at scale
Replace	Retires the system for a new one, often bought rather than built	Commodity functionality with a mature vendor market	Least reversible; costly if requirements were mis-scoped upfront

For a system under active workforce and support pressure, Encapsulate is frequently the strategy that buys the most time and value per unit of risk, not because it's a lesser option, but because it's the only one of the seven that doesn't require the original system to be understood well enough to be safely reproduced.

A worked example: claims intake at a hypothetical regional insurer

Consider a hypothetical regional insurer (not a real company) running claims intake through COBOL programs on the mainframe, with adjusters and downstream systems both needing faster access to claim status than the current batch and green-screen access patterns allow.

A Rebuild strategy here means fully understanding and reproducing the claims logic (validation rules, status transitions, edge cases accumulated over decades) before anything ships. An Encapsulate strategy means a different sequence:

1. Map what the claims programs actually take in and return, without needing to trace every internal branch of how they get there.
2. Expose the relevant operations as governed APIs, so a modern claims portal, partner integration, or AI claims assistant can call them directly, while the COBOL keeps running exactly as it does today.
3. Let real usage tell you which programs matter most. API call volume and business priority, not a static audit, determine which claims programs are worth a deeper Refactor or Rearchitect effort later.
4. Reserve Rebuild for the few programs where the underlying platform is genuinely the constraint, not the default first move for the whole estate.

The insurer gets a modern claims experience, and a legacy estate an AI agent can actually call, without first resolving the harder, slower question of whether or how to eventually rewrite the COBOL underneath it. That question stays answerable later, on better information, instead of being forced upfront.

Why does the platform choice matter? Isn't Encapsulate just "go build some APIs"?

Because the naive version of Encapsulate quietly reintroduces much of what makes Rebuild slow. A team can start today with just low-level connectivity (MQ, CTG, IMS Connect, JT400), but those gateways only provide access. The enterprise team is still on the hook for interpreting legacy assets, handling copybook-defined datatypes field by field, building and documenting API contracts, testing each flow, and repeating that work across every program, transaction, and dataset that needs exposing. That's custom software development with extra steps, and it inherits the same skills dependency Rebuild has, since someone still has to understand the COBOL or RPG well enough to get the mapping right: for every single integration, not once.

Choosing a proven Encapsulate platform over hand-built connectivity isn't about reducing what gets exposed. It's about removing the parts of that work that don't need to be redone for every API: ready connectors instead of custom adapters per gateway, governed datatype and copybook handling instead of manual field-by-field validation, and a shared, contract-first delivery model instead of each new service becoming its own one-off engineering project. That's what keeps Encapsulate the fastest of the seven strategies in practice, rather than letting it quietly become its own multi-year integration program.

Where does a platform like OpenLegacy fit in?

This is the specific bet behind OpenLegacy's API Integration capability: Encapsulate as a first-class, permanent modernization strategy, built and packaged rather than assembled from raw connectivity each time.

Within that capability, the choice isn't one-size-fits-all either. OL CoreIQ and OL DataIQ generate direct System APIs straight from CICS, VSAM, DB2, IMS-DB, and DB400 assets: the simplest form of Encapsulate, for when a one-to-one API onto existing data or a program is all that's needed. OL Integration handles the more complex case: orchestrated, multi-step APIs that compose several programs, database calls, or terminal-screen journeys into one callable operation, via RPC flow methods and terminal Screens Flow, useful when the business operation being exposed doesn't map cleanly to a single existing program. OL Screener covers the same orchestration need for remote CICS/BMS and IMS/MFS map-based conversations specifically. OL AtomIQ and OL Code support the discovery and authoring work underneath both paths: analyzing COBOL and map source, and creating and testing the resulting API assets from the IDE. Contract-first design also matters specifically for the AI case: a documented, readable API contract is what lets an agent reason about what a legacy operation does, not just call it blindly.

That range is also what separates OpenLegacy's positioning from broader integration platforms like MuleSoft or IBM's own z/OS Connect, and from a from-scratch build on MQ, CTG, IMS Connect, or JT400: rather than a general-purpose connectivity layer, a z/OS-only API enablement product, or hand-rolled adapters per gateway, the pitch is Encapsulate done specifically for mainframe and IBM i, with ready connectors, governed datatype handling, and both the simple System API case and the orchestrated case covered from one platform, backed by roughly a decade of legacy integration experience.

The bottom line

Encapsulate isn't a consolation prize for teams that can't commit to a full rewrite. It's Gartner's own first-listed modernization strategy, chosen on its merits for the systems where it fits. What's changed is the urgency: agentic AI has turned having an API for a legacy system from a modernization nicety into the actual gate on whether that system can participate in a fast-growing share of new AI initiatives at all. For organizations facing that pressure alongside the same shrinking-workforce and rising-technical-debt trends as everyone else running COBOL or RPG in production, Encapsulate is frequently the fastest way to deliver real, measurable value now, provided the platform doing the encapsulating removes the custom-adapter, datatype-risk, and one-off-engineering costs that would otherwise make "just build some APIs" slow in exactly the same ways Rebuild is. The harder question of whether and when to Rebuild specific pieces can then get decided later, with better information than a static audit, or a stalled AI pilot, could ever provide upfront.