A software project is not fully handed over just because the application has been deployed and the client can log in.

A working application is only part of the final delivery.

A proper handover should give the client, internal team, or replacement development team enough information and access to understand, operate, maintain and take control of the system.

That includes the source code, infrastructure, databases, deployment process, integrations, documentation, monitoring, backups, known issues and ownership information.

This is the purpose of a software development handover document.

It records the final state of the project, explains where important assets are located, identifies who controls them, and provides the operational information needed after the development phase ends.

The level of detail depends on the project.

A marketing website may need a relatively simple handover. A multi-tenant SaaS platform, enterprise operations system, e-commerce platform or AI application may require a much more detailed package.

The principle remains the same:

A client should receive more than a working application. It should receive the information, access and control required to operate and maintain it.

To make this practical rather than theoretical, we have put the checklist below into a working spreadsheet: download the Software Development Handover Checklist (Excel). It tracks all 56 items across the categories in this guide, with owner, status and evidence columns, plus a Summary sheet that automatically calculates handover readiness and flags blocking items.

This is the twelfth guide in our pre-development-through-delivery documentation series, alongside the documentation checklist, technical documentation, the architecture document, the requirement document, the scope document, requirements vs scope vs specifications vs SOW, acceptance criteria, what information a client should provide, questions to ask before hiring a development company, how to compare proposals, and the Statement of Work. Handover is where all of those documents finally get tested against the real, running system.

---

Quick Answer: What Should a Software Handover Document Include?

A comprehensive handover should generally cover:

Handover Area	What It Contains
Project Overview	What was built and its current status
Delivered Scope	What was completed and what remains
Source Code	Repositories, branches and build information
Architecture	Current system structure
APIs	Interfaces, authentication and integrations
Database	Schema, access and migration information
Infrastructure	Hosting, cloud resources and networking
Environments	Development, staging and production setup
Deployment	Release and rollback process
CI/CD	Automated build and deployment pipelines
Domains & DNS	Domain ownership and configuration
Third-Party Services	External systems and account details
Access Management	Administrative and operational access
Secrets Management	How credentials and secrets are controlled
Monitoring	Logs, alerts and system health
Backup & Recovery	Backup and restoration procedures
Testing	QA status and outstanding test work
Security	Important security controls and responsibilities
Known Issues	Outstanding defects and limitations
Technical Debt	Known technical compromises
Dependencies	External services, libraries and runtime requirements
Licenses	Third-party and open-source components
Release History	Major production releases
Support	Post-launch arrangements
Warranty	Defect coverage
Knowledge Transfer	Walkthroughs and training
Ownership	Code, data, infrastructure and account ownership
Acceptance	Confirmation that handover is complete

Not every project needs a separate document for every item.

What matters is that critical knowledge and operational access do not remain dependent on one person or one development company.

---

What Is a Software Development Handover Document?

A software handover document is a structured record of the information, assets and access transferred when responsibility for a software system moves from one team to another.

This can happen:

• At project completion
• At the end of a development phase
• When changing development companies
• When moving software to an internal engineering team
• During an acquisition
• When transferring operational responsibility

The document should allow a qualified technical team to understand the system without having to reverse-engineer it from scratch.

It should make clear:

What was built?

Where is the code?

Where does it run?

How is it deployed?

What systems does it depend on?

Who controls the important accounts?

How is production monitored?

How are backups handled?

What problems remain?

Who is responsible after handover?

---

Why Software Handover Matters

A project can appear complete while the client remains technically dependent on the original development company.

For example, imagine a company has launched a B2B SaaS platform. Customers are using it, subscriptions are being processed and the application is running in the cloud.

The client may still have no direct access to:

• The source repository
• The production cloud account
• The database
• The deployment pipeline
• Monitoring dashboards
• Backup systems
• Payment provider accounts
• Technical documentation

That creates operational risk.

The application may work today, but a future security issue, production failure, vendor change or new development requirement can become unnecessarily difficult.

A good handover reduces that dependency by transferring both knowledge and control.

---

Software Delivery vs Software Handover

These are different stages.

Software delivery

The agreed software has been built and made available.

Software handover

The client or receiving team has the access, documentation and operational knowledge needed to take responsibility for that software.

For example:

An e-commerce application has been deployed and customers can place orders.

That is delivery.

The client has source-code access, production infrastructure access, payment-provider access, database documentation, deployment instructions, monitoring access and the required account ownership.

That is a meaningful handover.

---

1. Project Overview and Final Status

Begin with a concise summary of the project.

Include:

