Why Enterprise AI Stalls on Legacy Systems, and How OpenNash Modernizes Them

Enterprise AI stalls on legacy systems because the systems give AI no context. They have no API, no documentation, no access for new tools, and no logs. The fix is a foundation layer that makes the old system readable, then a step-by-step rewrite that proves each new part works before it takes over. OpenNash does this with a forward-deployed engineer (FDE) on your team and OpenNash Software Factory, our coding agents for legacy code.

Why Enterprise AI Fails on Old Systems

Gartner found that 63% of organizations do not have, or are not sure they have, the right data management practices for AI. It predicts that through 2026, organizations will abandon 60% of AI projects that lack AI-ready data (Gartner, February 2025).

The model is rarely the problem. An agent can only act on what it can read and call. Anthropic's engineering team calls context "a finite resource with diminishing marginal returns" (Anthropic, Effective context engineering for AI agents). An old system gives the agent almost none of it.

The same gaps block modernization. AWS lists code base access as the first requirement of the strangler fig pattern. In its words, "You cannot intercept calls without code base access" (AWS Prescriptive Guidance, Strangler fig pattern). So the first work is the same for an AI project and for a rewrite. Build the foundation layer.

The Foundation Layer Comes First

The foundation layer is the set of interfaces that let people, agents, and new code see and use the old system safely. It leaves the old system in place and makes it visible to new tools.

The foundation layer pays off before any rewrite. Once an agent can read orders, inventory, and claims through a governed tool, teams can automate work on top of the old system. For more on this layer, see data and context engineering for AI agents.

Most of the Work Is People

The code is the fast part. The slow part is learning what the system must do. That knowledge sits with subject matter experts (SMEs) in finance, operations, and IT, and they rarely sit in the same meeting.

An OpenNash FDE works inside your team, on site when it matters. Most of the FDE's time goes to these jobs:

1. Interview the SMEs. Ask each expert to walk through real cases, including the exceptions they fix by hand.
2. Run the cross-functional meetings. Put finance, operations, IT, and security in one room to agree on rules, owners, and edge cases.
3. Turn answers into artifacts. Each meeting ends with updates to the rule register, the golden datasets, or the acceptance criteria.
4. Get access. Work with security and IT to approve read-only access, service accounts, and audit logs.
5. Close the loop. Show each SME the differences the parallel run finds, and record their decision.

Agents make this faster. They read the code and draft the system map before the first interview. The FDE then asks better questions, and the SMEs correct a draft instead of starting from zero.

The OpenNash Modernization Process

We do not replace the whole system at once. We use the strangler fig pattern. A routing layer sends one function at a time to the new code. The old system keeps running everything else (Martin Fowler, Strangler Fig).

1. Embed. An FDE joins your team. In week one we agree on one bounded target with a measurable result, such as an inventory reconciliation or a pricing engine.
2. Discover. Software Factory agents read the code, schemas, jobs, and interfaces, and draft the system map. The FDE checks it with the SMEs.
3. Build the foundation layer. Read-only access, event capture, governed tools, and golden datasets.
4. Pin the behavior. Turn the golden datasets into tests that record what the old system does today, right or wrong.
5. Decide what to keep. The business owner marks each known defect in the rule register as "keep" or "fix". A matching output is not always a correct output.
6. Rewrite one slice. Software Factory writes the replacement through your own CI and code review. Nothing merges until it passes the tests.
7. Prove it. Run old and new side by side and compare every output. Prove the rules that move money for every input.
8. Cut over in steps. Move a small share of traffic first, keep a tested rollback, and widen when the numbers hold.
9. Retire and hand over. Switch off the old component, measure the savings, and hand your team the code, the tests, and the evidence.

The first target matters. These are the ones we rank highest for a first project:

A worked example: a distributor runs inventory on IBM i, with CSV exports, Excel macros, and nightly transfers. We would not replace the ERP. We would expose inventory and orders through a read-only API. Then we would rebuild the nightly reconciliation as a new service and compare its results with the current process each night. Operations gets a dashboard of exceptions, the ERP does not change, and the manual reconciliation stops.

What You Get in the First 4-8 Weeks

OpenNash puts the first workflow, team, or codebase into production in 4-8 weeks. For a legacy modernization, the first weeks deliver these results:

