Beyond Lift-and-Shift: AI-Led Paths to Mainframe Transformation
Surasa Mukherjee, associate director in Infrastructure and Cloud Architecture at Kyndryl, explains the value of AI-assisted discovery, dependency analysis, documentation and knowledge retrieval
Mainframes remain at the center of many of the world’s most important business services. They process high volumes of transactions, protect critical data and support applications that have evolved over decades. It reflects the reliability, security and performance they provide for demanding enterprise workloads.
Yet the discussion around mainframe modernization is often reduced to a question of migration. Organizations are encouraged to measure progress by how many applications have moved to the cloud, how much infrastructure has been removed or how quickly legacy code can be converted into a newer language.
That view overlooks a more important question: What should happen to each workload based on the value it delivers, the risk it carries and the capabilities the business will need from it in the future?
AI is creating new ways to answer that question. AI-assisted discovery, dependency analysis, documentation and knowledge retrieval can help organizations see their application estates more clearly. This insight can support safer decisions about whether to retain, integrate, refactor, migrate, replace or retire individual workloads.
Modernization Is More Than Moving Applications
Moving an application may change where it runs, but it does not automatically change how well it supports the business.
Lift-and-shift can be a valid response to a specific requirement. An organization may need to leave a data center, address an infrastructure constraint or align with a broader hosting strategy. In those situations, migration can provide a practical path forward.
However, moving an application without changing its design can also move its existing limitations.
Complex dependencies remain complex. Manual testing remains manual. Outdated documentation does not become accurate because the application has a new hosting location. Business rules embedded across programs, batch jobs, databases and operational processes remain difficult to understand.
A complete rewrite carries a different type of risk. Long-running mainframe applications frequently contain decades of business decisions. Some rules may be clearly documented, while others exist only in source code, job sequences, database structures or operational procedures.
A program may contain a condition introduced to meet an old regulatory requirement. A batch step may run in a particular sequence because of a production incident that occurred years ago. A validation rule that appears redundant may protect an important downstream process.
Converting the code without understanding this context can produce an application that is technically functional but operationally or commercially incorrect.
Modernization therefore needs to begin with understanding, not movement.
One Estate, Different Workloads
A mainframe estate is not a single application with a single modernization destination.
Most enterprises operate a varied portfolio of mainframe workloads. Some applications process millions of business-critical transactions. Others support periodic reporting, internal administration or products that are approaching retirement.
These workloads do not have the same requirements.
A payment engine that must maintain continuous availability should not be assessed in the same way as a reporting application used by a small internal team. A stable system of record may not need the same level of architectural change as a customer-facing application that must support frequent product releases.
Before selecting a transformation path, teams should consider several factors:
- Business value: Does the workload generate revenue, support customers, protect the organization or fulfil a regulatory obligation?
- Resilience: What availability, recovery, latency and transaction-integrity requirements must be maintained?
- Change demand: How frequently does the business need to modify the application?
- Technical condition: Is the application modular and well understood, or tightly coupled to multiple systems and data sources?
- Knowledge risk: How many people understand the application, its dependencies and its operational behavior?
- Economics: What does it cost to run, maintain and change the workload, including the potential cost of disruption?
- Strategic relevance: Will the business capability still be required in three, five or 10 years?
Portfolio-level targets can provide direction, but the final decision should be made workload by workload. This prevents organizations from applying the same treatment to applications with very different business and technical characteristics.
AI Can Help Reconstruct Application Understanding
One of the greatest modernization challenges is the difference between what teams think an application does and what it actually does.
Mainframe applications often have extensive operational histories. Over time, new programs are added, existing logic is changed and interfaces are created to support emerging business requirements.
Documentation does not always keep pace with those changes.
Application teams may have source-code repositories, design documents, support tickets, runbooks and monitoring data, but these sources are usually distributed across different tools. Understanding the complete application can require experienced specialists to manually connect information from each source.
AI can help accelerate this discovery process.
For example, AI-assisted tools can support teams by:
- Summarizing the purpose of programs and application modules
- Explaining complex sections of COBOL, PL/I, assembler or JCL
- Mapping program, data and job dependencies
- Identifying potential business rules and validation logic
- Finding duplicated or inconsistent processing
- Generating initial technical and functional documentation
- Highlighting possible service boundaries
- Supporting impact analysis for proposed changes
- Creating candidate test scenarios from code paths
- Connecting application knowledge with incidents and operational procedures
AI-assisted application-discovery tools can already analyze application structures, map dependencies and help teams identify business services that may be candidates for selective refactoring.
These capabilities can reduce the time spent searching for information, but they do not remove the need for specialist review. Source code alone does not describe the complete behavior of a production application. Its operation can also be influenced by data, middleware, scheduling, security rules, configuration and interactions with other platforms.
AI should therefore provide evidence for investigation, not an unquestioned answer.
Preserving the Knowledge Behind the Code
The most important application knowledge is not always stored in a formal system.
Experienced mainframe professionals often understand far more than the technical structure of an application. They know why certain processes exist, which symptoms indicate a serious issue and which recovery actions are safe under specific conditions.
Much of this knowledge may be distributed across:
- Standard operating procedures
- Incident and problem records
- Change histories
- Runbooks and recovery guides
- Source-code comments
- Architecture documents
- Emails and collaboration platforms
- Personal notes and team experience
When an experienced specialist retires or moves to another role, the organization may lose not only technical information but also the reasoning behind important operational decisions.
AI-enabled knowledge systems can help capture and organize this material. Teams can use them to search approved procedures, retrieve related incidents, explain unfamiliar components and identify differences between documented processes and actual application behavior.
This is not about replacing experienced professionals. It is about making their knowledge available to a wider group and preserving it for the next generation of mainframe practitioners.
For this approach to be trustworthy, every response should indicate where its information originated. Users should be able to distinguish between an approved procedure, a source-code observation and an AI-generated interpretation.
Different Workloads Need Different Paths
A strong transformation strategy creates several possible paths rather than one mandatory destination.
Once teams have a reliable understanding of an application, they can evaluate the most suitable treatment.
Common paths include:
- Retain and optimize: Keep a stable, high-value workload on the mainframe while improving automation, observability, testing, security and development practices.
- Integrate and expose: Make trusted business capabilities available through APIs, events or secure data services without immediately moving the underlying processing.
- Refactor selectively: Extract or redesign specific business functions that limit agility, rather than rewriting the entire application.
- Migrate or replatform: Move the workload when infrastructure, skills, economics or strategic alignment create a clear business case.
- Replace: Adopt a commercial or software-as-a-service (SaaS) product when maintaining a custom application no longer provides a meaningful advantage.
- Retire: Remove applications or functions that are no longer used, provided their dependencies and data-retention obligations have been addressed.
Retaining an application should not be interpreted as avoiding modernization. A retained workload can still benefit from automated delivery, improved monitoring, modern interfaces, stronger knowledge management and AI-assisted operations.
Similarly, migration should not be treated as success on its own. The target environment must still meet the workload’s security, resilience, performance and compliance requirements.
The right path is the one that improves the workload’s business contribution while managing transformation risk responsibly.
Human Judgment Remains Essential
AI can accelerate analysis and execution, but accountability cannot be delegated to a model.
AI-generated documentation can omit an unusual processing path. A suggested business rule may be technically accurate but lack business context. Automated code transformation may compile successfully while changing transaction behavior.
These risks are particularly important for applications supporting financial processing, healthcare, government services and other regulated or mission-critical functions.
An AI-led modernization approach should therefore include:
- Approved AI models and deployment environments
- Controlled access to source code and operational data
- Traceability from generated outputs to source evidence
- Review by application, infrastructure and business specialists
- Automated regression and data-reconciliation testing
- Security and compliance validation
- Confidence thresholds for AI-generated recommendations
- Version control and audit records
- Rollback plans for production changes
AI should help specialists investigate faster and work with a broader evidence base. The final decision should remain with the people accountable for the application and the business service it supports.
Starting With a Focused Use Case
Organizations do not need to analyze their entire application estate before beginning. A focused pilot can demonstrate value while helping teams establish governance and working practices.
The pilot should involve a representative application with accessible source code, documentation, operational history and subject-matter experts.
The team can then:
- Collect application code, metadata, procedures, incidents and performance information
- Use AI to generate summaries, dependency views and candidate business rules
- Validate the findings with application, database, operations and business specialists
- Evaluate the workload against value, resilience, change demand, risk and cost
- Compare realistic transformation options
- Implement one controlled improvement
- Measure the effect on delivery time, operational effort, documentation quality and risk
The first outcome does not need to be a major migration. It could be an API for an existing business function, an automated test suite, a documented dependency map or the retirement of an unused component.
What matters is that the organization establishes a repeatable method for making evidence-based decisions.
From Migration Targets to Transformation Choices
Mainframe transformation should not be defined by how much technology leaves a platform. It should be defined by how effectively the enterprise improves business capability, resilience, agility and long-term sustainability.
AI can help teams uncover hidden logic, reconstruct application knowledge and examine transformation options that were previously too difficult or time-consuming to evaluate. It can make complex estates more understandable and incremental modernization more achievable.
However, the goal is not to use AI to justify a predetermined destination. The goal is to use AI to create better choices.
For some workloads, that choice will be migration. For others, it will be integration, selective refactoring, optimization or retirement. Many enterprises will continue to operate across mainframe, cloud, distributed and SaaS environments.
The most successful transformation programs will be those that understand the role of each workload and place it where it delivers the best balance of business value, resilience, security and changeability.
The path beyond lift-and-shift begins by replacing platform assumptions with application evidence.