There is a moment, usually in the final fortnight before a launch, when everyone on a software project is focused on the wrong thing. The developer is fixing last-minute bugs. The business owner is checking the colour of a button. Nobody is asking who will actually be in charge of the system once the launch party is over.
That oversight is expensive — not immediately, but three months later, when the developer has moved on, the admin password is locked in someone's personal email account, the database back-up has never been tested, and a bug appears on a Monday morning.
A handover plan is not a formality. It is the work that makes the launch mean something, and it needs to start well before the champagne is ordered.
A successful launch can still leave the business vulnerable if one developer controls all the access, all the knowledge and all the recovery options.
Why handover planning belongs at the beginning, not the end
Most projects treat handover as a closing task — something to sort out after the last feature is signed off. This is backwards. By the time the final week arrives, the developer is under pressure to finish, the business is excited to go live, and nobody has the time or the headspace to do handover properly.
The practical consequence is that handover gets rushed. Access credentials are emailed across in a single file. Documentation is promised and never written. The developer explains how the system works in a one-hour call that nobody records. A month later, when someone needs to remember any of it, nobody can.
Handover planning should begin at the same time as everything else. When you are agreeing the scope of the project, agree the handover deliverables too. Make it a line item in the contract. Define what the business expects to receive — not just a working application, but the means to operate and maintain it independently.
What the business must actually receive
A finished application is only one of the things that changes hands at the end of a project. The business should also receive:
- Access credentials. Every account, login and administrative panel that belongs to the project — the hosting environment, the domain registrar, the email service, the payment gateway, the analytics dashboard, the code repository. These should be transferred into accounts the business controls, not shared from the developer's personal accounts.
- The source code. You should own a copy of the codebase in a repository under your own organisation's account. If the developer disappears, the code must not disappear with them.
- Technical documentation. At minimum: how to deploy an update, how to restore from back-up, what the third-party services are and what each one does, and what to do if the site goes down. This does not need to be a 200-page manual. A clear, honest README will do.
- Operational instructions. The practical day-to-day tasks that an internal administrator will need to perform — adding users, running reports, changing content, processing orders. Written for a non-technical person, not for another developer.
None of these are unreasonable to ask for. Any professional developer will expect to provide them. Resistance to handing over source code or credentials is a serious warning sign, and worth addressing before the project goes any further.
Training for the people who will actually use the system
There are usually two groups who need training, and they need different things.
Administrators — the people who manage the system from the back end — need to understand how to carry out operational tasks, handle common problems and know when to escalate. They do not need to understand the code, but they do need to understand the system's logic well enough to keep things running.
Everyday users need to be comfortable with the parts of the application they will actually touch. A booking system, an internal dashboard, a client portal: each has its own flows and quirks. Training does not need to be elaborate — a short screen-recorded walkthrough or a one-page reference card will often be enough.
The test of adequate training is not whether people sat through a session. It is whether they can carry out their tasks without calling for help in the first week.
Training is not complete when the session ends. It is complete when the team can operate the system without needing to phone someone.
Support arrangements: knowing who to call and how fast they will answer
Every application will need attention after launch. Bugs will surface. Requirements will change. Something will behave unexpectedly. The question is not whether support will be needed — it is whether there is a clear, agreed arrangement for providing it.
Before launch, agree in writing:
- What counts as urgent. A payment system being down is urgent. A minor display glitch is not. Define the categories clearly so that both sides have matching expectations.
- Who responds, and how quickly. A response-time commitment — even a modest one — is far more useful than a vague promise of ongoing availability. If the developer is moving on to other clients, a formal support retainer with agreed hours and rates is the honest way to handle it.
- What is out of scope. New features are not bug fixes. Make sure everyone agrees on the distinction before the first request arrives.
If the original developer will not be available for ongoing support, the handover plan must include enough documentation that a new developer could pick the project up without starting from scratch. The businesses that sail through that situation are the ones with decent docs and source code they actually own.
The backup plan: recovery, passwords and supplier continuity
A good back-up is not the same as a back-up that exists. It is a back-up that has been tested, that can actually be restored, and that is stored somewhere the business controls.
Before launch, confirm:
- Back-ups are running automatically and going to a location that is independent of the main hosting environment.
- A restoration test has been completed. Ask the developer to demonstrate a restore from back-up before sign-off. If this has never been done, you do not know whether your back-ups work.
- Passwords are stored properly. A shared spreadsheet in someone's email is not a password policy. Use a proper password manager — something like Bitwarden, which has a free tier adequate for small teams — and ensure at least two people in the business have access to it.
- All third-party suppliers are identified. If the hosting provider, the email service or the payment gateway has a problem, who contacts them? Do you have the account credentials to do so?
Supplier continuity is easy to overlook because it feels unlikely. But probably fine is not good enough when the stakes are a live application serving customers.
Practical steps: preparing your handover before you need it
- Build handover into the contract. Define the deliverables — code repository, credentials, documentation, training sessions — as accepted criteria for project completion, not as afterthoughts.
- Audit every account the project touches. List every third-party service, hosting environment, domain and tool used in the project. Confirm that each one is registered to an account the business controls, or that transfer is scheduled before launch.
- Request documentation in stages. Do not wait for a single handover document at the end. Ask for incremental notes as features are completed — these are easier to write when the code is fresh and easier to review when there is still time to improve them.
- Set up a password manager before launch. Do not let credentials exist only in the developer's memory or personal accounts. Bitwarden Free or a shared Google Drive folder with strictly controlled access are both workable starting points.
- Test your back-up. Before signing off the project, ask for a demonstrated restoration from back-up. One test is worth ten assurances.
- Agree support in writing. Capture the post-launch support arrangement — response times, scope, rates — in a brief document signed by both parties before launch day.
The handover checklist is not the end of the relationship between business and developer. It is the foundation that makes everything after launch possible.
The practical shape of a ready handover
Think of handover readiness in five areas: access (do you control every account?), code (do you own the source?), documentation (could a new developer find their way around?), training (can your team operate independently?), and support (do you know who to call and what to expect?).
If any one of those five areas is blank on launch day, a failure will be very hard to recover from. A problem with good documentation and clear contacts is manageable. A problem where nobody knows the admin password and the developer is on holiday is not.
Handover is not glamorous, but it is the difference between owning a system and renting access to someone else's knowledge. Start the checklist early, complete it honestly, and the launch party will mean what it should: a beginning, not a gamble.
