Recover the system around the code
Source code explains implemented logic, but production behavior also depends on JCL, batch windows, datasets, security profiles, message queues, manual recoveries, and downstream reconciliations. A program that looks unused may still be part of a month-end route. A field that looks redundant may carry a regulatory distinction.
Create an inventory that joins technical and operating evidence. Give each relationship an evidence source, verification state, owner, and last-checked time. Unknown is a useful value; an unmarked guess becomes a hidden migration risk.
| Layer | Evidence | Question |
|---|---|---|
| Business capability | Process, policy, control owner | What outcome does this protect? |
| Application logic | Programs, copybooks, rules | How is the outcome calculated? |
| Runtime dependency | Schedules, traces, interfaces | What must happen before and after it? |
| Operational judgment | Runbooks, incidents, expert review | How is an exception recovered? |
| Assurance | Reconciliations, accepted cases | How does the business know it is correct? |
Use AI as a discovery aid, not as the authority
AI can summarize unfamiliar programs, propose data lineage, group similar routines, and help reviewers search a large estate. It can also produce a confident explanation for a relationship that does not execute in production. Treat generated findings as candidates with provenance.
IBM describes application wikis and dependency analysis as ways to improve mainframe code understanding and preserve institutional knowledge. That is useful when every generated explanation remains tied to a source version and a human review path. When code or configuration changes, mark dependent explanations for review.
Choose the renewal path by capability
Do not force the whole estate into one modernization pattern. A stable ledger may be retained or rehosted. A bounded peripheral service may be refactored. A capability with clear replacement controls may move to a package. Score criticality, dependency complexity, change demand, skills exposure, data sensitivity, and test evidence for each capability.
Record why the route was selected and what evidence would change the decision. That decision history belongs in the knowledge base because the next renewal wave will depend on it.
Prove business behavior at the boundary
Build cases from normal transactions, boundary values, historical incidents, authorization failures, duplicate inputs, partial outages, restart behavior, and end-of-day reconciliation. Compare outputs at the business level, not only record counts. Mark intentional changes and obtain the right approval instead of hiding them inside a broad migration sign-off.
The existing knowledge-based mainframe renewal guide contains the longer capability-mapping and acceptance model. This page focuses on the preservation decisions most likely to be lost during a renewal.
Sources and verification
Primary product, architecture, risk, and security sources checked on 10 September 2026. Product behavior can change, so verify current plan and admin documentation before implementation.