Application handover means the receiving organization has authorized access, the necessary materials and the ability to perform agreed operational work without a hidden dependency on the vendor’s laptop or personal account. Make it a documented operating exercise, not just a compressed folder and a presentation. Specify the requirements before project completion so essential ownership questions do not become last-minute negotiations.
App Development should define source, features, testing and handover outputs. Intellectual-property ownership, usage rights and third-party components require appropriate contractual review. Possessing a source-code copy does not automatically settle every legal right.
Separate ownership, access and operating ability
The business might own the repository account without controlling deployment. It might access the source without knowing which version is live. The application might run in the vendor’s account while the client pays the bill. These are different arrangements and should be recorded explicitly.
Maintain an asset register covering repositories, test and production environments, domains, distribution accounts, external services and secret-management locations. For each, name the owner, administrator and recovery route. Do not place passwords or access keys in the register; document where access is managed and how authorized people obtain it.
List exclusions such as separately licensed services, vendor-owned tools and components requiring independent subscriptions. The objective is not to demand transfer of assets the vendor has no right to transfer. It is to expose dependencies, rights and ongoing costs before acceptance.
Demonstrate a build from a clean starting point
Ask someone from the receiving team to build the agreed version in an appropriate clean environment using the repository, instructions and authorized credentials. If it works only on the original developer’s computer, an undocumented requirement or dependency still needs attention.
Instructions should identify required tool versions, dependency installation, environment-variable names and purposes without secret values, test-data preparation and test execution. Do not claim exact binary reproducibility unless that is explicitly required and demonstrated. The immediate requirement is a repeatable build that performs the agreed functions.
Connect the repository to the deployed release through a clear version or reference. Access to the newest repository contents does not establish that those contents produced the running application or the version tested for acceptance.
Worked hypothetical: receiving a booking application
Imagine a business taking over a newly developed booking application. Its handover exercise has three steps: build a test release from an approved reference, deploy it into a business-controlled test environment and return to the preceding version after an agreed unacceptable change. This is a teaching scenario, not permission to disrupt production.
The build succeeds, but deployment fails because an automated job uses an access token tied to a vendor employee. The team records a handover blocker, moves access configuration through an authorized process to an appropriate client-controlled identity and repeats the test. It does not paste the token into a conversation or leave an undocumented dependency because the current application appears healthy.
After deployment, the receiving team creates and amends a test booking, locates relevant logs and alerts and explains what it would do after a later failed release. If nobody can identify who authorizes recovery or handles changed data, the recovery plan is not yet complete.
Deployment needs controls and a decision owner
Infrastructure as Code & CI/CD connects version-controlled configuration, checks, approval gates and recovery steps. Ask which actions are automated, which require human approval and who may change those rules. A working deploy button does not replace an understanding of authority.
GitHub’s environment documentation describes deployment protection rules and notes availability differences by plan and repository type. If GitHub is used, verify the capabilities in the actual account rather than assuming identical review controls are available everywhere.
Where the application depends on cloud infrastructure, the resource map, dependencies and operating assumptions belong in an appropriate Cloud Architecture Design & Review scope. Receiving a diagram alone does not include ongoing infrastructure operation or an unagreed availability commitment.
Recovery also deserves careful boundaries. Reverting an application version may not reverse data or schema changes. The handover should identify which recovery procedures apply, which require specialist intervention and which have actually been rehearsed.
Make acceptance evidence and support boundaries explicit
Software Quality Assurance should provide evidence for the accepted build, executed journeys, unresolved defects and their dispositions. Include the receiving team’s access, build and operating checks in acceptance instead of relying entirely on the vendor’s final demonstration.
Specify support start and end, reporting channels, the distinction between a defect and a new change, coverage hours and responsibility for external services. “Free support” is incomplete without those boundaries.
Once transfer is demonstrated, review vendor access and remove permissions no longer needed through an authorized process. Preserve an action record and avoid disabling a necessary service before coordinating its replacement. Access removal is an operational change, not an administrative afterthought.
A useful closing record lists remaining dependencies, their owners and whether they are accepted or still blocking final handover. This prevents unanswered operating questions from disappearing behind a signed completion note.
Frequently asked questions
Is receiving a source-code archive enough?
No. You need the accepted version, build instructions, dependencies, configuration and authorized service access. Demonstrate that the receiving team can operate what it receives.
Must every account belong to the business?
Identify which assets the business should control under the service and contract, then verify what can actually transfer. The essential point is to avoid an unidentified critical dependency on an individual.
Does restoring the previous application version restore data too?
Do not assume so. Data or schema changes may require a different procedure. Explain the limits of application and data recovery and test appropriate steps.
When should vendor permissions be reduced?
After the receiving team’s access and necessary operations are proven, and in line with the support agreement. Avoid cutting off an automated task before its ownership has moved.
Ask for a handover session led by the receiving team, with the vendor assisting when needed. Demonstrated build, deployment and monitoring ability is stronger evidence than documentation nobody has tried.
Technical source
- GitHub: Managing environments for deployment, reviewed 26 October 2026. Ownership, rights and support conditions require contractual review.
