Run AI adoption and legacy modernization as related investments with explicit dependencies. Approve a bounded AI use when its information, controls and operating support are adequate. Fund prerequisite repairs when they are necessary for that use. Keep the wider case for replacing an old system visible on its own merits.
An old system’s age does not settle what must happen next. A maintained application may support a useful new task. A modern application can still lack the reliable information or authority that another task needs. The sponsor’s job is to make those differences visible before committing people and money.
Give the proposed AI use a specific dependency
“Our legacy estate is holding back AI” could describe several problems. Staff might be unable to retrieve approved manuals. Stock information might arrive too late to support a customer promise. An unsupported application might require replacement regardless of any AI proposal.
These problems need different decisions. Keep the wider enterprise adoption strategy tied to the work you want to improve, then ask the system and process owners what that work actually requires.
Suppose Claire Bennett leads customer operations at an established industrial-parts distributor. The company is replacing its old order system. Meanwhile, her team proposes two uses of an assistant:
- Find a candidate replacement part. Retrieve the applicable pump manual and identify the part reference for an engineer to check.
- Promise a dispatch date. Tell a customer whether that part can be supplied from current stock, allowing for reservations and warehouse commitments.
The second use depends on facts the manual cannot provide. If the only available stock export omits allocations, a convincing answer could promise someone else’s part. Fixing that information route is a prerequisite for this proposed promise. It does not automatically require Claire to postpone testing permitted manual lookup until the entire order-system replacement is finished.
The first use still needs its own acceptance. Can an engineer verify the pump variant, applicable manual and part reference? Are the sources permitted and maintained? Use the data-preparation guide to examine those source requirements rather than treating a readable PDF as proof of readiness.
Two proposed uses have different dependencies
Test the bounded document task
Claire’s team retrieves an applicable pump manual. An engineer checks the variant and part reference. Source permission, currency and review remain acceptance requirements.
Resolve allocation information first
The available stock export omits reserved quantities. Keep this proposed promise on hold until the owner supplies an acceptable current information route.
For the program sponsor, the decision is where to place the next commitment. Commissioning a maintained manual collection and repairing an allocation feed are different pieces of work. Putting both under “AI foundations” would hide which proposed result each one enables.
Separate prerequisites from improvements with a wider case
A prerequisite is something without which the specific use cannot meet its acceptance standard. A broader modernization improvement may be valuable without being necessary for that use. Ask the owner to demonstrate the dependency, including an acceptable narrower alternative.
For Claire’s team, compare the commitments this way:
| Proposed commitment | What would justify it now | Decision owner |
|---|---|---|
Bounded manual-lookup trial | Permitted current manuals, checkable part references and a supported review route | Customer operations with the engineering reviewer and source owner |
Reliable allocation information | Dispatch promises cannot be accepted using the available stock export | Order-system and warehouse owners with customer operations |
Wider order-system replacement | Its own support, reliability, change or operating requirements, including any verified AI dependencies | Modernization sponsor and affected business owners |
Record the observable failure behind each request. “The export omits reserved stock” gives the technical owner something to resolve. “We need a modern data platform” describes a possible investment, with a much larger scope still to justify.
There may be no suitable smaller repair. The application might not expose the necessary information through a supported route, or the team might be unable to maintain that route safely. In that case, keep the affected AI use on hold while the necessary modernization proceeds. A narrower proposal is useful only if it still serves a worthwhile task at an acceptable standard.
Use the readiness evidence guide when people disagree about what is missing. Record what the evidence permits now, what remains blocked and who can change that conclusion.
Give temporary connections an owner and an end state
Coexistence can be a deliberate design. AWS’s strangler fig guidance describes replacing parts of a suitable application incrementally while other functionality continues to run. Its conditions matter: access to the existing code and a workable way to redirect requests are among the requirements it discusses. A packaged legacy product may not offer them.
The architectural option is a reason to investigate an incremental route, not evidence that a connection already exists. Ask the technical owner what the selected system actually supports.
In Claire’s case, a temporary route supplying allocation information could become work that survives much longer than expected. Someone must handle changed fields, update failures and the eventual move to the replacement system. The cost belongs in the decision from the beginning.
Microsoft’s anti-corruption layer pattern explains one way to translate between systems with different meanings and structures. It also identifies added latency, maintenance, consistency and retirement considerations. A translation layer can preserve separation while creating an additional service to operate.
Before accepting a temporary bridge, settle:
- Its business meaning. Which definition of available stock will Claire’s team receive, including reservations and units?
- Its operating responsibility. Who maintains it and resolves an incomplete or stale result?
- Its expected lifetime. Which replacement milestone should trigger review or retirement?
- Its exit evidence. What must work in the replacement route before the bridge can stop?
Avoid assigning the same small group an unlimited integration backlog alongside the replacement project. Make the competing demand on those people visible. If a temporary route would delay a necessary replacement more than its bounded benefit justifies, the sponsor can choose to wait.
Keep AI-assisted modernization separate from business acceptance
There is another relationship between these investments: developers may use AI to help understand or change the old software. That is distinct from Claire’s team using an assistant in customer operations. Progress on one does not establish readiness for the other.
In their January 2026 Thoughtworks account, Subhrajit Roy and Nick Hill described modernizing a fund-allocation dashboard. An early generated version used mocked data. Backend integration, authentication, authorization and extensive testing followed; expert review also improved the generated code. Their vendor account illustrates the work between a convincing demonstration and a production application. It does not establish a general return on AI-assisted modernization.
Preserve people’s knowledge of why the existing system behaves as it does. In an August 2026 Reddit discussion, a user describing earlier work with the older programming language COBOL recommended comparing old and new behavior using historical inputs where available. A reply in the same chain raised an important qualification: the old behavior may itself be wrong. These are unverified practitioner accounts, not a validation standard, but the disagreement makes the business decision clear.
A difference needs explanation; a match still needs an appropriate reference. For the distributor, an old rule might exclude damaged stock for a sound reason. Another rule might preserve a workaround that the replacement should remove. Have the responsible business owner classify those cases with the engineers. Neither a generated description nor an unexplained match settles the intended behavior.
Keep acceptance attached to the business result. Claire needs a defensible dispatch promise for the right part and customer, including the conditions that make the promise valid. A successful code conversion or attractive new screen answers a different question.
Make the next joint investment review concrete
Bring the adoption and modernization owners together around the proposed use, its unresolved dependencies and the next decision. They do not need to turn every small trial into a company-wide architecture program. They do need to agree when a local choice creates a shared obligation.
- Name the accepted result. Specify the employee task and who can judge it. For the distributor, manual lookup and a dispatch promise remain separate uses.
- Locate the blocking condition. Identify the missing information, supported access, capacity or control. Record evidence and any viable narrower route.
- Assign the next commitment. Choose a bounded trial, prerequisite repair, further investigation or deferral, with an owner and a review point.
- Review costs and the end state together. Include preparation, checking, temporary connections, support and replacement work. Agree when the old route can end.
Keep shared costs and benefits visible without assigning the whole modernization bill to one assistant, or claiming the same improvement twice. The AI ROI guide explains how to distinguish the benefit being measured from overlapping claims on it. A safer stock-information route might serve several workflows; identify those uses rather than inventing an allocation that makes one pilot look attractive.
When a replacement milestone arrives, revisit the temporary arrangement. Check whether it is still needed, whether the new route meets acceptance and whether people can stop maintaining duplicate work. Use the old-process retirement guide to make that an explicit operating decision.
Claire can then give each proposal an honest status: the manual-lookup trial has an acceptance route; the dispatch-promise use awaits reliable allocation information; the wider replacement retains its own investment case. That is enough clarity to make the next decision without pretending the whole estate must be ready at once.
Questions about AI adoption and legacy modernization
Must a mature company replace its legacy systems before adopting AI?
Not universally. Decide against the requirements of a specific task. A permitted manual-lookup trial may be feasible alongside an old order system, while a dispatch promise depends on reliable current allocations. Confirm the necessary sources, controls and operating support with their owners. Keep a use blocked when those requirements cannot be met through an acceptable route.
Which modernization work should come first?
Prioritize work that removes a demonstrated dependency for a worthwhile accepted result, alongside modernization needs justified by support, reliability or other business requirements. Ask what fails today and what evidence will establish that the repair is adequate. The commitment comparison keeps bounded trials, prerequisite repairs and wider replacement decisions distinct.
What if an old system has no suitable API?
Ask its owner which supported access routes exist and whether any can meet the task’s requirements. An application programming interface is one possible route, not proof of readiness by itself. A governed export might support some read-only tasks but be inadequate for a current stock promise. If no acceptable route exists, narrow or defer that use and assess the necessary modernization instead of improvising unsupported access.
How should we budget for a temporary connection?
Include building, maintaining, monitoring and eventually retiring it, together with the people’s capacity it consumes. State which workflows benefit and which replacement milestone should trigger review. Keep wider replacement costs visible separately and avoid claiming shared benefits more than once. A cheap initial demonstration does not establish that the connection is affordable to operate.
Can AI-generated code prove that modernization is complete?
Generated code alone cannot establish business acceptance. Agree the intended behavior, test relevant ordinary and exceptional cases, investigate differences and confirm the production requirements with the responsible owners. Matching old outputs can preserve an old mistake; changing them can break an intentional rule. Treat AI assistance as part of the engineering work and keep acceptance tied to the required business result.
