You don’t have to replace your old system to escape it

David Zey

Guest Columnist

May 4, 2026

Call it whatever your team calls it – the mainframe, the AS/400, the iSeries, the green screen, the old system.

IBM has renamed this technology several times over the decades, from System/38 to AS/400 to iSeries to IBM i, with mainframe variants running z/OS alongside.

The names have changed.

The pattern has not.

The system works.

It has worked for a long time.

In many cases, it runs the core of your business with a reliability that newer systems have not matched.

But it is also increasingly a ceiling.

New tools cannot easily connect to it.

Development is slow and specialized.

The people who know it best are, in many cases, closer to retirement than to their first day on the job.

And the backlog of things you want to do that the system cannot support keeps getting longer.

The instinct, when that ceiling gets low enough, is to replace everything.

A full migration.

A clean break.

For most mid-market companies, that instinct runs directly into a wall of cost, of risk, of timeline and of the unsettling realization that nobody has fully documented what the old system does.

There is a smarter path.

It does not require a big-bang replacement, and it does not require your legacy team to become cloud-native developers overnight.

It is borrowed from nature, of all places, and it starts at the roots.

The strangler fig

In tropical forests, the strangler fig begins its life in the canopy, not the ground.

A seed deposited high in an existing tree germinates there, among the branches and begins to grow.

For a time, it is fragile, drawing what it can from air and rain, alive but without a real foundation.

It sends roots downward, slowly, along the outside of the host tree, searching for the earth below.

When those roots finally reach the ground, something changes.

The fig is now drawing from the same soil, the same water, the same deep reserve of nutrients that has sustained the host tree for decades.

It does not take from the host.

It shares the same source.

And from that moment, it grows as a peer: two structures, side by side, drawing from common ground, each carrying its share of the canopy.

Over time, the fig becomes the stronger of the two.

Not through conflict, but through growth.

The host tree, older and slower to adapt, gradually yields.

The forest never loses its canopy.

There is no gap, no crisis, no day when everything changes at once.

The new structure simply becomes the one that is standing when the old one is ready to rest.

Without shared ground, the fig withers.

Without access to the data, the new system has no foundation and cannot become a peer, let alone a successor. 

Software architects have used this pattern as a metaphor for a generation, and it maps cleanly onto what mid-market companies face with legacy technology.

The ground is the data – the shared source that both the old system and the new one can draw from. 

Your DB2 tables, your VSAM files, your flat files and sequential datasets: they are not the problem to be solved. 

They are the foundation that makes the transition possible.

The strategy begins there.

Not with replacing the application, not with rewriting business logic, but with establishing access to the shared ground.

When the new system can draw from the same authoritative data as the old one, it can begin to grow alongside it.

Everything else follows from that connection.

Growing the new structure alongside the old

The path to the data layer varies by environment.

In some cases, it is a direct connection.

In others, a lightweight extraction step is needed first, and increasingly, that extraction code itself is something AI can write.

Either way, the destination is the same and the barrier to getting there is lower than it has ever been.

Once you have access to the data layer, the next step is building an orchestration layer outside the legacy environment.

A message queue, a workflow engine, an API gateway: the specific technology matters less than the function.

This layer receives work, routes it, manages dependencies and coordinates results between the legacy system and the modern services being built alongside it.

The legacy system remains authoritative – it just stops being the only place where work gets done.

For organizations that have hit throughput ceilings, this is where the pattern pays its most immediate dividend.

When the legacy execution model serializes high-volume processes, forcing everything through a single checkout point one transaction at a time, moving the orchestration layer outside allows parallel execution in modern infrastructure.

The bottleneck is relieved without rewriting the core business logic.

The fig grows alongside the tree, carrying more of the load, while the original structure remains standing.

AI as the control plane: Making the old system legible

Here is where modern AI tools change the equation in ways that were not available five years ago.

Legacy systems carry enormous institutional knowledge inside them, encoded in COBOL programs, RPG code, JCL scripts and VSAM file definitions written by people who understood the business deeply.

That knowledge is extraordinarily valuable.

It is also effectively invisible to modern tools, to new team members and to any system that has not been given access to it.

The first step in any serious modernization effort should be making that knowledge visible.

Not migrating it yet.

Just seeing it clearly.

And the starting point is simpler than most organizations expect, because AI does not require the data to be cleaned, normalized or reformatted before it can begin.

It just needs access.

Like the fig reaching fertile soil, the value is already there.

It simply needs to be reached.

What AI draws from that soil comes in three layers, each one adding depth to what we call the Book of Knowledge:

• Code and data definitions tell you what the system was built to do. COBOL programs, file structures, data dictionaries, dependency relationships: the architecture of intent.
• Logs and operational data tell you what the system does. Where it slows down, where it fails quietly, where workarounds have accumulated over years of daily use.
• Tickets and incident history tell you where the system has hurt people and how often. Recurring failures, escalations, the edge cases that only surface under specific conditions and that everyone on the legacy team knows to watch for. 