• Project name
• Client
• Development company
• Delivery date
• Current software version
• Production URL
• Main components
• Current production status

Then document what was actually delivered.

For example, a B2B service management platform might have the following final scope:

Delivered

• Customer web portal
• Operations dashboard
• Role-based authentication
• Service request workflow
• Document upload
• Email notifications
• Reporting dashboard
• Production deployment

Not delivered

• Native iOS application
• Native Android application
• Advanced predictive analytics
• AI-powered recommendations

This is particularly useful when the product roadmap is larger than the phase that was actually delivered.

The handover should represent the final state of the system, not the original product vision.

---

2. Source Code and Repository

The source code is one of the most important handover assets.

Document:

• Repository location
• Repository owner
• Administrator
• Production branch
• Main development branch
• Release branches
• Build instructions
• Dependency information
• Required tooling

For example, a SaaS application might have:

• Web application repository
• Backend API repository
• Infrastructure repository
• Mobile application repository
• Shared package repository

The handover should identify which repositories belong to the delivered product and how they relate to one another.

Where appropriate, the client should have direct access to the repositories rather than relying on the development company to provide code only when requested.

The handover should also confirm:

• What source code is included
• Whether any components are excluded
• Whether third-party code has separate licensing terms

Ownership should match the governing agreement.

---

3. Architecture and Technical Documentation

The final architecture should reflect what is actually running in production.

For example, a multi-tenant SaaS platform may consist of:

Web Application → API Layer → Business Services → Relational Database

with additional connections to:

Payment Provider

Email Service

Object Storage

Authentication Provider

Monitoring Platform

The architecture documentation should explain those relationships and identify the role of each major component.

It should cover, where applicable:

• Frontend
• Backend
• APIs
• Database
• Authentication
• External integrations
• Background processing
• Storage
• Infrastructure

The handover package may also include:

• Technical specifications
• Functional specifications
• API documentation
• Database documentation
• Integration documentation
• Deployment documentation
• Environment documentation

The purpose is to give the receiving team enough context to safely work on the system.

---

4. API Documentation

If the system provides or consumes APIs, document:

• Endpoint
• HTTP method
• Authentication
• Parameters
• Request structure
• Response structure
• Error behaviour
• Webhooks
• Versioning
• Rate limits where applicable

For example, an e-commerce platform may expose APIs for:

• Customer accounts
• Product catalogue
• Shopping cart
• Orders
• Payments
• Inventory

An enterprise application may also consume APIs from an ERP, CRM or accounting system.

Example requests and responses can be particularly useful for future developers.

API documentation should cover both APIs owned by the project and important external integrations.

---

5. Database and Data

Database handover should cover:

• Database technology
• Production database location
• Schema
• Important entities and relationships
• Access process
• Migration process
• Data retention
• Backup configuration

For example, a subscription-based SaaS product may maintain entities such as:

• Organizations
• Users
• Plans
• Subscriptions
• Invoices
• Payments
• Usage records

The receiving team needs to understand how those entities relate to the application.

The client should also know:

• Who owns the data
• Who controls production access
• How data can be exported
• How data is backed up
• How data can be transferred if the system changes

The software and the data are separate assets and should both be accounted for.

---

6. Infrastructure and Environments

Document where and how the software runs.

For example, an enterprise application may use:

• Cloud compute
• Managed database
• Object storage
• CDN
• Load balancing
• Private networking
• Firewall rules
• Monitoring services

Also document each environment:

Development

Used for active implementation.

Testing

Used for QA.

Staging

Used for production-like validation.

Production

Used by real users.

For each environment, document:

• Purpose
• URL
• Infrastructure
• Database
• Configuration
• Access process
• Deployment method

Do not place sensitive credentials directly in the handover document.

---

7. Deployment and CI/CD

A receiving team should be able to understand how new software reaches production.

For example, a typical release process might be:

1. Developer creates release candidate.
2. Automated tests run.
3. Application is built.
4. Staging environment is updated.
5. Acceptance checks are completed.
6. Production approval is given.
7. Production deployment runs.
8. Database migrations are applied where required.
9. Health checks are performed.
10. Release is monitored.
11. Rollback is initiated if critical problems occur.

If CI/CD is used, document:

• Pipeline location
• Trigger conditions
• Build steps
• Test stages
• Deployment stages
• Required approvals
• Rollback process

Deployment should not depend on an undocumented manual procedure known only to one person.

---

8. Domains, DNS and SSL

Domains are business assets and should be explicitly covered.

Document:

• Domain registrar
• Domain owner
• DNS provider
• Important DNS records
• Production domains
• Subdomains
• Renewal responsibility

