What You Should Receive When a Software Project Is Handed Over

The Project Is Finished. What Do You Actually Own?

Most software projects end quietly. The application goes live, the last bugs are fixed, the final invoice is paid, and everyone moves on. The organisation that paid for the system has a working application, an admin login, and perhaps a short user guide.

The gap shows later. A new feature is needed and the original team is no longer available, so the organisation looks for a new one. The new team asks for the specification, the design, the test records, the repository, and the server access. Very often, none of it can be found.

At that point the organisation owns a running copy of its system, for as long as nothing needs to change. Handover is the moment that should have been settled, and it is the moment most often skipped, because the application works and nobody is in a hurry.

A Project That Arrived Without a Single Document

We write this from the receiving side. qadrtech was asked to continue developing an application that arrived as source code and nothing else. There was no requirements specification, no design document, no database design, no test cases, and no user manual. Nor were there the artifacts an iterative process leaves behind: no backlog, no user stories, no acceptance criteria, no sprint or release notes. Whatever method had produced the application, nothing from that process came with it. For the client's privacy we do not describe the project further.

Before a single new feature could be planned, we had to work out what the system did by reading the code, then confirm with the owner which behaviour was intended and which they had simply been living with. We have written about that work in recovering knowledge from code and taking over an AI-built application.

It can be done, but it has a cost. The client pays a second time for knowledge that already existed once, and some of it never comes back. Code shows what a system does. It does not show what was agreed, what was rejected, or why a rule exists.

Software Is Code and Its Documentation

Standard definitions of software do not stop at the programs. The IEEE software engineering glossary (IEEE Std 610.12) describes software as computer programs together with the procedures, documentation, and data that go with them. Ian Sommerville's Software Engineering textbook makes the same point: software includes the documentation and configuration data needed for the programs to work correctly.

In practical terms, an application delivered without its documentation is an incomplete delivery, in the same way a building handed over without its drawings is. The development method changes what that documentation looks like. It does not remove it.

What Every Handover Should Contain

A complete handover covers five areas: the code, the development documentation, the operational documentation, access and ownership, and credentials. Check each one separately; having one does not imply having the others.

1. The Code

• The full repository with its version history, not a zip file of the latest copy. History is often the only record of when and why something changed.
• The repository under an account your organisation controls, with the vendor added as a collaborator rather than the other way around.
• Confirmation that the repository matches what runs in production. Changes made directly on a server and never committed are a common source of surprises.
• Build scripts, configuration templates, and database migrations, not only the application code.
• No passwords or API keys committed in the code. If any are there, they must be removed and replaced.

2. Development Documentation

This is the record of what was built and why. Its form depends on how the project was run, so ask for the set that matches your project's method.

If the project followed a plan-driven lifecycle

A project run in phases, such as a waterfall-style SDLC, produces documents at each phase. At handover, expect:

• Requirements: a business requirements document or software requirements specification describing what the system must do, including functional and non-functional requirements. Our article on the business requirements document explains why this matters.
• Design: the system architecture, the database design or entity relationship diagram, the user interface design or mockups, and API specifications if the system exposes or consumes APIs.
• Testing: the test plan, the test cases, and the user acceptance test (UAT) results signed by your side.
• Change records: the change requests approved after the specification was agreed, so the specification and the delivered system can be reconciled.

If the project ran on Agile or Scrum

The Agile Manifesto values "working software over comprehensive documentation", and that line is often read as permission to deliver no documentation at all. The manifesto itself says the items on the right still have value. What it rejects is heavy documentation written up front and never updated, not documentation.

Scrum leaves its own artifacts, and they belong to the client as much as the code does:

• The Product Backlog, including completed items: user stories, acceptance criteria, and priorities. In an agile project this is the living specification.
• The Definition of Done, which should state that documentation is updated as part of finishing each item, so documents grow sprint by sprint rather than in a rush at the end.
• Sprint review notes, release notes, or a changelog, showing what was delivered and when.
• Records of significant technical decisions, for example as architecture decision records.
• Design materials produced along the way, such as data models and interface designs.

Agile projects carry one particular risk. These artifacts usually live in a tool such as Jira, Trello, ClickUp, or Notion, often in the vendor's workspace. When the contract ends and access is removed, the user stories, acceptance criteria, and discussions disappear with it. Ask for an export, or better, create the workspace under your organisation's account from the start.

Whatever the method