Together, those three sources give AI enough context to build something genuinely useful: not just documentation, but a prioritized, evidence-based map of where modernization efforts should go first.

Ranked by probability of impact, grounded in years of real operational data and depoliticized in a way that no internal planning process ever quite manages to be.

The data says what needs attention.

The room does not have to argue about it.

From that foundation, AI takes on a broader role than interpretation alone.

It helps design modernization strategies for both the old system and the new one, informed by everything it has learned about how the legacy environment behaves.

It proposes architecture for the new system that accounts for the edge cases, the recurring failure modes and the business rules that were never formally documented.

It also validates that the code being written honors the design, testing new implementations against the Book of Knowledge to surface discrepancies before they reach production.

I want to be direct because this can read like a promise.

Much of what I am describing comes from hands-on experience over the last two months working at the cutting edge of AI and AI agents applied to real business use cases.

For those paying attention, the way these projects get tackled has changed fundamentally.

The Book of Knowledge that once took a dedicated team quarters to incompletely assemble is now taking weeks, and it arrives more complete and usable than ever before. 

That is not a forecast; it is a current observation from someone doing this work.

What makes this manageable, and what I keep coming back to, is that the role AI plays is quite focused despite how much ground it covers.

Read. Design. Validate.

The AI control plane does all three, drawing from the same fertile soil that the legacy system has been rooted in for decades, without asking anyone to reformat it first:

• It tells the modern development team what they are building toward, without requiring them to learn COBOL.
• It gives the legacy team a way to validate that their expertise has been captured accurately.
• It becomes the reference layer that AI tools use when translating logic, routing work and generating new integrations between old and new systems.
• And it exists independently of any future technology decision. Even if the full migration takes five years, the Book of Knowledge is valuable on day one.

The human risk nobody puts on the project plan

Every organization running on a legacy system has a version of this person: the employee who has been there for 25 or 30 years, who knows exactly why a certain field is always blank on Tuesdays, why a particular batch process has to run before the overnight job, why a validation rule that looks arbitrary is actually protecting against an edge case that happened once in 1998 and will never happen again.

When that person retires, they take that knowledge with them.

The system keeps running until it does not, and nobody can explain why.

This is not a small risk.

It is one of the most consistently underestimated risks in mid-market technology operations. 

Traditional documentation processes have failed to address it, because asking a veteran to write down everything they know is an unreasonable request that produces incomplete results.

The expert who has been there for 30 years is not going to write a manual.

But they will answer questions, and AI can turn those answers into structured knowledge.

AI-assisted knowledge capture changes this.

A structured process combining code analysis, data profiling and expert interviews, with AI doing the synthesis and documentation, can surface and encode institutional knowledge at a pace and depth that manual efforts cannot match.

The veteran expert becomes a reviewer and validator, not the sole author of documentation they do not have time to write.

Think of it in terms of the fig metaphor: those veterans are part of the root system, too.

The institutional knowledge they carry is as foundational as the data itself.

The Book of Knowledge strategy captures both.

It is not just a migration asset.

It is a business continuity asset.

It is the difference between a retirement that leaves a gap and a retirement that leaves a record.

Two teams, one foundation

Legacy modernization projects fail as often due to team dynamics as to technology.

The legacy team feels threatened by a project whose goal is to replace what they know.

The new team cannot replicate business logic they do not fully understand.

The strangler fig approach resolves this by giving both teams a shared foundation to work from. The legacy team does not have to become cloud developers.

The new team does not have to reverse-engineer decades of undocumented behavior.

The orchestration layer and the Book of Knowledge become neutral ground where both teams contribute at their level of expertise, and where knowledge transfers continuously as part of the work rather than in a crisis when someone announces they are leaving.

There is never a cliff where one team is suddenly obsolete, and the other is suddenly overwhelmed.

The transition is managed, incremental and humane.

The companies that navigate legacy modernization well are not the ones with the biggest budgets or the most aggressive timelines.

They are the ones who ask the right question at the start: not how to replace the old system, but how to make what they know visible and start moving work to where it can grow.

The answer to that question is a strategy, not a project.

It is patient, incremental and grounded in the reality of what the business needs.

It is available to mid-market organizations willing to approach it that way, with the right partner, the right playbook and the willingness to start at the roots.

Inch by inch, life’s a cinch.

Yard by yard, life is hard.

The organizations that have successfully modernized from a legacy foundation did not do it all at once.

They found the shared ground first.

They grew alongside what was already standing, drawing from the same source, building structure gradually.

And when the transition was finally complete, there was no crisis moment, only the quiet realization that the new system had been carrying the weight for a while already.

AI does not replace the playbook.

It expands it, giving practitioners new plays that change what is possible on the field.

For organizations ready to use them, the opportunity is not just commercial.

It is a reinvention of what their teams are capable of.