A software handover checklist is the only thing standing between an orderly change of development partner and a system that nobody left in the building knows how to rebuild. When a relationship ends, the outgoing supplier stops caring about your roadmap on the last billable day. Everything they understood but never wrote down walks out with them, and what remains is whatever you thought to ask for while you still had leverage.
That leverage is the part businesses waste. The best moment to work through a software handover checklist is before you give notice, while there is still an invoice to be paid and a reference to be protected. The worst moment is three weeks after the final payment cleared, when your emails go unanswered and the new team is quoting for a rewrite because they cannot get the application to build on a clean machine.
This guide sets out a practical software handover checklist for changing development partners: what has to transfer, in what order, who signs it off, and how to prove it actually worked. It covers repositories and history, infrastructure and secrets, documentation, licences, data and the contractual terms that make the whole exercise enforceable. If you are still deciding whether to move at all, our guide to rescuing a failing project is the better starting point.
Table of contents
- Why a Software Handover Checklist Decides What You Keep
- What a Complete Software Handover Checklist Includes
- The Software Handover Checklist: Code, Repositories and Build
- The Software Handover Checklist: Infrastructure, Accounts and Secrets
- Documentation and Knowledge Transfer That Survives the Exit
- Contracts, IP and the Exit Clauses That Make Handover Possible
- Timeline and Cost of a Software Handover Checklist
- Verifying the Software Handover Checklist Before You Sign Off
- Common Software Handover Checklist Mistakes
- Frequently Asked Questions
- References
Why a Software Handover Checklist Decides What You Keep
Handover is not an administrative formality at the end of an engagement. It is the point at which an intangible asset either becomes yours or quietly stays with somebody else. A weak transition does not announce itself; it shows up months later as an inability to deploy, patch or extend the thing you paid for.
The asymmetry is entirely in the supplier’s favour
Your outgoing partner knows which environment variable breaks the build, which integration is held together by a scheduled job on a forgotten server, and which part of the codebase everybody avoids. You know none of it. That imbalance is normal and not necessarily malicious, but it means the burden of asking precise questions sits with you, which is exactly what a software handover checklist is for.
Goodwill expires faster than you expect
Even suppliers who part on excellent terms redeploy their people within days. The engineer who wrote your payment integration is on somebody else’s project by the end of the month, and by the end of the quarter they have forgotten the details. Every week you delay the software handover checklist reduces the quality of the answers you can still get.
What “we handed everything over” usually means
It usually means a zip file of source code and a link to a shared drive. That is a fraction of the estate, and a fraction of any serious software handover checklist. A working system is code plus build configuration plus infrastructure plus credentials plus data plus the reasoning behind a hundred decisions, and only the first of those is ever transferred by default.
The cost of getting it wrong is not proportional
A missing README costs an afternoon. A missing deployment pipeline costs a fortnight. A missing DNS registrar login can cost you your domain. The distribution of handover failures is long-tailed, which is why a software handover checklist that looks excessive is still cheaper than the one gap it prevents.
| Asset | Usually handed over | Often withheld or forgotten | Cost if missing |
|---|---|---|---|
| Application source code | Yes, as a snapshot | Full commit history and branches | Low to moderate |
| Build and deploy pipeline | Rarely | CI configuration, runners, secrets | High |
| Cloud accounts | Sometimes, as a user | Ownership and billing root access | Very high |
| Domains and certificates | Rarely | Registrar login, renewal control | Existential |
| Third-party service accounts | Rarely | Payment gateway, email, analytics | High |
| Architecture documentation | Sometimes, outdated | Decision rationale, known issues | Moderate to high |
| Test suites and fixtures | Partially | Test data, environment setup | Moderate |
| Design source files | Rarely | Editable originals, brand assets | Moderate |
What a Complete Software Handover Checklist Includes
Before working through the detail, it helps to see the shape of the whole thing. A complete transition has six workstreams, and a credible software handover checklist covers all six rather than dwelling on the one your outgoing supplier finds easiest to satisfy.
Code and version control
Everything that compiles into the product: application repositories, infrastructure definitions, database migrations, scripts, and the complete history behind them. History matters more than people assume, because it is the only record of why the system is shaped as it is.
Environments and infrastructure
The servers, containers, managed services, networks and DNS entries the application runs on, together with ownership of the accounts they live in. This is the workstream where a software handover checklist most often reveals that you do not own what you thought you owned.
Credentials and secrets
API keys, service accounts, certificates, signing keys and third-party logins, along with a plan to rotate every one of them once the outgoing team no longer needs access. Transfer and rotation are two separate items on the software handover checklist and both are mandatory.
Documentation and knowledge
Architecture overviews, runbooks, deployment instructions, known defects, and the informal knowledge that only exists in someone’s head until a structured session drags it out. This is the part of the software handover checklist that decays fastest after the engagement ends.
Legal and commercial
Intellectual property assignment, third-party licence obligations, data processing arrangements, and confirmation that nothing in the codebase carries an encumbrance you did not agree to. Our companion guide to source code ownership covers the ownership question in depth.
Data
Production data, backups, retention settings and a tested restore, plus the lawful basis and processor arrangements for moving any of it. Data is the workstream where mistakes are least reversible and most regulated.
The Software Handover Checklist: Code, Repositories and Build
Source code is the item everybody remembers, which is precisely why it is the one people check least carefully. Receiving a folder of files is not the same as receiving a project you can develop.
Transfer repository ownership, not a copy
The first technical item on the software handover checklist is to ask for the repositories to be transferred into an organisation account you own, rather than exported. A transfer preserves history, issues, pull requests and review comments; an export preserves none of it. Every major platform supports this, and the GitHub repository transfer process takes minutes when somebody with the right permissions is still employed to do it.
Insist on the complete commit history
A single squashed commit labelled “initial import” is a red flag on any software handover checklist. History tells your new team when a defect was introduced, who to ask, and which experiments were already tried and abandoned. It is also the practical evidence of authorship if ownership is ever disputed.
Verify a clean-machine build
The single most valuable test in the whole software handover checklist costs one day: give a developer who has never touched the project a clean laptop, the repository and the documentation, and ask them to produce a running application. If they cannot, the handover is incomplete regardless of what has been formally delivered.
Capture the build and deployment pipeline
Continuous integration configuration, deployment scripts, environment definitions and release procedures must all transfer. Pipelines often live in the supplier’s own tenancy, which means the configuration transfers but the runners, credentials and permissions do not. Teams that follow modern DevOps practices usually have this in version control already, and the ones that do not will need to write it down.
Inventory every dependency and licence
Ask for a dependency manifest with versions, and a note of any licence that imposes obligations on you. Machine-readable inventories in the SPDX licence list format make this straightforward, and compliance frameworks such as OpenChain exist precisely because inherited open-source obligations are easy to miss.
The Software Handover Checklist: Infrastructure, Accounts and Secrets
This section of the software handover checklist is where the genuinely expensive failures live. Code can be rewritten. A domain name lost to an unpaid renewal on somebody else’s card cannot always be recovered.
Establish who legally owns each account
Work through every account the system depends on and record, on the software handover checklist itself, the legal owner, the billing owner and the technical administrators. Cloud subscriptions, DNS registrar, certificate authority, email delivery, payment gateway, error tracking, analytics and app store listings all belong on the list. Anything registered to an individual at the supplier is a liability until it is moved.
Move billing to your own payment method
Ownership follows the invoice more often than the paperwork suggests. If the outgoing supplier’s card is still funding your infrastructure, you are one cancelled subscription away from an outage. Transfer billing first, because it is the change most likely to be quietly refused later.
Rotate every credential after access ends
Transferring secrets is not the same as securing them. Once the outgoing team’s access is formally revoked, rotate API keys, service account passwords, database credentials, signing keys and certificates. Guidance such as the OWASP secrets management cheat sheet is a sensible baseline, and the exercise doubles as a useful audit of how many secrets exist that your software handover checklist never listed.
Document the network and access model
Firewall rules, VPN configuration, IP allow-lists, bastion hosts and identity provider integrations all need to be written down. The NCSC cloud security collection is a reasonable reference for what good looks like, and reviewing it alongside your cybersecurity arrangements often surfaces access nobody remembered granting.
Confirm monitoring, alerting and backups survive the move
Alerts routed to the outgoing supplier’s inbox stop being useful the moment the engagement ends. Reroute monitoring, confirm backup jobs still run under accounts you control, and — this is the part almost everybody skips — perform an actual restore before the old team disappears.
| Phase | Typical duration | Who leads | Exit criteria |
|---|---|---|---|
| 1. Inventory and audit | 1-2 weeks | You, with both suppliers | Signed asset register |
| 2. Account and IP transfer | 1-2 weeks | Outgoing supplier | You own every account |
| 3. Documentation sprint | 2-3 weeks | Outgoing supplier | Runbooks accepted in writing |
| 4. Shadowing and Q and A | 2-4 weeks | Incoming supplier | New team deploys unaided |
| 5. Acceptance testing | 1-2 weeks | You | Clean-machine build passes |
| 6. Access revocation | Days | You | All credentials rotated |
| 7. Warranty and support tail | 4-12 weeks | Outgoing supplier | Defined response commitment |
Documentation and Knowledge Transfer That Survives the Exit
Documentation is the workstream everybody underestimates and the one that determines whether your new partner spends month one shipping or month one guessing. Treat it as a deliverable with acceptance criteria, not a favour.
Ask for decisions, not descriptions
A document explaining what the code does is worth far less than one explaining why it does it. Which alternatives were rejected, which constraint forced the awkward design, which supplier integration dictated the data model. Lightweight architecture decision records are the cheapest format, and they are the section of the software handover checklist that ages best.
Demand runbooks for the things that go wrong
For each recurring operational event — a failed deployment, a stuck queue, a certificate renewal, a data import — you want a written procedure someone unfamiliar can follow at three in the morning. Ask which incidents occurred in the last twelve months and add a runbook for each to the software handover checklist.
Insist on an honest known-issues register
Every system has parts its authors are not proud of. A candid list of fragile areas, unresolved defects and deferred work is more valuable than a polished overview, and asking for it explicitly gives an outgoing team permission to be honest. Pair it with a technical debt audit if the estate is large.
Run recorded live sessions, not just written handover
Schedule working sessions where the outgoing engineers walk the incoming team through the system while screen sharing, and record them. People explain out loud what they would never write down, and the recordings remain useful long after everyone involved has moved on.
Set acceptance criteria for documentation itself
Documentation is accepted when the incoming team, not the authoring team, confirms it is sufficient. Making the receiving party the acceptor is the single change that most improves quality, and it belongs in the contract alongside the software handover checklist rather than in an email.
Contracts, IP and the Exit Clauses That Make Handover Possible
A software handover checklist is only enforceable if the underlying agreement supports it. Most disputes at exit are not about bad faith; they are about terms that were never written because nobody wanted to discuss the ending at the beginning.
Confirm intellectual property has actually been assigned
Under UK law, work created by a contractor belongs to the contractor unless assigned in writing — the position is set out in the Copyright, Designs and Patents Act 1988 and summarised in the government’s guidance on ownership of copyright works. A paid invoice does not transfer copyright. Check the assignment exists before you give notice, not after, because every other item on the software handover checklist assumes it.
Separate your code from the supplier’s reusable components
Many agencies build on internal frameworks they licence rather than assign. That is legitimate, but you need it identified and licensed on terms that survive the relationship. An unidentified proprietary component discovered mid-handover is the most common cause of a stalled transition.
Write the exit obligations into the contract
The clause should specify a notice period, a defined transition assistance period, the day rate for that assistance, the deliverables expected, and who accepts them. Our software development contract guide covers the drafting in detail; the short version is that a software handover checklist attached as a schedule is worth more than a paragraph of good intentions.
Handle personal data as a controller, not an afterthought
If the supplier processed personal data on your behalf, the arrangement is governed by a processor contract, and the end of that arrangement triggers deletion or return obligations. The ICO’s guidance for controllers and processors sets out what those terms must contain, and confirming deletion in writing closes the loop on the data section of the software handover checklist.
Keep a retention window before you switch anything off
Do not revoke the outgoing supplier’s access on the same day you take ownership. Keep a short overlap so that questions can still be answered, then revoke on a defined date and rotate everything, which is why revocation sits at step six of the software handover checklist rather than step one.
Timeline and Cost of a Software Handover Checklist
Transitions fail on timing more often than on technique. Businesses give one month’s notice, assume the software handover checklist can be completed inside it, and discover that the outgoing team’s contractual obligation ended with the notice period.
Budget six to twelve weeks for a real transition
For a system of moderate complexity, a properly executed software handover checklist takes six to twelve weeks from inventory to revocation. Smaller applications compress to three or four; anything with multiple integrations, regulated data or bespoke infrastructure runs longer.
Expect to pay for transition assistance
Handover is billable work, and pretending otherwise produces the worst possible outcome: an unpaid supplier doing a minimum-effort job. Budget for a defined number of days at the contracted rate. Ten to twenty days of a senior engineer’s time is typical, and it is the best-value money in the entire switch.
Overlap the two suppliers deliberately
Running both partners in parallel for a few weeks feels wasteful and is not. The incoming team asks better questions of the software handover checklist than you can, because they know what they will need. Structured vendor management practice treats this overlap as standard rather than exceptional.
The cost of skipping it lands in the first quarter
Where a handover is thin, the incoming partner spends their first months reverse-engineering rather than delivering. That discovery effort is invisible in the switching decision and highly visible in the first invoice, which is the strongest financial argument for treating the software handover checklist as a funded project.
Verifying the Software Handover Checklist Before You Sign Off
The difference between a handover and a paperwork exercise is verification. Every item on your software handover checklist needs a test that either passes or fails, performed by the receiving team while the outgoing team is still contractually available.
The clean-machine build test
A developer with no prior exposure clones the repository, follows the written setup instructions and runs the application locally. No verbal hints, no messages to the old team. This test alone catches the majority of documentation gaps a software handover checklist is designed to expose.
The unaided deployment test
The incoming team deploys a trivial change to production, or to a production-equivalent environment, using only the transferred pipeline and documentation. Deployment is where undocumented steps hide, because they were performed by the same person every time for two years.
The restore test
Restore a backup into a fresh environment and confirm the application runs against it. Backups that have never been restored are best treated as decorative, and this is the test most likely to reveal that the backup job has been silently failing.
The access audit
Enumerate every account and confirm that you hold administrative access, that the outgoing supplier’s access has been removed on the agreed date, and that no shared credential remains in use. Verification standards such as the OWASP ASVS provide a structured basis if you want something more rigorous than a spreadsheet.
The delivery-metrics baseline
Record deployment frequency, lead time and change failure rate for the outgoing team, so you have a baseline against which to judge the new one. The DORA research programme defines these consistently, and having a number from before the switch prevents six months of unfalsifiable argument afterwards.
Common Software Handover Checklist Mistakes
Most failed transitions repeat a small number of avoidable errors. Recognising them is usually enough to prevent them, because none of them is subtle once named.
Giving notice before completing the inventory
Notice changes the incentives immediately. Complete the asset inventory, confirm account ownership and verify the IP assignment while the relationship is still commercially normal, then give notice. Reversing that order is the most common mistake on this list.
Accepting a code dump as a handover
A zip file is evidence of nothing. Without history, pipeline, infrastructure and documentation, a code dump is raw material for a rewrite rather than a transferable asset, and accepting one usually means the software handover checklist was never applied at all.
Letting the outgoing team mark their own homework
If the party producing the documentation also decides whether it is adequate, it will always be adequate. Acceptance must sit with the incoming team, and a software handover checklist that omits named acceptors is decoration.
Forgetting the long-tail accounts
Payment gateways, transactional email providers, SMS gateways, app store developer accounts, code signing certificates and analytics platforms are all easy to overlook and all painful to recover. Walk the estate account by account rather than from memory.
Assuming the new partner will find the gaps
An incoming supplier will discover missing pieces, but they will discover them after the outgoing team is unreachable and after you have started paying for the discovery. Bringing the incoming team into the handover early is what converts that discovery from an expense into a checklist item.
| Signal during exit talks | What it usually means | Your response |
|---|---|---|
| Refuses to transfer repository ownership | History or authorship concerns | Check the IP assignment immediately |
| Cloud accounts in their name only | No separation was ever set up | Move billing before giving notice |
| “Documentation is in the code” | There is no documentation | Fund a documentation sprint |
| Proprietary framework revealed late | Licence dependency you did not price | Negotiate perpetual licence terms |
| Handover offered free of charge | Minimum effort is being planned | Pay for defined days and deliverables |
| Open, well-organised, asks who is taking over | Professional exit | Move quickly while goodwill lasts |
Frequently Asked Questions
How long should a software handover take?
Six to twelve weeks for most business applications, measured from inventory to credential rotation. Simple systems finish in three to four weeks; regulated or heavily integrated estates take longer. The variable that matters is not system size but how much of the software handover checklist was anticipated in the original contract.
Should we pay the outgoing supplier for handover?
Yes, unless your contract already includes transition assistance. Paid handover produces cooperation and a defined deliverable; unpaid handover produces a zip file. Ten to twenty days of senior engineering time is a normal budget and comfortably cheaper than the rediscovery it prevents.
What if the supplier refuses to cooperate?
Establish first what they are contractually obliged to provide, then work the software handover checklist from the outside in: registrar and cloud provider account recovery processes, your own backups, and any assets already in your possession. Where the relationship has genuinely broken down, a paid, narrow, time-boxed engagement often still beats litigation.
Can we run the software handover checklist ourselves?
Yes, if you have someone technical who can judge whether a deliverable is real. If you do not, have the incoming partner run it — they have both the expertise and the incentive, because every gap becomes their problem. Sensible outsourcing strategies assume the receiving team leads verification.
What is the single most important item?
Ownership of the accounts. Code can be rebuilt and documentation can be recreated, but a domain, a cloud tenancy or an app store listing controlled by somebody else is a hostage rather than an asset. Everything else on the software handover checklist is recoverable; that one is not always.
When should we start planning the handover?
At the start of the engagement, not the end. The terms that make a software handover checklist enforceable are all agreed before work begins, and a supplier who negotiates them willingly at the outset is telling you something useful about how the relationship will end.