1. One legacy system your AI tools can use. Governed, read-only access, with every call logged. Your teams can ask questions of the legacy data the same week it goes live.
2. A plain-language map of what the system does. The business rules, who owns each one, and the manual work around them.
3. One quick win in production. For example, a dashboard of reconciliation exceptions, or an agent that answers order and inventory questions from the legacy data.
4. A ranked list of modules to modernize. The yearly cost of each one today and the expected savings after it moves.
5. A business case for the first wave. Costs, savings, payback, and the exit criteria your finance and audit teams agree to before any cutover.

The Business Case: One Module, Then the Program

Start with the unit economics of one bounded module. The numbers below are an example, not industry averages. Replace them with your own.

1. Old system costs a year: $500k maintenance and support, $120k manual work, $50k infrastructure. Total: $670k.
2. New system costs a year: $90k. Net savings: $670k - $90k = $580k a year.
3. One-time cost: $220k for the foundation layer, rewrite, and verification, plus $50k for the parallel run and cutover. Total: $270k.
4. Simple payback after cutover: $270k / ($580k / 12) = 5.6 months.

Savings start at cutover, not at kickoff. If the work takes six months, payback lands near month 12. One module earns about $1.2M of net cash in three years. That is a good result, but the larger return comes from many modules.

The program compounds

A large enterprise runs hundreds of legacy applications. The money is in a program that moves them in waves. Each wave moves more modules than the last, and each module costs less, because it reuses what earlier waves built:

• The foundation layer is already in place. Access, event capture, and governed tools are paid for once.
• The rule register and golden datasets grow. Later modules share customers, products, and ledgers with earlier ones.
• Software Factory reuses its work. Tests and comparison checks carry over from module to module.
• The people know the process. SMEs know what a "keep or fix" decision needs, and security already approved the access pattern.
• Savings fund the next wave. Each cutover adds monthly savings that pay for the modules still in flight.

This example program moves 21 modules in five waves. Program modules are larger than the single-module example, such as mainframe-licensed workloads, so each one costs and saves more. We assume each saves $1.5M a year net, counting license and mainframe costs, support staff, and manual work. The foundation layer costs $1.5M, spent in the first six months. Each wave builds in the six months before its cutover.

The results, computed month by month:

1. Peak cash outlay: $2.75M at month 12. The program spends $9.8M in total, but savings from earlier waves pay for most of the later ones.
2. Break-even: month 23.
3. Run-rate savings after the last wave: $31.5M a year (21 modules x $1.5M).
4. Cumulative net cash: $24.0M at month 36 and $55.5M at month 48.

The program is cash negative until month 23. After the last wave, it gains about $2.6M a month. A company that stops after the first module stays on the lower line.

The one-time costs in these examples are your side of the program: internal team time, infrastructure, and running both systems during the overlap. OpenNash's fee is a flat monthly amount, month to month, with no consulting hours.

Two more effects are not in that figure. First, the foundation layer keeps its value after cutover, because agents and dashboards keep using it. Second, the expected cost of incidents falls. Say a reconciliation failure has a 5% yearly chance of costing $1M. If the new tests cut that chance to 1%, the expected loss falls by $40k a year for that module. Multiply by your module count, using your own incident history.

How We Take the Risk Out of a Rewrite

The goal is less risk at cutover. Two checks give the evidence. A parallel run shows that the new code matches the old code on real work. Formal verification shows that the new code obeys a stated rule for every input. A business owner then confirms the rule is right.

Old and new run side by side

In a parallel run, the old system stays the authority. Each request goes to both systems with the same ID. The caller gets the old system's answer, and a comparator records every difference. GitHub's Scientist library works this way: it runs the old path and the new path, always returns the old result, and publishes mismatches (github/scientist).

Three problems break parallel runs. We plan for each one:

1. Side effects. Do not charge a card, send an email, or move inventory twice. Scientist's own documentation says it "is only safe for wrapping methods that aren't changing data." For writes, the new system runs against an isolated copy, or it computes the result without applying it.
2. False differences. The two systems can give the same answer in a different order, format, rounding, or timestamp. The comparator must ignore these and report only real differences.
3. Different state. If old and new read different snapshots of the data, they disagree for reasons unrelated to the code. Record the input version with each comparison.

Set the exit criteria before the run starts. Without them, nobody can say when the run is done. A typical set:

• Zero unexplained differences in money, quantity, or status fields.
• Coverage of at least one month-end and one quarter-end close.
• Each known difference marked "keep" or "fix" by its business owner.
• Peak-load performance at or above the old system's.
• A tested rollback, with a named owner.

The rules that move money are proven

A parallel run only covers the inputs that occur during the run. Formal verification covers every input. For Rust code, the Kani model checker either proves a rule or returns the exact input that breaks it (Kani Rust Verifier).

