Software handover checklist: everything to get from your outgoing developer

This software project handover checklist covers what to get from your developer before they leave: 35 items in eight sections (Code, Accounts, Environments, Data, Docs, Ownership, Knowledge transfer and Prove it). It works for a website handover, a mobile app handover or a full software project takeover; step 2 decides which items show.

Step 1 sets the situation, which changes the email’s opening line. “Adding a second team” keeps the current developer on (see switching developers mid-project), and “Developer is unreachable or gone” swaps the email for a recovery plan.

Which items show for what they built

• 24 items show for every type.
• Repository history, build scripts and runtime versions: every type except no-code apps.
• Domain registrar, DNS, email-sending service and SSL renewal: every type except a database on its own.
• Payment processor, analytics and upload storage: web apps, mobile apps, websites and no-code apps. Mark the payment processor N/A if there are no payments.
• Apple Developer and Google Play accounts: mobile apps only.

The answers, the weights and the formula

Each item starts unanswered and takes one of four answers: In our account, They have it, Don’t know or N/A. Weights are critical 3, important 2, helpful 1: 9 critical, 16 important and 10 helpful items, a total weight of 69 (66 for a web app on its own).

Readiness = Σ(weight × credit) ÷ Σ(weight) × 100 over the visible items: those your types turn on that aren’t marked N/A. Credit is 1 for In our account and 0 for everything else, including They have it and unanswered, because the developer holding something isn’t the same as your company having it. The result is rounded to a whole percent.

Why one missing critical item overrides the score

The nine critical items are repository ownership, the hosting account, the domain registrar, the app-store accounts (mobile only), an agreed date to rotate every credential, database admin access, a current backup, a test deployment by someone other than the developer, and your own admin login. If any visible critical item isn’t In our account, the status reads “You don’t fully control this software yet”, whatever the percentage, and names each gap. Otherwise the rounded score decides: 85% or more is “Ready to hand over”, 50–84% is “Partly ready” and under 50% is “Not ready”.

How the request email is built

The email lists every item marked They have it, under section headings in checklist order, most important first within each section, numbered straight through. Repository, hosting and app-store asks add “Please transfer ownership to our account (not collaborator access).” The subject is “Handover request:” plus your system name, and a reply-by date goes into the closing line. Don’t know items go to a separate “Find out first” list for you, each with a tip on where to start. The downloads and Print add the summary lines and that list.

Example (hypothetical, not client data)

A customer booking web app with no payments, so the payment processor is N/A: 33 visible items, total weight 64. In our account: five critical items (15 points), three important (6) and two helpful (2). They have it: the current backup and three important items. Don’t know: whether anyone else has deployed it. The credential rotation date isn’t answered.

“After” assumes the backup is now in your account, a rotation date is agreed and someone else has deployed to staging: 9 more points, landing exactly on the 50% line.

Assumptions and limits

• The weights are our judgment of what matters most for control, not an industry standard.
• It scores only what you tell it and doesn’t log in to anything.
• N/A takes an item out of the total, which raises the percentage when that item isn’t in your account, so use it only when an item truly doesn’t apply.
• The IP-assignment item asks only whether you’ve found the clause. It isn’t legal advice.
• An answered item can be changed but not blanked; “Clear answers and draft” resets everything.

Not sure the project itself is on track? Try the software project health check or browse all free tools.

Pick “Developer is unreachable or gone” and the tool replaces the email with a recovery plan. It says up front that what you can recover depends on what you can access, so it makes no promises about outcomes. The order:

1. Secure what you can log into now. Change passwords and turn on two-factor authentication for email, the domain registrar, hosting, app stores and the app’s admin area. Hold off on rotating API keys until you know what uses them.
2. Domain. If it isn’t in your company’s name, or nobody can log in, contact the registrar’s support as the business owner. ICANN Lookup shows a domain’s current registration data. This step is skipped for a database on its own.
3. Hosting. If your company pays the bill, contact the provider’s support as the billing holder. If the developer pays it, find out which provider it is; the software can go offline if that bill stops being paid.
4. Code. Check whether the repository is in an account your company owns. If not, request the code in writing and check your contract for an ownership clause (not legal advice).
5. App stores (mobile apps only). Check whose developer accounts publish your apps, and request a transfer in writing if they’re the developer’s.
6. Have an engineer assess what’s recoverable from the code, hosting, data and backups you can reach.

Each step lists your answers to its related items, and the plan ends with “Items to request in writing”: everything marked They have it, most important first. The developer disappeared guide covers the first 48 hours in more detail. For help with what’s left, see software project rescue; your first call is with an engineer.