An enterprise application has been running for 30 years. It still processes orders, calculates payments, or moves information between systems the business depends on. Everyone agrees it would be useful to modernize it. Nobody wants to be responsible for breaking it.
The last estimate put the project beyond what the organization could justify. Much of the cost came from figuring out what the application actually does. Documentation was incomplete, business rules were scattered across programs, and the people who understood the original design had moved on. Leaving it alone became the practical decision.
AI gives leaders a reason to revisit that estimate.
Faster code generation is part of the opportunity. For large legacy systems, however, AI-assisted analysis can be just as consequential. Making existing behavior easier to understand can change the cost of discovery, implementation, and validation—and bring previously unaffordable projects back into consideration.
My recommendation is to change how we estimate and validate modernization projects. Reassess the expensive assumptions, measure what AI changes in your environment, and use that evidence to decide what deserves investment.
The Cost of Understanding Deserves a Fresh Look
When we discuss software development costs, implementation gets most of the attention. How many developers will we need? How many months will the rewrite take? What will the replacement platform cost?
With a decades-old enterprise system, those questions can be premature. Before a team can estimate the replacement responsibly, it needs to understand the behavior it must preserve, the dependencies it must accommodate, and the business processes it could disrupt.
Consider a hypothetical billing application. A late-payment rule might depend on customer classification, an exception table, a date calculation in a shared routine, and a nightly job that updates account status. Reading the billing program alone would give you an incomplete explanation. Translating that program into a newer language would carry the same incomplete understanding into a different technology stack.
AI can help teams navigate that work by explaining unfamiliar code, identifying candidate business rules, and producing documentation for review. Microsoft’s published COBOL modernization approach illustrates agents analyzing business logic, mapping dependencies, and coordinating code conversion through agentic AI. It is an engineering example to evaluate and adapt, rather than a guarantee of automated modernization for every mainframe workload.
That creates an opportunity to reduce work that previously required extensive manual investigation. The size of the reduction will depend on the codebase, available artifacts, tools, and review effort. A capability demonstration establishes that a tool can help; a measured pilot establishes whether it changes your business case.
Turn Undocumented Logic Into Reviewable Evidence
One of the most valuable uses of AI in modernization is translating logic that exists only in code into something developers and business stakeholders can discuss.
But an explanation needs evidence behind it. For the hypothetical billing system, a useful deliverable would identify the rule, its source locations, the data it depends on, the conditions that trigger it, and representative examples. It should also identify missing inputs and unresolved questions.
Suppose the analysis reports that a certain customer category receives an extended payment period. A business owner should be able to trace that statement to the relevant code and configuration, then compare it with actual transactions. If the explanation depends on a missing utility or an unavailable reference table, that uncertainty belongs in the deliverable.
Code reveals implemented behavior. It does not necessarily reveal why the business wanted that behavior, whether the rule remains valid, or whether customers now depend on an accidental quirk. Those questions still need people who understand the domain.
This is where scarce legacy expertise becomes especially valuable. Instead of asking an experienced developer to manually explain every program from scratch, the team can ask that person to review extracted rules, resolve ambiguity, and identify important omissions. Business owners can then decide which behaviors should be preserved and which should deliberately change.
Keep those decisions explicit. Otherwise, modernization can quietly become a business-process redesign, with defects and intentional changes becoming difficult to distinguish.
Rebuild the Estimate Around the Work
Applying an “AI productivity discount” to an old project total will produce a weak estimate. Different activities have different opportunities for acceleration, and some costs may increase as the team discovers previously hidden complexity.
Break the estimate into workstreams and attach evidence to each assumption.
| Workstream | Where AI may reduce effort | What the estimate must still include |
|---|---|---|
| Discovery and business rules | Code explanations, dependency analysis, draft rule catalogs | Missing artifacts, expert review, business decisions |
| Implementation | Translation, refactoring, repetitive changes, test scaffolding | Architecture, integration, review, correction |
| Validation | Candidate test cases, comparison scripts, mismatch investigation | Trusted expected results, representative data, acceptance |
| Migration and transition | Draft mappings, scripts, runbooks | Data reconciliation, rehearsals, parallel operation, recovery |
| Delivery tooling | Reusable analysis and implementation workflows | Model usage, setup, security controls, ongoing maintenance |
For each workstream, ask what drove the original cost and what evidence would justify changing it. An estimate dominated by manual code analysis deserves a different reassessment from one dominated by data cleanup, external dependencies, or business approvals.
Here is a simplified illustration, not a benchmark or a projected savings rate. Suppose an earlier estimate allocated $4 million to discovery and implementation, with another $6 million for validation, migration, transition, and other delivery costs. If a representative pilot supported cutting the first category in half, the revised total would be $8 million before any additional AI tooling costs.
That would be a 20% reduction in the project total. Whether it changes the investment decision depends on the expected business benefits, remaining risks, and available alternatives.
Compare those alternatives over the same planning period. Include the cost of retaining the current system and the ongoing cost of the replacement on Microsoft Azure, including support, operations, and any transitional overlap. Distinguish cash savings from capacity released for other work, and avoid counting the same benefit twice.
Also distinguish reduced labor effort from a shorter delivery schedule. Faster analysis may release engineering capacity without moving a fixed migration window or accelerating a partner’s integration work. Estimate cost and elapsed time separately, using conservative, expected, and optimistic scenarios.
Fund a Pilot That Can Change the Decision
A useful modernization pilot should resolve a business uncertainty. Producing an impressive translation of a small program is insufficient if the original project was rejected because nobody understood cross-system dependencies.
I would organize the reassessment around five decisions.
1. Establish what the business needs to improve. Identify the constraint: expensive changes, slow product launches, fragile integrations, operating costs, or dependence on a shrinking group of specialists. Define a measurable outcome so the project has a purpose beyond replacing old technology.
2. Select a representative business capability. Choose a bounded workflow with meaningful rules, real dependencies, and observable results. Include difficult characteristics found elsewhere in the system, such as shared data, exception processing, or batch interactions. Document what the sample excludes.
3. Define acceptance before implementation. Specify which behavior must match, who approves intentional differences, and what performance, security, and operational requirements apply. Establish how expected results will be obtained and how sensitive data will be protected.
4. Measure the complete delivery loop. Track artifact preparation, tool setup, analysis, expert review, implementation, testing, and rework. Record elapsed time as well as labor effort. Compare results with a documented baseline or comparable previous work, and make clear where the comparison relies on judgment rather than a controlled measurement.
5. Update the investment decision. Use the results to revise cost ranges, identify unresolved risks, and choose the next scope. Continue, narrow the project, change approaches, or stop based on the evidence.
The output should include a reviewed rule catalog, a dependency map, an implemented slice where appropriate, validation results, and a revised estimate. Keep one-time setup costs separate from recurring delivery costs so leaders can see what might improve across subsequent waves.
Avoid extrapolating from lines of code alone. A large reporting program and a small shared routine can have very different business consequences. Group remaining work by characteristics demonstrated in the pilot, and retain uncertainty for categories the pilot did not cover.
A successful pilot can also justify retaining the system. If analysis reveals manageable maintenance costs and little business benefit from replacement, that is a useful investment result.
Build Confidence Independently of Generated Code
When AI helps explain the old system, write the replacement, and generate tests, the same misunderstanding can appear in all three outputs. Passing those tests would demonstrate consistency within the generated work without necessarily demonstrating correct business behavior.
Use additional sources of evidence. Compare old and new outputs using controlled inputs, review important rules with domain experts, and test business invariants such as balanced financial totals or preserved transaction counts. Include exceptional conditions, period-end processing, recovery behavior, and boundary cases relevant to the workflow.
Microsoft makes a similar distinction in its guidance for another enterprise modernization scenario: migrating BizTalk Server integrations to Azure Logic Apps Standard. Its AI-assisted Migration Agent supports discovery and implementation, while Microsoft explicitly requires architectural review and validation of generated artifacts before deployment. That example has a different source platform, but the acceptance principle applies equally to mainframe modernization.
For our billing example, matching a normal day’s totals would be only one check. The team would also need to examine rounding, account-state changes, duplicate inputs, failed jobs, and restart behavior. A replacement that calculates correctly but charges customers twice after a retry has failed an important requirement.
Functional comparisons also leave other questions open. Can the replacement handle peak load? Are authorization boundaries correct? Can operations detect failures and recover within business tolerances? Those requirements need their own validation.
Missing documentation makes discovery more important; missing source artifacts, runtime configuration, or access to expected results can limit what discovery establishes. If the team cannot validate a high-consequence behavior, report that as an unresolved risk and fund further investigation before expanding the migration.
Choose Tools and Migration Scope Together
A specialized modernization product may fit the source language and target platform. Existing developer tools may be sufficient for a bounded task. A custom AI harness may make sense when the project needs a repeatable process that coordinates analysis tools, models, tests, and human review.
For business leaders, the harness is the system around the model. It determines what information the AI receives, which tools it can use, how work is recorded, and what must happen before a result is accepted.
For example, a project-specific workflow could collect a program and its dependencies, generate a draft rule catalog with source references, flag unresolved calls, and route the results for review. Approved rules could then guide implementation and testing. Record the source revision, instructions, model configuration, reviewer decisions, and test evidence so the team can investigate how an output was produced.
Custom tooling has an economic case only if its benefits justify its development and maintenance. Evaluate supported languages and artifacts, integration effort, traceability, exportability, and the expertise required to operate it. Use parsers, compilers, and deterministic comparison tools where they provide direct evidence; use AI where interpretation adds value.
Set access boundaries early. Decide where source code and data may be processed, how prompts and outputs are retained, and which environments agents can modify. Include these constraints in the pilot so the measured approach is one the organization can actually deploy.
For a Microsoft Azure target, hosting and data architecture also need their own decisions. Microsoft’s mainframe refactoring reference architecture describes options using Azure Kubernetes Service or Azure Virtual Machines. Select a target based on workload requirements and operational capability, then estimate its costs; generating replacement code does not settle that choice.
The implementation strategy deserves the same discipline. Lower development costs may make selective replacement attractive, but rehosting, replatforming, refactoring, purchasing a replacement, and retaining parts of the estate should remain available options. Mainframe infrastructure is not automatically the problem; identify the capability or constraint that needs to change.
A phased migration can provide earlier feedback and limit exposure, provided the team accounts for coexistence costs. Shared databases, synchronized data, temporary interfaces, and dual operations can make an incremental approach expensive. Plan the cutover and recovery process explicitly, especially once the replacement starts accepting writes that the old system would need to recover.
Finally, connect each phase to an economic milestone. Moving one capability may deliver business value without eliminating the cost of its original platform. Track when applications, infrastructure, licenses, and support arrangements can actually be retired. Partial migration and realized savings are different milestones.
Reopen the Estimate With Better Questions
An old modernization estimate records what the project appeared to require under the assumptions available at the time. AI gives us a reason to test some of those assumptions again, particularly where manual investigation and implementation made the work prohibitively expensive.
For a CTO or business decision-maker, the next step is a focused reassessment. Choose one deferred project, identify its largest cost or uncertainty, and fund a bounded pilot that measures whether AI changes it. Require evidence strong enough to support the next investment decision.
If your organization has a legacy system everyone agrees needs attention but nobody can justify changing, I’m happy to discuss how to structure that reassessment. Start with what made the last estimate unacceptable and what evidence would justify a different decision today.
