Your business also needs to know that it controls the accounts, code and information required to continue operating the software.
A structured handover makes these responsibilities visible. It can help the new developer start with a clearer picture while reducing avoidable disruption.
This guide explains what to collect, how to organise the transition and what to check before considering the handover complete.
Start With a Named Handover Owner
Choose someone in your business to coordinate the transition.
That person should track:
The outgoing and incoming developers can contribute technical information, but your business should retain a record of the transition.
If the outgoing supplier will be available for only a limited period, agree on the priority questions and handover sessions early.
Create an Application and Account Inventory
List the systems involved before changing access. An application may depend on several services beyond its main hosting account.
| Asset or service | Information to record |
|---|---|
| Source-code repositories | Location, account owner and required permissions |
| Hosting | Provider, environment and responsible contact |
| Databases | Location, access owner and backup arrangements |
| File storage | Provider and how the application uses it |
| Domains and DNS | Registrar, DNS provider and account owner |
| Email and messaging | Services, purpose and billing owner |
| Payments | Provider and integration responsibilities |
| Analytics and monitoring | Tools, access and alert recipients |
| Mobile distribution | Developer accounts and release responsibilities |
| Paid dependencies | Licences, subscriptions and renewal information |
Confirm Which Code Is Running
A repository can contain several branches, experiments and unfinished changes.
Ask the outgoing developer to identify:
The incoming developer should be able to distinguish the live application from work still in progress. If the available code does not clearly match the deployed application, record that as an unresolved handover issue.
Our software project takeover service explains how we approach transitions involving existing codebases.
Gather Setup Instructions
The new developer needs enough information to work in an authorised environment.
Useful setup documentation includes:
Configuration documentation can identify required variable names without exposing their secret values.
Ask the incoming developer to follow the instructions and record missing steps. Documentation is more useful when someone other than its author can use it.
Production data should not automatically become development data. Agree on an appropriate test-data approach.
Explain the Important Business Workflows
Code describes implementation. It may not fully explain why a particular rule exists.
Document the application’s most important workflows, including:
“A booking workflow may involve customer requests, staff approval, calendar updates and notifications. The incoming developer needs to understand those relationships before changing one part.”
Our guide to writing a developer brief shows how to describe workflows and acceptance criteria.
Document External Integrations
Integrations often depend on information outside the application repository.
For each connection, record:
Identify who receives provider notices about service changes or expiring access.
If an integration needs investigation or repair, explore our API development and integration service.
Make the Release Process Understandable
The incoming developer should know how a tested change reaches the live application.
Collect information about:
Ask for a walkthrough where the release process is undocumented. A demonstration does not necessarily require a production change. Use a suitable environment and agreed activity.
During the transition, make it clear which person or team is authorised to deploy. Overlapping ownership can create conflicting changes.
Review Backups and Recovery Information
A backup record should explain more than that backups are “enabled.”
Confirm:
- Which information is backed up.
- Where backups are stored.
- Who controls access.
- The applicable schedule and retention.
- Whether recovery has been checked.
- Who is responsible if restoration is needed.
Any recovery exercise needs an appropriate plan and environment. If backup or recovery arrangements are unknown, record the gap and assign responsibility for resolving it.
Do not assume that moving developers automatically requires moving hosting or databases.
Record Known Issues and Unfinished Work
Ask for a current list that distinguishes between completed and pending work.
For each important item, include available reproduction steps, affected workflows and supporting evidence. Avoid relying on a single statement such as “the project is nearly finished.”
A defined application technical assessment can help establish the current condition when records are incomplete or disputed.
Agree on Live Support During the Transition
The application may still need attention while the handover takes place.
Confirm:
- Who handles reported incidents.
- How urgent problems are raised.
- Whether routine feature work continues.
- Who can approve a production change.
- When the incoming developer assumes responsibility.
- What happens if the handover is delayed.
Support availability and response arrangements need explicit agreement.
If ongoing maintenance is required, review our application maintenance and support service.
Use Handover Sessions to Answer Specific Questions
A recorded walkthrough can be useful where everyone agrees to recording and storage.
Give each session a purpose, such as:
Prepare questions in advance and capture decisions afterwards. A long recording without an index or written notes can be difficult to use. Keep the essential instructions and unresolved questions in an accessible document.
Transfer Access in a Planned Sequence
Access changes need to account for accounts and credentials used by the application itself.
A practical sequence is:
- 1Confirm the business owner of each account.
- 2Arrange appropriate incoming access.
- 3Check that required tasks can be performed.
- 4Identify credentials used by people and those used by services.
- 5Plan any ownership or credential changes.
- 6Confirm the application still operates as expected.
- 7Remove outgoing access when it is no longer required.
Changes to credentials can affect integrations and automated processes. Coordinate them with the relevant provider and authorised technical owner.
Check the Handover With a Small Task
Reading documentation is different from using it.
A defined first task can help establish whether the incoming developer has enough context.
For example:
- Set up the application in an authorised environment.
- Run the relevant tests.
- Reproduce a documented issue.
- Make a limited change on a review branch.
- Prepare a test build.
Agree on the scope, fee and review process. This can reveal gaps before a larger development commitment begins.
Our developer hiring process explains how onboarding connects to initial tasks.
A Practical Handover Checklist
Use this checklist to confirm completion across each operational area.
| Area | Completion evidence |
|---|---|
| Ownership | Business account owners and responsibilities recorded |
| Source code | Repositories and current release identified |
| Setup | Incoming developer can follow the agreed setup process |
| Configuration | Required settings documented and access arranged |
| Data | Databases, storage and backup responsibilities identified |
| Integrations | Providers, account owners and dependencies recorded |
| Workflows | Important user journeys explained |
| Release process | Deployment and approval steps understood |
| Known issues | Outstanding work documented |
| Support | Transition responsibilities agreed |
| Documentation | Materials stored where the business can access them |
| Access closure | Outgoing permissions reviewed and changed appropriately |
A missing item should have a named owner and next action. It should not disappear simply because the handover date has arrived.
What If the Previous Developer Is Unavailable?
Start with what your business controls.
Gather repositories, accounts, deployment records, invoices, documentation and relevant communications.
An incoming team may need a paid investigation to reconstruct missing information. Some questions may remain unresolved without additional access.
The initial goal is to establish what can be inspected and operated, then define a practical next step.
Avoid committing to a large repair or rebuild solely because the handover material is incomplete.
Discuss Your Application Handover
DOT IT Services helps businesses take over existing applications with clear access, documentation and release arrangements.
Tell us what the application does, what materials are available and when development needs to continue.
Written by DOT IT Services.