A practical software project handover checklist: the code, credentials, and docs to collect, how long a handover takes, and what transition support costs.
A software project handover between two teams takes two to six weeks when it is planned, and most of that time goes to collecting access and writing down context, not to new code. Budget roughly 20 to 80 hours of senior engineering time across both teams, plus a two-to-four-week support window where the outgoing team stays available. If you are changing vendors, the checklist below is what keeps a clean exit from turning into a lost password and a missing repository.
The list below is ordered by what is hardest to recover if you miss it.
A handover is a transfer of working assets, not a meeting. Every asset falls into one of a few buckets: code, environments, data, documentation, third-party accounts, and the people who know how it all fits. Miss one and the new team spends its first weeks rebuilding instead of shipping.
Keep this as a spreadsheet you tick off, not a document you read once.
| Asset | What to collect | Why it matters |
|---|---|---|
| Source code | Full repository with commit history and all branches | A zip file is not enough; version history shows why decisions were made |
| Environments | Production, staging, and CI/CD credentials and keys | The new team must build and deploy on its own |
| Data | A recent full backup plus direct database access | Your data is usually worth more than the code |
| Documentation | Architecture notes, runbooks, deployment steps, API docs | Lets the new team ramp up in days instead of weeks |
| Third-party accounts | App stores, payment gateways, DNS, analytics, cloud billing | These often sit in one person's personal email |
| People | A named contact for knowledge transfer during the overlap | Some context only lives in heads |
The first row matters most. Code without credentials is a locked box, and documentation without a working build pipeline is a story, not a runbook.
The timeline depends on how much you already control. If you hold full admin access and the documentation is current, two to three weeks is realistic. If access is partial or the new team insists on a code audit first, plan for four to six weeks.
| Situation | Typical handover | What drives the time |
|---|---|---|
| Full access, current docs, small to mid codebase | 2 to 3 weeks | Onboarding the new team, one overlap sprint |
| Partial access or thin docs | 3 to 5 weeks | Regaining credentials, writing missing runbooks |
| Unknown code quality or an uncooperative old vendor | 4 to 6 weeks | A code audit and risk assessment before any new work |
These are planning ranges, not quotes. A product with three payment integrations and two app stores takes longer than a single web app with one database. The clock starts when you first ask for access, not when you send the termination notice, so start early.
Most vendors do not price a handover as a line item, which is exactly why it gets squeezed. It is usually billed as transition support: hourly time from senior engineers, or a small fixed engagement covering the audit, the runbook, and the overlap.
| Project size | Typical effort | Rough planning range |
|---|---|---|
| Small web or mobile app, one or two services | 20 to 40 hours | $2,000 to $6,000 |
| Mid-size platform with several integrations | 40 to 80 hours | $6,000 to $12,000 |
| Large system with audits, compliance, and data migration | 80 to 150+ hours | $12,000 to $25,000+ |
These figures are effort estimates, not firm quotes. The real cost of a bad handover is not the transition fee; it is the weeks of stalled delivery or an outage while the new team reverse-engineers what the old one never wrote down.
The riskiest window is the gap between "we are leaving" and "we are gone." People get reassigned, access gets revoked, and memory evaporates fast. Collect in this order, and do the first three before you tell the old vendor anything.
If the original contract never assigned IP and source code ownership to you, this is when that gap shows up. Confirm the clause before you start and fix it in the next agreement. Our IP protection guide and contract checklist cover both in detail.
A handover is finished when the new team can operate without the old one. The test: have the new team deploy to staging from the repository alone, and restore a backup and run the app against it, both within the first week. If they cannot, the documentation or the credentials have a gap, and you want to find that while the old team is still around to answer questions.
When a project comes to us mid-flight, our custom software development team starts with a code audit before we talk about scope. A senior engineer reads the repository, checks the build and deployment setup, and writes a short report on what is sound and what is not. Only then do we quote, because an estimate based on the actual code beats one based on a wish.
The handover itself follows the checklist above: full access transfer, a staging deployment in week one, a named engineer as your single point of contact, and overlap hours arranged across time zones so the outgoing team, your team, and our engineers can talk directly in English. We have taken over projects where the previous vendor handed us nothing but a zip file, and we rebuilt the pipeline from there. It works, but it is slower and more expensive than a handover where the checklist was followed.
If you are deciding whether a switch is worth it at all, our vendor switch guide walks through the decision, and the failed project rescue guide covers what to do when the code is the problem. If you are planning a handover now, start with one thing: log into your own repository. If you cannot, everything else waits behind that first step.
Source code with full history, environment credentials, a recent data backup, documentation and runbooks, third-party account access, and a named contact for knowledge transfer. Tick each one off before the old team disengages.
Two to six weeks in most cases. Two to three weeks when you hold full access and documentation is current; four to six weeks when access is partial or the code needs an audit first.
As a planning range, 20 to 80 hours of senior engineering time, or roughly $2,000 to $12,000 depending on project size, plus a two-to-four-week support window. The bigger cost is stalled delivery if the handover is done badly.
Before you notify the current vendor. Secure repository admin, environment access, and a fresh backup first; cooperation usually drops to the contractual minimum once the vendor knows you are leaving.
The new team can deploy to staging from the repository alone and restore the database from a backup, both within the first week. If they cannot, the documentation or credentials still have gaps.
A two-to-four-week overlap helps knowledge transfer, but set a hard end date. Overlaps that drag on become two teams billing you for the same work.
GlobeSoft builds custom software, AI applications, SaaS, FinTech and enterprise systems for clients worldwide. Message us on WhatsApp for the fastest answer, or email us — we typically reply within 24 hours.
Keep reading
How to recover a failed software project: the salvage-or-rebuild decision, a clean code handover, what a rescue actually costs, and how to choose the team that takes it over.
13 min readA vendor-side look at what project management software actually contains, which decisions move the price, and what a realistic build costs.
11 min readChoosing a tech stack is a business decision, not a popularity contest. A practical way to pick the right frontend, backend and database for your product, and how the choice affects cost, timeline and hiring.
10 min readThe RFP questions that separate a real software development partner from a polished sales pitch. What to ask about the team, process, budget, and what happens when a project goes wrong.
9 min readMost software estimates are wrong, and that is not the problem. The problem is not knowing why they're wrong, or which number to trust. Here is how to estimate a custom project so the number means something.
4 min readMonolith vs microservices is not a fashion choice. Here is when each architecture pays off, with real costs and the hybrid most teams should start from.