A discount rule shows why this matters. Say the first version passes ordinary unit tests. Kani still finds two faults. A percent above 100, for example from a bad promotion table, makes the price calculation fail. A very large price overflows the arithmetic. After the fix, Kani proves that a discount never raises the price, for every possible price and every percent value.

Capping the percent at 100 is a business choice. The business owner decides whether to cap or reject a bad percent, and the rule register records it. The same method proves other rules. For example, a claim payout never exceeds the policy limit, and an order never ships more units than are on hand. For a longer walkthrough, see formal verification for AI agent output.

Save these heavy checks for code where an error costs money: ledgers, claims, pricing, and inventory. For an ordinary internal screen, integration tests and a staged rollout are enough.

The evidence report

Each engagement keeps one evidence report up to date. Engineering leaders, finance, and auditors read the same document, so everyone makes the cutover decision from the same facts.

Choosing the Target Language

The cheapest rewrite is often no language change. A Java 8 to current Java upgrade, or .NET Framework to modern .NET, keeps the libraries, the team skills, and most of the tests. Change the language only when the component gains something clear from it.

Go is our default for business services, integrations, and batch work. It is simple, fast to build, and easy for your team to maintain after handover. CISA and its partner agencies list Go as a memory safe language (CISA, The Case for Memory Safe Roadmaps).

Rust is our choice where security and performance matter most: replacements for C and C++, parsers of outside data, and low-latency systems. Google estimates about 0.2 memory safety vulnerabilities per million lines of Android's Rust code. Its C and C++ code had close to 1,000 per million lines (Google Security Blog, Rust in Android, November 2025). The same post reports a rollback rate about 4x lower for medium and large Rust changes.

Rust also suits coding agents. Its compiler rejects whole classes of memory and concurrency bugs before the code runs. The agent gets an exact error to fix (The Rust Programming Language, Fearless Concurrency). The compiler does not check business logic. That is what the parallel run and the proofs are for.

Questions Buyers Ask

Is it secure? We build in your cloud or on-premises environment. Access starts read-only. Every agent has SSO and role-based access, and every read and tool call is logged. Changes merge only through your own code review.

Who owns the result? You do. The code, tests, tools, rule register, and evidence report are yours at handover.

How is it priced? Software Factory runs on the same flat monthly fee as every OpenNash offering. It is month to month, with no per-seat pricing and no consulting hours. You can pause or cancel at any time. When the work needs people in the room, we fly out at our own cost.

Why not do it in-house or with a large integrator? Your engineers keep running the business. The FDE and Software Factory do the discovery, rewrite, and proof work with them. You get one active workflow at a time, live in 4-8 weeks, without a multi-year statement of work.

We already license a migration tool, such as AWS Transform. We are vendor-neutral and work with the tools you already license. Code conversion tools speed up one step. The FDE work around them is the SME interviews, the keep-or-fix decisions, the parallel run, and the cutover evidence.

When This Approach Is the Wrong Choice

• The old system is stable and cheap. An IBM i system that runs orders reliably may need an API, not a rewrite.
• The business cannot name an owner for the rules. Without someone to decide "keep" or "fix", the parallel run produces differences nobody can close.
• The target is the whole ERP. Start with one interface or one pipeline, and use its results to plan the next one.
• No one can get access. If security will not approve read-only access in the first weeks, fix that first. Nothing else moves without it.

Modernize Your Legacy Systems With OpenNash

Most companies that want value from AI first need systems that AI can see and use. OpenNash puts forward-deployed engineers on your team, and we work with Fortune 2000 companies. OpenNash Software Factory does the coding agent side of the work. It maps legacy code, pins its behavior with tests, and modernizes it through verified pull requests.

A typical engagement:

1. Embed an FDE with your team, on site when it matters, to interview SMEs and run the cross-functional meetings.
2. Build the foundation layer: governed read-only access, event capture, AI tools over your systems, and the business rule register.
3. Ship a first win in 4-8 weeks and a ranked, costed list of modules to modernize.
4. Modernize the first module with Software Factory through your own CI and code review.
5. Prove it with a parallel run and proofs of the rules that move money, recorded in the evidence report.
6. Cut over in steps with a tested rollback, retire the old component, and measure the savings.
7. Scale to a program in waves, so each module costs less than the last.

Book a call with an OpenNash forward-deployed engineer or email us at hello@opennash.com. In the first session, we review the legacy systems behind your top AI use cases and pick the first target. Then we show you which modules deliver the highest business value and the fastest ROI.