For example, an application might use:

• app.example.com
• api.example.com
• admin.example.com

For SSL/TLS, document:

• Certificate provider
• Where certificates are managed
• Renewal method
• Expiration monitoring
• Production configuration

The objective is to make ongoing ownership and renewal responsibility clear.

---

9. Third-Party Services and Accounts

Modern applications often depend on external services.

A typical e-commerce application might depend on:

• Payment gateway
• Transactional email
• SMS provider
• Analytics
• Cloud storage
• Search service

An AI application might additionally depend on:

• Model provider
• Embedding service
• Vector database
• Document-processing service
• AI monitoring platform

For each important service, document:

• Purpose
• Account owner
• Billing owner
• Environment
• Integration location
• Subscription or renewal information

A simple ownership table can help:

Service	Account Owner	Billing Owner
Cloud platform	Client	Client
Domain	Client	Client
Payment provider	Client	Client
Email provider	Client	Client
AI provider	Client	Client

The exact arrangement may differ by project, but it should be explicit.

---

10. Access and Secrets Management

The handover should explain how access is controlled without putting sensitive credentials into ordinary documentation.

Document:

• Systems requiring access
• Who currently has access
• Who should receive access
• Where credentials are securely stored
• How access is revoked
• How ownership is transferred

This includes:

• API keys
• Database credentials
• Tokens
• Encryption keys
• Signing keys
• Service accounts

For example, an AI application may rely on several API credentials. The handover should identify which systems use them and where they are securely managed, without publishing the actual keys in the document.

The handover document should describe the location and process for managing secrets, not expose production secrets in plain text.

---

11. Authentication, Authorization and Administration

Document the operational security model.

Include:

• Authentication system
• Identity provider
• User roles
• Permission model
• Administrative roles
• SSO configuration
• MFA configuration where applicable
• Session behaviour

For example, an enterprise platform might have:

Employee

Can access assigned records.

Manager

Can approve specific workflows.

Administrator

Can manage users and system configuration.

Also document the administrative interface:

• User management
• Configuration
• System settings
• Operational functions

Avoid shared administrator accounts where individual accounts can be provided.

---

12. Monitoring, Logging and Alerts

The receiving team should know how to determine whether production is healthy.

Document:

• Application monitoring
• Infrastructure monitoring
• Error tracking
• Logs
• Metrics
• Health checks
• Alerts
• Key dashboards

For example, an online commerce platform may monitor:

• API availability
• Payment failures
• Order-processing failures
• Database health
• Background job failures
• Application errors

For important systems, record:

• Where monitoring is located
• Who receives alerts
• How long information is retained
• What constitutes a critical issue

A system that cannot be observed is harder to maintain safely.

---

13. Backup and Recovery

Document:

• What is backed up
• Backup frequency
• Storage location
• Retention period
• Ownership
• Encryption
• Restoration procedure

For a SaaS platform, this might include:

• Production database
• Object storage
• Critical configuration
• Infrastructure state

Where recovery is important, also document:

• Critical systems
• Restoration order
• Recovery dependencies
• Responsible team
• Recovery testing status

A backup should not simply exist. The team should know whether it can actually be restored.

---

14. Testing and Release Status

At handover, document the state of quality assurance.

Include:

• Testing completed
• Accepted test cases
• Production validation
• Outstanding test work
• Known limitations
• Open defects

For example, an enterprise application may have completed functional and integration testing while performance testing remains scheduled for a later phase.

That should be visible.

The receiving team should not have to assume that every part of the system received the same level of validation.

---

15. Known Issues, Technical Debt and Pending Work

These three areas should be documented separately because they represent different things.

Known issues

Problems that currently affect the software.

For example:

A reporting export fails when a date range exceeds the current supported limit.

For each significant issue, record:

• Description
• Severity
• Impact
• Workaround
• Status
• Owner
• Planned resolution

Technical debt

Known technical compromises that may require future engineering work.

Examples:

• Temporary implementation
• Legacy dependency
• Manual deployment step
• Deferred refactoring
• Planned architecture improvement

Pending work

Agreed or discussed work that was not part of the completed delivery.

Examples:

• Phase 2 mobile application
• Deferred CRM integration
• Future reporting module
• Additional AI workflow
• Planned performance optimization

Keeping these categories separate makes the final state much easier to understand.

---

16. Dependencies and Licenses

Document important technical dependencies:

• Runtime versions
• Framework versions
• Major packages
• External APIs
• Cloud services
• Databases
• Third-party libraries

