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

Map operations and responsible roles

Start with operations the organisation needs: preparing a release, investigating failure, recovering an account, reaching a supplier and performing recovery. Identify who may do each operation and whose cooperation is required. A developer might release code while a different administrator owns the domain.

For each critical operation, identify cover during absence. This does not mean granting every permission to everyone. A clear escalation path may be appropriate if it is executable. Make ownerless topics visible. Otherwise the handover can appear complete until an incident reveals that each person is waiting for somebody else.

Check access without hiding previous dependencies

Have the incoming operator use their agreed access to reach the environment. A demonstration on the departing developer’s laptop does not show that the new team can begin independently. Identify required approval, additional authentication and assistance from an organisational administrator. Do not preserve access keys in handover notes.

Within authorised scope, examine recovery of an important account too. Who can restore blocked access, and which organisational administrators are needed? End previous access at an agreed point after necessary replacement capability is demonstrated. Ownership and bounded operational permissions belong together in a useful handover.

OWASP Application Security Verification Standard ↗

Trace code, configuration and deployment together

Ask the incoming operator to identify the active version and locate its source. Explain how configuration is selected and which environment differences are intentional. A repository tag helps only if its connection to the running application is understood.

Include files or jobs outside the normal release route when they support the chosen business journey. A separate nightly import may have its own version history. A future investigator should be able to explain which state was active at a particular time. Without that relationship, incidents remain harder to reconstruct even if all source files are stored somewhere.

Integrations have their own accounts, data contracts and recovery paths. Include them in the handover: API integration maintenance and handover: what must be in place?.

Rehearse a bounded release

Choose a safe exercise in which the incoming operator builds and publishes an agreed test version in an identifiable environment. Record manual steps and missing information. A small content change may be sufficient, provided the exercise follows the real release method.

The operator should then identify the active version and completed checks. A command ending successfully does not demonstrate that users receive the intended version. Request an observable application result and verification of the relevant business journey. Preserve where assistance was required so instructions and access can be improved before further responsibility transfers.

Use an explainable failure as a handover exercise

Prepare an example where processing is rejected or an external source is unavailable. Have the incoming operator locate the alert, identify the business reference and determine the next step. Keep the exercise within the agreed environment and avoid unintended production actions.

A useful outcome goes beyond finding the error. The operator should know whether replay is appropriate, who assesses an uncertain outcome and which information should not appear in general alerts. This reveals whether supporting documentation actually helps. A failure explainable only through verbal guidance from the original developer is a concrete outstanding handover item.

Treat recovery as a separate capability

Release and recovery are different operations. An incoming operator may know the normal release control without knowing where recovery copies, configuration or files come from. Rehearse an agreed recovery path when it belongs to the transferred responsibility. Record limitations and production differences.

Verify the outcome through a recognisable user operation. A restored database lacking attachments may open technically while producing unusable work. Preserve the version and dataset used and what remains untested. Confidence in recovery requires targeted exercises; one successful handover demonstration is not a guarantee for every future incident.

Google SRE: Testing for Reliability ↗

Make supplier dependencies actionable

For critical external services, record how an authorised operator obtains support and which information a request needs. A general support address says little about who may act for the organisation. Identify ownership of licences, renewals and billing when these can affect availability.

Use an example question to check the route without unnecessarily simulating an incident with the supplier. An existing contract administrator may confirm the relevant process. Show where a third party still owes access or information. That dependency can affect the start of independent operation and should not be dismissed as a minor administrative detail.

Make documentation discoverable during operations

A long manual is not always the best format for every task. A short entry page linking release, incident and recovery procedures may work better during daily operation. Each procedure needs an owner and the state it describes. A replacement should find it without searching somebody’s private chat history.

Explain what an operator should do when instructions no longer match reality. Blindly following an obsolete instruction may cause avoidable damage. A stop and escalation point is more useful than pretending every future scenario can be documented in advance. The handover should let missing information surface safely for assessment by the appropriate owner.

Example: release succeeds but diagnosis still depends on one person

Illustrative example: a company transfers an internal platform. The incoming operator independently publishes a test version but cannot explain a nightly import failure. The alert refers to a folder existing only on the previous operator’s computer. The team records successful release capability and a separate unresolved diagnosis task.

Follow-up moves the necessary investigation material into an appropriate shared operational location and repeats the same failure example. Handover status remains honest: some capabilities are demonstrated while others still need support. This enables phased responsibility instead of marking the entire transfer complete or failed at once.

Finish with a handover record and owned outstanding work

For each selected operation, record who performed it, when, in which environment and with what outcome. State required assistance and evidence a future operator can locate. A signed inventory of received documents may serve administration, but it does not replace this operational check.

Give outstanding work an owner, next action and decision point. Agree which previous access ends only after that action. Future releases and incidents should update the operating record. The aim is to reduce dependence on incidental personal knowledge while keeping deliberately retained dependencies visible.

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

Continue with a related question