User documentation belongs in every handover: a user manual for the people who use the system and an administrator manual for the people who manage users, settings, and data.

3. Operational Documentation

This is what the next team needs to run and change the system:

• A README explaining what the system is, the technology it uses, and how to run it locally.
• Deployment steps and a description of each environment.
• A list of environment variables and configuration, with what each is for.
• Backup and restore procedures.
• Known issues and limitations, so the next team does not rediscover them the hard way.

Keep these in the repository, next to the code, so they are handed over with it and updated when it changes.

4. Access and Ownership

Every account the application depends on should belong to the organisation, not to an individual:

• Hosting and server: the hosting or cloud account in the organisation's name, with administrator access.
• Database: direct access and a recent full backup stored away from the server.
• Domain and DNS: registered to the organisation, with the expiry date known. An expired domain takes a working system offline as effectively as a crash.
• External services: email delivery, payment gateways, SMS, storage, app store accounts, and analytics.

List every account with its owner next to it. Any line that names a person's private email rather than an organisational address is unfinished handover.

5. Credentials

• Passed through a secure channel, such as a password manager shared with the organisation, not in chat messages or plain email.
• Rotated after handover. Passwords and keys the vendor knew should be changed. This is ordinary hygiene, not distrust, and a good vendor will expect it.
• Personal accounts used by developers during the project removed or transferred.

After rotation, confirm the application still works. A key nobody knew about will show itself here rather than during an incident.

Prove It Works Without the Previous Vendor

A handover that has never been tested is a hope. Before signing off:

1. Read the specification against the system. Pick a few features and check that the requirements, or the user stories and acceptance criteria, describe what the application actually does.
2. Build from the repository. Someone new follows the README. Every question they have to ask is a gap in the documentation.
3. Deploy to a test environment by following the deployment notes.
4. Restore a backup somewhere separate. A backup that has never been restored is not yet proven.
5. Log in with the new credentials on every account in the access list.

Do this while the vendor is still engaged, when questions can be answered in minutes.

Put It in the Contract Before Work Starts

Handover is far easier to arrange at the start of a project than at the end. Points worth agreeing up front:

• The list of documents the project will produce, matched to the method: specification, design, test, and UAT documents for a plan-driven project; backlog, Definition of Done, and release notes for an agile one; manuals and operational documentation for both.
• Handover as a named deliverable, with final acceptance tied to receiving those documents together with the code.
• Ownership of the code and documentation. The details vary by jurisdiction and contract type, so this is worth reviewing with someone qualified in contract law.
• Accounts and workspaces in the client's name from day one: repository, hosting, and the project management tool.
• A transition period in which the vendor answers questions from the organisation or its next team.

None of this signals distrust. It protects both sides: the client knows what it will receive, and the vendor has a clear point at which the work is complete.

A Handover Checklist You Can Use

Code

• Full repository with history, under an organisational account
• Repository matches what runs in production
• Build scripts, configuration templates, and migrations included
• No secrets committed in the code

Development documentation

• Requirements: specification, or backlog with user stories and acceptance criteria
• Design: architecture, database design, interface design, API specification
• Testing: test cases and signed UAT results
• Change requests, release notes, or changelog
• Records of significant technical decisions
• Project management workspace exported or owned by the organisation
• User manual and administrator manual

Operational documentation

• README with local setup
• Deployment steps and environment description
• Configuration and environment variables explained
• Backup and restore procedures
• Known issues and limitations

Access and credentials

• Hosting, server, and database access in the organisation's name
• Domain registered to the organisation, expiry date known
• Every external service account listed with its owner
• Credentials received securely and rotated after handover

Verification

• Specification checked against the running system
• Application built and deployed by someone new from the documentation
• Backup restored successfully

What This Means for Application Owners

If your project is still running, ask for these documents now, while the people who wrote them are available. If it uses Scrum, check where the backlog lives and who owns that workspace.

If your project has already ended and the documents are missing, the situation is usually recoverable. Secure the code, server, database, and domain first. The structure of the system can then be read back from the code, and the intent behind it reconstructed with the people who use it. It costs more than receiving the documents would have, but it is far better than continuing to change a system nobody can describe.

Closing

A software project is complete when the organisation that paid for it can run, change, and move it without depending on any one person. That takes the code and the documentation that explains it, together with the access and credentials to operate it.

If you are about to receive a project from a vendor, or you have inherited a system that arrived without its documents, we are happy to help you review what you have. Get in touch and tell us about the system; we will start from there.