For example, an AI application may depend on:

• A specific model provider
• A vector database
• A document parser
• Several application libraries

For important open-source or commercial components, record:

• Component
• Version
• Purpose
• License
• Modification status where relevant

This makes future upgrades and compliance checks easier.

---

17. Production Configuration

The receiving team should understand important production configuration without receiving sensitive values in plain text.

Document:

• Configuration categories
• Feature flags
• External service settings
• Database configuration
• Storage configuration
• Runtime settings
• Domain configuration

For example, a SaaS product may use feature flags to control whether a new billing workflow is enabled for all customers or only selected organizations.

Actual secrets should remain in the approved secrets-management system.

---

18. User and Administrator Documentation

If non-technical teams operate the application, provide appropriate user documentation.

For example, an operations team using an internal workflow platform may need instructions for:

• Creating users
• Managing roles
• Reviewing requests
• Generating reports
• Handling failed transactions
• Updating system settings

This may include:

• Administrator guide
• User guide
• Common procedures
• Troubleshooting instructions
• Operational workflows

A technical team may understand the codebase while the business team still needs help operating the product.

Both needs should be addressed.

---

19. Knowledge Transfer

Documentation and knowledge transfer serve different purposes.

Documentation gives the receiving team a reference.

Knowledge transfer gives them context.

A handover session may cover:

• Architecture
• Local development setup
• Deployment
• Monitoring
• Administration
• Troubleshooting
• Backup and recovery
• Important business rules

For example, when transferring an enterprise application to a new internal engineering team, a walkthrough might explain why a legacy integration is still required, where failed jobs are monitored and how production deployments are approved.

For complex systems, recorded walkthroughs can be useful for future team members.

---

20. Support, Warranty and Contacts

The handover should identify what happens after delivery.

Support

• Support contact
• Support period
• Response expectations
• Maintenance arrangement

Warranty

• Start date
• End date
• Covered defects
• Exclusions
• Defect reporting process

Contacts

• Development company
• Client technical owner
• Infrastructure contact
• Relevant third-party contacts

A new feature request should not automatically be treated as a warranty defect.

---

21. Ownership and Intellectual Property

The handover should be consistent with the signed agreement and clearly identify ownership of:

• Source code
• Designs
• Documentation
• Database
• Business data
• Custom integrations
• Infrastructure
• Domains
• Relevant accounts

For example, an e-commerce company may own the application code, product data, domain, payment account and production cloud environment while continuing to use third-party software subject to its own license terms.

The handover should identify any items that remain subject to third-party ownership or licensing.

This is one of the most important areas to verify before signing off the project.

---

22. Handover Acceptance

Handover itself should have acceptance conditions.

The client or receiving team should verify the following:

Area	Verification
Source code	Repository is accessible and the production version is identified
Architecture	Current architecture and major dependencies are documented
Database	Schema, access and backup process are documented
Infrastructure	Required production access is available
Deployment	Release and rollback procedures are documented
Third parties	Important accounts, owners and subscriptions are identified
Security	Administrative access and secrets management are documented
Monitoring	Logs, dashboards and alerts are accessible
Recovery	Backup and restoration procedures are documented
Testing	QA and acceptance status are recorded
Issues	Known defects, technical debt and pending work are listed
Ownership	Code, data, infrastructure and accounts are controlled by the appropriate party
Knowledge transfer	Required walkthroughs have been completed

Once these conditions have been satisfied, the handover can be formally accepted.

---

Handover Requirements by Project Type

Website

Typical requirements:

• Source code
• CMS access
• Domain
• Hosting
• DNS
• Analytics
• Deployment instructions

For example, a corporate website may require WordPress or CMS administrator access, hosting access, domain control, analytics access and instructions for publishing content.

SaaS Application

Additional requirements may include:

• Architecture
• APIs
• Database
• Authentication
• Cloud infrastructure
• CI/CD
• Monitoring
• Backups
• Third-party integrations

A multi-tenant SaaS platform may also require documentation covering tenant isolation, subscription billing, background jobs and customer-level configuration.

Enterprise Platform

May require deeper coverage of:

• Infrastructure
• Identity
• Security
• Networking
• Integrations
• Disaster recovery
• Operational procedures

For example, an enterprise operations platform may depend on corporate SSO, internal APIs, approval workflows, private networking and centralized monitoring.

AI Application

May additionally require:

• Model providers
• AI service accounts
• Prompt configuration
• Retrieval system
• Knowledge sources
• Vector database
• Agent tools
• Evaluation setup
• AI monitoring
• Usage and cost controls

