Software handover: what a new team must do independently

A complete software handover should be assessed by whether another team can set up the application, make a targeted change and deploy it to a test environment. Source code is necessary. The independent attempt reveals whether the supporting knowledge has been transferred too.

For the client, the practical question is how much still depends on a particular person or computer. An available download does not answer it.

A clean environment exposes gaps

In a fictional example, the new team receives approved release R-1 of an ordering portal. Everything starts on the previous developer's laptop. On a fresh test system, however, the exact runtime version, empty-database setup and meaning of two environment variables are missing. The code has arrived; part of the setup remains unclear.

A long general document can leave the same gap. What helps is a guide the new team can follow through the steps actually required. Twelve-Factor principles separate changing configuration from code and favour similar development and production environments. They provide orientation, rather than a complete handover record for every technology.

Use a small change as evidence

For the example exercise, R-1 is installed with defined dependencies. The team creates an empty test database, uses synthetic credentials and completes test order T-31. Production keys do not belong in the repository or instructions.

Next, it changes the field label “Reference” to “Customer reference”, rebuilds the application and deploys it to the test system. Finally, it restores the previous release. This small intervention tests whether setup, change, deployment and rollback are understood together. It does not prove the team can implement every future feature.

If the previous team has to supply missing steps, add them to the handover and try them again. A spoken explanation can resolve the immediate difficulty; the gap is resolved durably only when that knowledge remains available for the next attempt.

When a narrower scope is enough

For a limited extension to a platform already operated jointly, handing over the changed code can be a useful intermediate step. Building an entirely new operating environment might be disproportionate for that task. It must then be clear which platform knowledge and access already exist and who remains responsible for them.

Test services are also legitimate when real integrations should not be used in the exercise. State which part is therefore untested. A simulated payment service does not establish a working production connection.

For a complete team change, the independent exercise is the stronger measure. It exposes remaining handover work before the previous contact becomes unavailable. The acceptance record should name the release used, the completed workflow and the dependencies still open.

Sources

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity