Why a small change in legacy code is rarely small
In a COBOL or PL/I estate, a field is almost never used in just one place. A payment amount defined in one copybook can be read by dozens of programs, written to a ledger, copied into an audit record, and passed to a batch job that runs overnight. Change its length or meaning in one program and the damage may show up weeks later, in a report nobody linked to that change.
Change impact analysis is the work you do before the edit to find out what the edit will touch. This page is a practical checklist for engineers and architects at banks and insurers, where the original authors are often gone and the documentation is incomplete or out of date.
The dependencies to check before you change a field
Start from the field and work outward. For each item below, write down what you found and where you found it, so a reviewer can check your work later.
- Definition. Where is the field declared? Copybooks, tables and screen definitions can each hold their own version of it, and they may not match.
- Reads and writes. Which programs read the field, and which ones write to it? A program that only reads it still breaks if the format changes.
- Business rules. Which calculations or validations use the field? Look for the rule behind the code, such as a fee deducted to produce a net payment, not just the matching line.
- Downstream records. Where does the value end up? Ledger entries, audit records and extracts for other systems all count.
- Batch and scheduled jobs. Many dependencies only run at month end or year end, so they will not show up in a quick test run.
- Interfaces. Check files, queues and APIs that hand the value to another system, including ones owned by other teams or vendors.
- Reports and regulatory outputs. A changed field can quietly change a figure that a regulator or auditor relies on.
Who to ask besides the code
Code shows what a system does. It does not always show why. Before you sign off an impact assessment, talk to the people who can fill that gap.
- Operations and batch schedulers know which jobs run, in what order, and what depends on their output.
- Business analysts and product owners can say whether a rule still reflects current policy or is a leftover from a past product.
- Finance, risk and compliance know which outputs feed reports and audits, and which changes need formal approval.
- Teams that own connected systems can confirm whether they consume the field you plan to change.
- Long-serving engineers often remember the odd exceptions that never made it into any document. If one of them is close to retirement, capture what they know now. Our page on what to do when the only person who understands your system is about to retire covers how.
How to confirm nothing downstream breaks
A list of dependencies is only a hypothesis until you test it. Use these steps to turn it into evidence.
- Compare before and after. Run the same input through the old and new versions and compare outputs field by field, including the downstream records, not just the screen.
- Include the awkward cases. Test zero values, maximum lengths, negative amounts, and any case that triggers a special rule.
- Run the periodic jobs. Simulate the month-end or year-end run in a test environment before the change goes live.
- Check with owners of connected systems. Ask them to confirm they received and handled the test output correctly.
- Keep the evidence. Record what you checked, what you found and who approved it. This helps in an audit, and our guide to auditing business logic changes in legacy systems for regulatory reviews explains what reviewers tend to look for.
- Plan the rollback. Decide in advance how you will undo the change if something unexpected surfaces.
Where tooling helps
Manual impact analysis works for a single field in a small program. It does not scale to an estate with decades of accumulated code, where searching for a field name misses aliases, copybook redefinitions and indirect uses.
Replai reads your existing code, including COBOL, PL/I and Oracle Forms, and builds a structured map of business rules, workflows and dependencies. Your team can then ask plain-language questions about a field and follow its relationships back to the source code. In a simple example, a payment amount field links to a rule that calculates a net payment, which in turn links to a ledger entry and an audit record. Each link points to its source evidence so an engineer can check it.
A map like this narrows the search, but it does not replace judgment. Treat it as a faster way to build the dependency list above, then apply the same questions and the same testing. For background on how the analysis works, see legacy code analysis and how AI agents read legacy code.
Change impact analysis: common questions
What is change impact analysis in legacy code?
It is the work of finding everything a planned change could affect before you make it. For a field, that means its definition, the programs that read or write it, the rules that use it, and the records and reports that receive its value.
Why is a small change risky in a bank or insurer's legacy system?
Core systems often hold decades of accumulated business logic, and a single field can be used in many programs, batch jobs and outputs. A change in one place can quietly alter results in another.
Who should be involved in an impact analysis besides developers?
Operations and batch schedulers, business analysts, finance, risk and compliance staff, and the owners of connected systems all hold knowledge the code does not show. Long-serving engineers often know exceptions that were never documented.
Is searching the code for the field name enough?
Usually not. Aliases, copybook redefinitions and indirect uses can hide dependencies that a plain text search misses, so you need to trace relationships and not only matching names.
How can I confirm a change broke nothing downstream?
Compare outputs before and after the change, including downstream records, and test edge cases and periodic jobs such as month-end runs. Ask owners of connected systems to confirm they handled the output, and keep a record of what you checked.
Can AI tools do impact analysis for me?
They can speed up building the dependency map by reading code and showing relationships with links to source evidence. Your team still needs to review the findings, test the change and make the final decision.