Existing software and audits: understand the situation and choose a manageable next step

Choose the guide matching your current decision

A supplier leaves, users report failures and leadership wants renewal. These signals may be related, but they do not automatically describe the same assignment. Start with the decision required now. Does a new team need to operate the system, should a risk be investigated or does an investment need comparison?

Choosing the right entry prevents premature solution selection. Takeover starts with access and understanding behaviour. An audit starts with an investigation question and boundaries. Comparing improvement with rebuilding begins with desired outcomes and transition costs. Use the other guides to investigate a discovered uncertainty rather than treating every page as another mandatory assignment.

Record existing value alongside constraints

Ask users what they need daily and what they want to preserve. An unremarkable export may be essential at month-end. An older interface may remain tolerable because scheduling works well underneath it. A proposal describing only technical problems can lose this value when designing a replacement.

Also document specific friction: a change is difficult to release, an error hard to locate or an account hard to transfer. Connect every point to an example. This creates a comparison between value delivered and constraints imposed. Framework age or repository size can justify investigation, but neither provides a complete investment case by itself.

Connect people, systems and versions

A useful baseline connects the active software version to its environment, records and responsible people. Who owns the domain, hosting, storage and external connections? Who explains the meaning of a status? Responsibilities may span several people and suppliers. This can work when relationships and cover arrangements are executable.

Identify information that is available and knowledge supplied only through conversation. A verbally explained nightly job may be an important transfer item. Name it without automatically demanding replacement of the infrastructure. The takeover guide explains how to connect scattered access and documents into a verifiable first operating journey.

Commission an answer to an investigation question

An audit should state the decision it supports. Investigating organisation boundaries in a portal requires different exercises from investigating whether a new team can deploy. Agree environment, version, access and sampling. Keep unexamined components visible in the report.

A security framework such as OWASP ASVS can help name particular controls. Mentioning it does not constitute complete certification. Ask which behaviour was actually examined and what evidence remains. A bounded report can be valuable precisely because it states its limitations. The scoping guide helps define the assignment; the findings guide then helps turn its result into action.

OWASP Application Security Verification Standard ↗

Create an improvement agenda with an endpoint

Technical debt becomes manageable when an item has an understandable consequence and a proposed first step. An error-prone manual check might need reference examples, while an unclear account needs ownership and cover. Do not put these subjects on the same numerical scale without explaining their meaning.

For each improvement, ask what will demonstrably differ afterwards. Can a second developer start a test version? Can a rejected enquiry be explained? Do intended outcomes survive internal restructuring? The debt guide supports this assessment. Preserve decisions to defer work too, so a future operator does not need to reconstruct the discussion from scratch.

Compare change including the transition

Retention, targeted improvement, gradual replacement and rebuilding have different consequences. Make each alternative address the same desired business journeys. Include data, staff preparation, temporary parallel processes and retirement of the old system. A fresh codebase can be attractive without offering the cheapest or most manageable transition.

AWS describes the strangler fig pattern as an option for gradual replacement. Investigate whether a suitable boundary exists; adding another system is not an objective in itself. Ask which old responsibility can genuinely disappear after a phase. The modernisation guide compares alternatives. The live-transition guide then addresses operational cutover rather than merely moving records.

AWS Prescriptive Guidance: Strangler fig pattern ↗

Investigate recovery before depending on it

A preserved copy is one component of continuity. Application code, records, files, configuration and access must together support a usable journey. An exercise can show which parts work and which knowledge is missing. Start with a recognisable business objective rather than simply instructing someone to restore a database.

Record observations and limitations honestly. A successful trial on one version does not predict every future incident. Google SRE provides background on targeted reliability testing; the recovery guide turns this into practical questions and examples. Use observed exercise time to improve the approach rather than as a standalone promise about availability.

Google SRE: Testing for Reliability ↗

Have operational handover performed

When transferring existing software, receiving documentation differs from demonstrating capability. Have an authorised second person perform selected tasks: identify a version, verify a test release, investigate a failure or follow recovery instructions. Record required assistance and the person responsible for providing it.

These exercises need not all occur in production. A suitable test environment with clearly stated differences can support safe rehearsal. The operational-handover guide covers this evidence. It differs from ownership and future-development agreements for new software: the question here is whether other people can genuinely continue an existing operating process.

Example: take over first, improve next

Illustrative example: an organisation wants to renew its internal order platform after the original supplier leaves. Discovery shows staff can still use the main processing, but release and recovery responsibilities were not transferred adequately. The organisation first chooses operational handover and a targeted audit of a proposed new customer role.

The results enable a smaller initial improvement: limited introduction of the role with explicit record boundaries and a retest. Complete rebuilding remains an alternative to assess later. This is not a universal sequence. It illustrates how investigation can direct investment towards the real constraint while preserving existing value and examining new needs.

Define the next assignment and its open questions

Use the preparation tool to record current access, responsibility, release and recovery. Do not replace unknown answers with assumptions. An open item may determine the first investigation required. Have the intended outcome assessed by people able to discuss technical execution and its daily operational meaning.

A useful initial assignment has boundaries, an assessable result and a decision point for discovered dependencies. Its outcome may require revising the proposal. This builds knowledge a future developer can use without promising complete renewal before the organisation understands which change is needed and executable.

Explore each decision

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Legacy software modernisation ↗
• Software audit ↗

Questions about this topic