Hand existing software over to a new team
Check the handover from an identified source revision to a small, reversible change in the test environment.
Let the new team follow the path themselves
A handover becomes tangible when the new team can set up the application with their own authorised accounts and check an agreed change. A source archive and a demonstration by the previous team do not by themselves supply all the evidence.
First map the running version to an identified source revision. Record required files, dependencies, tool versions and the path to a runnable result. SLSA distinguishes sources, other inputs, builds and distributed artifacts. This lets the new team trace which inputs produced the handed-over version.
Example: a text change from setup to reversal
This scenario is fictional. A service form is handed over at v2.3.0. The new team should clarify the help text “Delivery note” as “Access and delivery.” Data fields and the database schema remain unchanged in this example. The table describes expected evidence, not an executed test.
Step | Agreed task | Expected evidence |
|---|---|---|
Access sources | Use an individually authorised account to retrieve the documented source revision and required additional files. | The handed-over revision is identified; required private packages and additional repository content are accessible too. |
Set up the environment | Follow the runtime, package installation and test configuration instructions. | The test application starts without production access or the previous developer’s private files. |
Check a small change | Change the help text and exercise the existing save workflow with synthetic data. | The new text appears; the agreed save workflow still works. |
Reverse the change | Undo the text change in the test environment and use the documented startup path. | The original text and previously checked form workflow are available again. |
The final row demonstrates only the rollback path for this change. Database restoration or a production transition needs its own appropriate checks.
Add operations and open issues
Document configuration names, secure ways to obtain secrets, private package sources and existing build configuration, including a suitable dependency lockfile. Real secrets do not belong in the source archive. Check separately stored large files and included repositories if the project uses them.
Clarify access and responsibilities for deployment, monitoring, backups and incidents. A GitHub repository transfer retains associations including webhooks, secrets and deploy keys. Explicitly review which connections and access should remain. A transfer alone does not clean them up.
If a step fails, record the missing prerequisite, responsible role and next evidence required. Separate open issues from successfully demonstrated results. Agree when the new team takes over each task and who remains available until then.
Sources
Read more
All articles
Software Development with ASES
Custom software, web and mobile apps