# Modernisation starts by establishing what is actually true

> Discovery should distinguish what an application does, what the organisation needs and what it has authorised someone to change. That distinction connects application understanding to a defensible modernisation decision.

Paper: 02.03
Published: 2026-09-17
Canonical: https://harten.io/papers/02-03-modernisation-starts-by-establishing-what-is-actually-true/

Cover illustration: [View the title image](https://harten.io/media/papers/covers/v1/02-03-modernisation-starts-by-establishing-what-is-actually-true.jpg?v=0b804eaf1487). Illustrative cover artwork, not an application screenshot or a record of measured results.

At the end of discovery, an organisation should be in a better position to decide what it is going to change.

That sounds straightforward. But knowing what an application does is not the same as knowing which parts of it should survive.

In [Legacy systems are expensive because knowledge has decayed](https://harten.io/papers/02-02-legacy-systems-are-expensive-because-knowledge-has-decayed/), I wrote about the cost of changing software when an organisation no longer has a reliable account of how it works. Recovering that knowledge gives modernisation a firmer starting point. It does not, on its own, decide what should happen next.

What the system does today, what the organisation needs it to do, and what a team has been authorised to change are three different things. The next part of discovery is connecting them without treating them as interchangeable.

## Start with the problem, not the replacement

Before looking at the application, I would want to understand why the organisation wants to change it.

Perhaps support is ending. Perhaps the service is unreliable, the cost of operating it is becoming unacceptable, or a business process cannot adapt without disproportionate engineering effort. These are different problems. They should not automatically lead to the same modernisation strategy.

The government’s [updated definition of legacy IT](https://www.gov.uk/government/publications/guidance-on-the-legacy-it-risk-assessment-framework/updated-definition-of-legacy-it), updated on 17 August 2026, makes a useful distinction here. It centres legacy on unacceptable burden or risk and the ability to support or secure a system effectively and economically, rather than its age, technology type or hosting model. A shortage of the necessary skills and knowledge is one of the criteria it identifies.

That is a more useful starting point than deciding that an application needs replacing because its technology looks old.

The [GOV.UK Service Manual](https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works) makes a related point about discovery: examine the problem before committing to a solution, understand the wider user journey and investigate the constraints around it, including operational processes and existing systems. Although written for public services, I think the principle travels well.

If the problem is slow fulfilment, the relevant boundary may extend beyond the application into warehouse processes and supplier integrations. If the problem is an unsupported component, a much narrower intervention may be sufficient.

Discovery should help establish that boundary. It should not simply gather material to justify a replacement that has already been chosen.

## A finding is not yet a requirement {#order-example}

Consider a hypothetical order-management application.

When a dispatch message arrives from the warehouse, the application marks the order as complete. Every afternoon, an operations team reconciles those orders against a separate warehouse report. Discrepancies are held back from invoicing until someone resolves them.

A description of the application might accurately explain the status change and still miss the control performed by the operations team.

As I wrote in [You cannot govern what you cannot understand](https://harten.io/papers/01-3-you-cannot-govern-what-you-cannot-understand/), understanding an application means looking beyond its source code to the dependencies, operational practices and human decisions around it. In this example, the effective process includes the reconciliation, even though the application does not perform it.

Finding that process is important. Deciding what to do with it is a separate piece of work.

The reconciliation might compensate for unreliable messages. It might catch errors that would remain possible with a new integration. Or it might combine several checks, only some of which are still needed.

Copying the manual step into the replacement could preserve an avoidable cost. Removing it because the new integration looks more reliable could remove a necessary control.

I would want the team to establish what the check prevents, which failures it has to handle and who depends on its result. Then the organisation can decide whether to retain the existing process, replace it with a different control or retire it.

The outcome that matters may be that an unresolved dispatch discrepancy must not lead to an invoice. That is different from requiring someone to run the same report at the same time every afternoon.

This is one of the useful things discovery can do for modernisation: separate what the organisation relies on from the particular way an older system provides it.

## Enough understanding for the change being considered

Discovery does not need to answer every question about an application before useful work can begin.

It needs to identify which unanswered questions could change the next decision.

In the [hypothetical order-management example above](https://harten.io/papers/02-03-modernisation-starts-by-establishing-what-is-actually-true/#order-example), not knowing why a report was given its name may have little bearing on the work. Not knowing whether it is the only check preventing incorrect invoices could determine whether the proposed change should proceed at all.

I would expect those uncertainties to be treated differently. Otherwise, we either investigate everything indefinitely or close discovery with important gaps hidden among a long list of minor ones.

The evidence should also be open to inspection. A conclusion drawn from a particular source-code version is not the same as an observation of the running service. An operator's explanation may add something neither source contains. Where those accounts disagree, the disagreement needs to stay visible until it is resolved or the decision is narrowed so that it no longer depends on the disputed point.

The [W3C's provenance model](https://www.w3.org/TR/2013/REC-prov-dm-20130430/) describes how information about sources, activities and responsibility can support assessments of reliability. Applied here, the practical requirement is modest: an important conclusion should retain a route back to what supports it. That route makes the conclusion easier to challenge; it does not make it automatically correct.

The next investigation should be chosen for what it could resolve. Inspecting exception records might establish whether the reconciliation catches a current problem. Comparing outputs might show whether a proposed replacement preserves an important result. Speaking to the team that receives the report might uncover a dependency the application team did not know about.

Where a material uncertainty remains, the answer need not always be to stop the whole programme. It may be to keep the existing check for the first release, reduce the scope of the change or test the uncertain part separately. But where the unresolved question could invalidate the proposed change, proceeding as though it has been answered is not a defensible shortcut.

This is the economic test I would apply to further discovery: could the answer materially alter the scope, expected benefit, risk or decision to proceed? That gives the investigation a purpose and a stopping point without pretending the whole estate is understood.

## Put human judgement where it matters

Once the relevant facts and gaps are visible, someone still has to decide which outcomes are required and which changes are acceptable.

In [The human cannot be the bottleneck](https://harten.io/papers/01-2-human-cannot-be-the-bottleneck/), I wrote about concentrating human judgement on consequential decisions rather than requiring approval of every machine action. Here, that means deciding whether the reconciliation may change, not supervising every step used to investigate it.

The decision needs both knowledge and authority. The person responsible for the service may understand the intended outcome. The operations team may understand the exceptions. An engineer may understand what the proposed design can reliably provide. A signature from one person does not automatically bring those perspectives together.

I would want the recommendation to explain the proposed change, the evidence supporting it, the unresolved risks and the conditions under which it is acceptable. The person accountable for the outcome can then make a meaningful decision, with the relevant specialists contributing to it.

The role I would give AI is to help prepare that decision: bring together relevant material, identify possible relationships, compare accounts and develop explanations that can be checked. Its findings should not silently become approved requirements. Nor should a suggestion to remove a process become permission to remove it merely because it appears in a convincing implementation plan.

Once the decision is made, the team needs room to execute within it. Routine implementation choices should not have to return for approval. A discovery that changes the agreed outcome, introduces a new consequence or invalidates the evidence behind the decision should.

## Keep the difference between today and tomorrow visible

The resulting specification should make the intended difference explicit.

For the hypothetical order system, it would describe the current reconciliation and its purpose. Separately, it would set out the agreed future behaviour: what must prevent an incorrect invoice, how unresolved discrepancies are handled and which part of the manual process is being removed.

It should also retain the basis for that decision. The claim that a new integration removes the need for a check must not replace the evidence that the old check existed. Otherwise, the proposed design starts rewriting the account of the system it is meant to replace.

This does not require a vast document or a new approval committee. It requires enough clarity that the business, engineers and people testing the change are working towards the same outcome.

If the approved requirement is to prevent invoicing while a discrepancy remains unresolved, checking only that an order reaches a "complete" status would not establish that requirement. The tests need to address the outcome that was agreed, including what should happen when the normal process fails.

That is where the understanding recovered during discovery becomes useful to delivery. It gives the team a reason for the behaviour it is preserving, a clear account of what may change and a basis for checking the result.

The cost of legacy discussed in the earlier paper was partly the cost of recovering lost knowledge. My concern here is what happens after that knowledge has been recovered. If the decisions remain implicit, the next team will still have to work out which behaviours matter, which compromises are intentional and what it is allowed to change.

I would judge discovery by whether it leaves the organisation able to make those choices explicitly. Then modernisation can proceed against an agreed purpose, rather than leaving the design of the future system to assumptions about the old one.

---

*This paper is part of The Modernisation Control Papers, the first major sequence within The Harten Papers. [Read the complete series on harten.io](https://harten.io/papers/).*