Home/Tools/Existing software handover check

OXIAE / PROJECT PREPARATION

Existing software handover check

Inventory access, reproducibility, restore evidence and investigation boundaries. Download preparation for a software handover or audit.

With existing software, establish what exists, who has access and which business process depends on it. This handover check gathers those facts for an initial discussion or audit. It separates confirmed evidence from matters that still require investigation.

Choose one system and one objective. Taking over daily maintenance, investigating an incident and preparing a complete modernisation decision are different assignments. Describe the decision the investigation should enable and which operations remain outside its scope.

Prepare your plan

Your answers stay in this page. Download the draft to keep it; closing or resetting the page clears your input.

System and business function

What does the software support and who is affected if it fails?

Handover or audit objective

For example take over maintenance, investigate an incident or prepare a modernisation decision.

Access and account ownership confirmed?

Include source code, hosting, domain, licences and connected services. Do not share keys.

Build and startup reproducible?

Can a successor start the correct version in an agreed test environment?

Restore drill evidence available?

A backup file differs from a verified restore drill.

Available investigation evidence

Choose what is currently available; completeness and usefulness need investigation.

Constraints and known uncertainties

Record unacceptable interruptions, missing knowledge and work that needs separate approval.

Owner and follow-up arrangement

Who receives findings and decides on remediation, maintenance or further investigation?

Your preparation

0 of 8 fields completed

Still to investigate

System and business function
Handover or audit objective
Access and account ownership confirmed?
Build and startup reproducible?
Restore drill evidence available?
Available investigation evidence
Constraints and known uncertainties
Owner and follow-up arrangement

Next steps for this plan

Inventory ownership and necessary access before agreeing maintenance. Exchange keys through an agreed secure route, not through this plan.
Have a successor build and start the correct version in a test environment. Record missing dependencies and unknown steps.
Plan an isolated restore drill with agreed data, responsibilities and business checks. Do not assume recoverability because backups exist.
Limit conclusions to the available evidence. Agree further investigation before making claims about internal code quality or hidden dependencies.
Connect each finding to evidence, possible consequences and an accountable next step. This check does not inspect software or issue an audit opinion.

Access means more than a user account

A maintainer may be able to log into an application without controlling its source code, hosting or connected services. Record which accounts belong to the organisation, who may grant access and where licences and recovery procedures are managed. Keep missing access visible as an open question. Do not put keys or passwords in this tool or an ordinary project brief.

A reproducible build helps establish which version is being transferred. Ask a successor to start the agreed version in a suitable test environment and perform a recognisable user operation. Documentation understood only by the original developer needs clarification before a new maintainer can responsibly prepare changes.

Describe the available evidence

Illustrative example: a company wants to hand over an internal scheduling application. A code archive and daily backup exist, but nobody has recently witnessed a restore drill. The initial investigation checks versions, dependencies and an isolated recovery path. At this stage, a new supplier makes no commitment to a recovery duration or a complete replacement.

Separate an observation, a possible explanation and an unknown. An error message can show that a request fails while its cause remains uncertain. A demonstration shows user behaviour but does not establish how authorisation or internal data handling is implemented. Available access determines which conclusions the investigation can support.

Agree an actionable follow-up

Connect each significant finding to an owner, a possible consequence and a next check. Record which operations need separate approval. An audit may recommend a restore drill without authorising the investigator to change production data or interrupt an operational system.

Download the draft to discuss with the current and future maintainers. Resolve unknowns with evidence before choosing maintenance, remediation or modernisation. This check does not inspect code or issue a quality certificate; it prepares an investigation with clear boundaries and handover arrangements.

Understand the decisions behind your plan

Existing software & audits ↗

01 / Existing software & audits

Existing software handover check

Prepare your plan

Access means more than a user account

Describe the available evidence

Agree an actionable follow-up

Understand the decisions behind your plan

Taking over an existing codebase: establish what must keep working

Scoping a software audit: which decision should the evidence support?

Prioritising technical debt: which improvement actually helps the business?

Modernise or rebuild existing software: compare the whole transition

Migrating a running legacy system: ownership, cutover and fallback

From audit finding to improvement: evidence, priority and retesting

Testing software recovery: a backup is not yet a working business journey

Handing over existing software operations: let a second person perform the work