Mainframe knowledge transfer fails when the people who understand mission-critical systems leave faster than organisations can replace their judgement. The answer is not another document repository. It is an interface that captures expert reasoning while the work is happening and makes it usable by the next person.

Mainframes are often discussed as though their age is the problem. It is an easy story: the platform is old, the specialists are retiring and the organisation should move on.

But mission-critical workloads do not disappear because the language around them changes. They continue to process transactions, support customers and generate costs that somebody must understand. Meanwhile, the estate around them has become more complicated. Mainframe, distributed systems and cloud now sit alongside one another, with different data, tools, owners and ways of explaining value.

The urgent question is therefore not simply whether an organisation is “leaving the mainframe”. It is whether the next generation will inherit enough context to operate, challenge and improve the whole estate.

Why mainframe knowledge transfer fails before retirement

Knowledge loss rarely happens on the day an expert leaves. It begins much earlier, whenever a decision is made but its reasoning is not captured.

An experienced practitioner sees a cost spike and knows which workload to inspect. They recognise that a month-end pattern is normal, that a threshold has a historical reason or that an apparently inefficient process protects a more important service. They may draw on decades of pattern recognition, conversations and incidents.

The dashboard records the number. The ticket records the action. Neither necessarily records why that action was the right one.

That missing “why” is the handover gap.

Traditional knowledge-transfer programmes often respond by asking experts to write more documentation before they leave. The result can be a large collection of technically correct material separated from the moment in which it is useful. A new employee still has to know what to search for, which version to trust and how a general rule applies to the incident in front of them.

The knowledge exists, but the route to it is broken.

The interface is the handover

A better approach is to treat knowledge transfer as part of the operational workflow.

When an expert investigates a workload, explains an anomaly or makes a cost decision, the surrounding context should be captured with it: the relevant data, the question being answered, the evidence used, the decision taken and the conditions under which that decision remains valid.

That creates a living knowledge layer rather than a document archive.

AI can make this interface conversational, but conversation is not the hard part. A fluent answer without evidence simply makes uncertainty easier to consume.

For knowledge transfer to be trusted, every answer should expose where it came from, when the source was last reviewed and whether it reflects documented policy, observed behaviour or an expert’s judgement. Where the system is unsure, it should identify the right person or missing evidence rather than manufacture certainty.

A worked example: the month-end cost spike

Imagine that a mainframe workload becomes significantly more expensive at the end of every month.

An experienced specialist investigates it. They compare the current run with earlier periods, identify the business process driving demand and decide that the cost increase is expected within a particular range. While doing so, they capture a short explanation and the evidence behind it. The interface links that reasoning to the workload, cost records and relevant operating guidance.

Months later, a new analyst sees the same pattern and asks:

Why does this workload become more expensive at month-end, and when should I escalate it?

The useful response is not a generic description of mainframe capacity management. It is a grounded answer that shows:

• the business event behind the increase;
• the normal range seen in earlier periods;
• the evidence used to establish that range;
• the conditions that should trigger escalation;
• the current owner of the guidance; and
• the actions taken the last time those conditions were breached.

The analyst can resolve a familiar issue without waiting for the original expert. If the circumstances are different, they can see exactly where the existing guidance stops applying.

The interaction also improves the organisation’s knowledge. Was the answer found? Was it understood? Did the analyst still need help? Each question reveals a gap that can be fixed for the next person.

Do not design one interface for two generations

The phrase “generational gap” can encourage the wrong design assumption: that experienced people resist technology while younger people intuitively understand it. Neither is reliable.

The meaningful difference is context. An expert needs a fast way to capture judgement without interrupting the work. A learner needs enough explanation to understand that judgement without being overwhelmed by specialist terminology.

The same knowledge layer can support both, but the interaction should adapt:

• For the practitioner: capture a decision from the dashboard or incident workflow, with the supporting data already attached.
• For the learner: explain unfamiliar terms, show the reasoning in stages and offer a safe next action.
• For the manager: reveal uncovered systems, ageing guidance and knowledge that depends on a single person.
• For finance and leadership: connect technical behaviour to cost, service and business impact.

This is how workforce resilience becomes part of cost transparency rather than a separate HR initiative.

What good looks like

A successful prototype should prove that knowledge can be transferred, not merely stored. Five measures would make that visible:

1. Time to a usable answer: how long a newer colleague takes to understand and act on a known issue.
2. Evidence rate: the proportion of answers linked to an identifiable source, dataset or accountable expert.
3. Repeat-work reduction: how often an investigation is repeated because the earlier reasoning could not be found.
4. Knowledge coverage: which critical workloads have current guidance and which still depend on one person.
5. Path to autonomy: whether learners need less expert intervention as they encounter related scenarios.

These measures also prevent the idea from collapsing into “add a chatbot”. The goal is not to generate more answers. It is to make valuable judgement retrievable, testable and transferable.

The challenge

The Innovation Forum’s Beyond the Mainframe challenge asks teams to rethink transparency across mainframe, distributed and cloud environments. Cost and usage data are part of that problem, but data alone does not explain itself. People supply the context that turns a number into a decision.

The opportunity is to connect those two assets: a trusted view of the technology estate and a trusted record of how experienced people interpret it.

A strong challenge build might capture an expert investigation, turn it into a sourced operational playbook and then demonstrate that somebody unfamiliar with the issue can retrieve, understand and apply it. The system should show its evidence, expose uncertainty and learn where the handover still fails.

That would do more than preserve knowledge about a platform. It would give a new workforce the means to question, operate and improve it.

The one thing to take away Do not wait for an expert’s exit interview to capture what they know. Capture the decision, evidence and reasoning at the moment their knowledge changes the work.