Your IT Budget Has A Blind Spot. It Is Called Maintenance.

The cost is not only writing code. It is understanding existing systems before every safe change.

Every CIO is being asked where the next investment should go. AI initiatives, cloud programmes, security, data platforms, and modernization all compete for attention.

Meanwhile, a quieter line keeps consuming time and money: maintaining software that already exists.

That cost is easy to treat as normal. Systems need fixes. Regulations change. Products evolve. Interfaces move. Incidents happen. The business keeps asking for small changes to large applications that cannot simply be paused or replaced.

The hidden question is why so much maintenance work still depends on expensive rediscovery.

Maintenance cost is often code-understanding cost wearing a different label.

At ITP Software, this is one reason we talk about Panorama as a code-comprehension and software-intelligence tool. The hard part of many changes is not typing the edit. It is finding what the edit touches, what depends on it, what has to be tested, and which assumptions are still unsafe.

The Budget Problem Is Structural

Maintenance is rarely one clean activity.

A team may receive a request to change a field, adjust a calculation, fix an exception path, support a new reporting rule, remove an old dependency, or connect a legacy process to a newer service. The requested change may sound small. The investigation around it may not be.

Before implementation, someone has to answer practical questions:

• Where is the relevant logic?
• Which programs, copybooks, tables, files, jobs, screens, reports, and interfaces are connected?
• Does the data move through COBOL, PL/I, Assembler, C, Java, DB2, IMS, CICS, JCL, batch, or distributed systems?
• What can be changed safely, and what needs more review?
• Which tests matter because of the dependency path rather than the ticket title?

If those answers live mainly in a few people's heads, maintenance becomes a scheduling problem as much as a technical one. The experts are overloaded. Newer team members wait. Managers hesitate to move people because the system knowledge is too fragile.

The Usual Levers Have Limits

Most organizations have already tried some version of two maintenance levers.

The first is continuity: keep experienced people on the same systems for as long as possible. It works because those people know the history, the exceptions, and the old decisions that never made it into documentation. It also creates a bottleneck. The more the organization depends on a few experts, the harder it becomes to scale maintenance, onboard new people, or reduce operational risk when those experts are unavailable.

The second is outsourcing or external maintenance support. This can be useful, especially when capacity is constrained. But a new provider does not automatically understand the codebase any better than a new employee does. Knowledge transfer, transition planning, detailed specifications, review cycles, and oversight can absorb much of the expected saving if the system itself remains opaque.

Both levers can change who does the work. Neither automatically changes how much understanding must be rebuilt before work can be done safely.

The Missing Lever Is Better System Understanding

Software maintenance becomes more repeatable when understanding is not reconstructed from scratch for every change.

This does not mean replacing engineering judgement. It means giving engineers, architects, and reviewers better evidence earlier:

• call relationships and cross-references
• dependency paths across languages and artefacts
• impact analysis around a proposed change
• data movement through programs, records, databases, files, screens, and interfaces
• generated technical documentation that can be reviewed and corrected
• searchable system knowledge that is not tied to one person's memory

That evidence changes the maintenance conversation.

Instead of asking one expert to remember every consequence, the team can investigate the system directly. Instead of sending vague change specifications to a receiving team, the organization can discuss a concrete impact surface. Instead of treating onboarding as months of passive shadowing, new developers can begin with navigable relationships and reviewed documentation.

Where Panorama Fits

Panorama helps organizations understand large legacy and enterprise codebases before they change them. It supports code comprehension and software intelligence across the kinds of systems where maintenance cost is usually hardest to see clearly: COBOL, PL/I, Assembler, C, Java, IBM Z, z/OS, CICS, DB2, IMS, JCL, batch, files, reports, interfaces, and mixed application estates.

A reviewer can start with a program, field, copybook, job, transaction, table, file, report, or suspected dependency and follow the relationships around it. The goal is not to make the system simple. The goal is to make the relevant evidence visible enough for a good engineering decision.

That matters for several maintenance situations:

1. A production change where the edit is easy but the dependency surface is unclear.
2. A new developer trying to understand an old application without waiting for one expert to explain every path.
3. An outsourcing or service-provider transition where the receiving team needs system evidence, not only handover meetings.
4. A modernization assessment where the organization needs to know what is really being maintained before deciding what should change.
5. A documentation effort where generated understanding can be reviewed instead of starting from a blank page.

Panorama should not be presented as a magic shortcut around engineering review. It is more useful than that: it gives the review better material to work with.

A Better Maintenance Question

The usual budget question is, "How do we spend less on maintenance?"

A more useful question is, "How much of our maintenance cost is spent understanding the same systems again and again?"

If the answer is significant, the organization has a practical lever. Make system understanding more visible. Reduce dependence on memory. Give new and external teams better evidence. Make impact analysis and dependency review part of normal maintenance, not an emergency activity after something breaks.

The point is not to pretend maintenance disappears. Critical software will always need care.

The point is to stop treating code understanding as a hidden cost that every team has to pay manually, change after change.