For example, an internal AI knowledge assistant may need handover documentation covering the approved knowledge sources, document ingestion pipeline, retrieval configuration, model provider, evaluation process, access controls and usage monitoring.

The handover should match the operational complexity of the system.

---

Practical Software Handover Document Structure

A reusable handover document can follow this structure:

1. Project Information

• Project name
• Client
• Version
• Delivery date
• Production status

2. Delivered Scope

• Completed functionality
• Deferred functionality
• Known exclusions

3. Source Code

• Repository
• Branches
• Build instructions
• Access

4. Architecture

• System overview
• Components
• Data flow
• Integrations

5. APIs

• Endpoints
• Authentication
• Webhooks
• Error behaviour

6. Database

• Schema
• Access
• Migrations
• Backup

7. Infrastructure

• Cloud
• Hosting
• Storage
• Networking

8. Environments

• Development
• Testing
• Staging
• Production

9. Deployment

• Build
• Release
• Migration
• Rollback

10. Third-Party Services

• Providers
• Accounts
• Billing
• Dependencies

11. Access and Secrets

• Access ownership
• Credential locations
• Secrets management

12. Monitoring and Operations

• Logs
• Alerts
• Dashboards
• Health checks

13. Backup and Recovery

• Backup schedule
• Retention
• Restoration

14. Security

• Access controls
• Authentication
• Security responsibilities

15. Testing

• QA status
• Acceptance status
• Outstanding issues

16. Known Issues and Technical Debt

• Defects
• Limitations
• Deferred work

17. Dependencies and Licenses

• Frameworks
• Libraries
• External services

18. User Documentation

• Administrator guide
• User guide
• Operational procedures

19. Knowledge Transfer

• Sessions
• Recordings
• Training materials

20. Support and Warranty

• Contacts
• Support period
• Warranty

21. Ownership

• Code
• Data
• Infrastructure
• Accounts

22. Handover Acceptance

• Verification checklist
• Approvals
• Sign-off

If you would rather work from a ready-made tracker than build this structure from scratch, the downloadable handover checklist covers all 22 areas as 56 trackable items, with owner, status and evidence columns and a Summary sheet that flags blocking items automatically.

---

When Should Handover Begin?

Handover should not be created from scratch on the final day of the project.

It should be prepared throughout development.

During the project:

• Keep technical documentation current.
• Keep repositories organized.
• Use clearly owned accounts.
• Record major architecture decisions.
• Track dependencies.
• Maintain deployment instructions.

Before launch:

• Verify production access.
• Verify ownership.
• Test backups.
• Confirm monitoring.
• Review deployment procedures.

At handover:

• Transfer responsibilities.
• Conduct knowledge-transfer sessions.
• Confirm access.
• Review documentation.
• Record unresolved items.
• Obtain acceptance.

This avoids turning handover into a last-minute scramble.

---

Handover When Changing Development Companies

A vendor transition is one of the clearest tests of documentation quality.

Imagine a company has operated a logistics platform for several years and decides to move development to a new technology partner.

The incoming team will need:

• Source code
• Architecture
• Infrastructure
• Database
• Deployment process
• Integration documentation
• Access information
• Monitoring
• Backup information
• Known issues
• Technical debt
• Business rules

Without this information, the new team may have to spend significant time reverse-engineering the platform before it can safely make changes.

A well-prepared handover reduces that transition cost and lets the new team spend more time improving the product rather than rediscovering how it works.

---

Final Takeaway

A software project is not fully handed over simply because the application is live.

A proper handover should transfer the information and operational control needed to manage the system after development.

That means accounting for:

Code

Architecture

APIs

Data

Infrastructure

Environments

Deployment

Third-party services

Access

Security

Monitoring

Backups

Testing

Known issues

Technical debt

Dependencies

Licenses

Support

Ownership

Knowledge transfer

The most important test is simple:

If the original development team stopped working on the project tomorrow, could another qualified team take over without having to rediscover the system from scratch?

If yes, the project has a meaningful technical handover.

If no, the software may have been delivered, but the knowledge and operational control required to own it have not been fully transferred.

At Ortem Technologies, we believe handover is not just the final exchange of files.

It is the point where responsibility can move from one team to another without losing control, context or operational knowledge.

That is what turns software delivery into genuine software ownership.

Handover answers who controls the system after launch. A separate question is who keeps it running — see our guide to what should be included in a software maintenance and support agreement.

Want a handover built into your project from day one instead of assembled at the last minute? That is how every custom software development engagement we run is structured.

Talk to us about your handover requirements →