The first line of a software project handover checklist is the date access changes hands: the day the repository, the hosting and every provider account stop being the builder’s. Every other line counts from it, and item 5 rotates every credential the builder could still use. The 20 items run in 5 groups, each with a test the receiver runs.
The software project handover checklist
A software project handover checklist is 20 items in five groups: access and ownership, code and environments, documents, acceptance, and support terms. Every item has a test the receiver runs, not a box the builder ticks, and both sides sign the list on the date access changed hands.
This list covers the handover itself. The wider picture, and what you should leave with, is what a developer handoff looks like. The agency’s side of the same list is how to hand over an app to a client, and the receiver’s side is owning an app someone else built.
The items and their tests are my working checklist. The handover date goes at the top, above item 1. Each group below starts with what has to be true; the table after the groups says who checks each item and what the test and its evidence are.
Access and ownership, items 1 to 5, come first, because every other test needs the receiver to hold the accounts.
- (1) The repository belongs to the receiver’s account or organization.
- (2) The hosting project sits in the receiver’s account or team.
- (3) The domain is in the receiver’s registrar account.
- (4) Every provider account is owned by the receiver, and the builder can be removed from it.
- (5) Every credential the builder could use has been rotated after the transfer.
The repository move follows GitHub’s repository transfer steps: someone with administrator access to the repository opens its Settings, goes to the Danger Zone and chooses Transfer. Three conditions from that page matter at a handover. A transfer to a personal account waits for the new owner to accept it, and the invitation expires if it is not accepted within one day. “The original owner of the repository is added as a collaborator on the transferred repository”, so removing the builder is a separate step, and webhooks, secrets and deploy keys stay associated with the repository after the move. And a private repository transferred to a GitHub Free account loses access to features like protected branches and GitHub Pages.
Item 4’s account list is the provider inventory a founder should hold. Which accounts have to end up in the founder’s name, and why, is covered under the nine things that have to be in your name; this list gives each one a test and leaves the reasons there.
Deliverable 2.8 of the Production Hardening Sprint, provider account ownership, is verified this way: produce an inventory listing each provider, the owning account, the owner role holder, and the date the previous builder’s access was removed.
Rotation needs a waiting period before its test means anything. On Stripe, “When you rotate a key in the Dashboard, both the old and new keys work for up to 7 days”, unless you pick Now as the expiration, in which case the old key is deleted. A check run straight after a rotation can still see the old key work, so run it once the expiry you set has passed. Stripe keeps webhook signing secrets apart from API keys, under each webhook endpoint, so they go on the rotation list as separate lines. Doing it without downtime is a matter of how to rotate API keys safely.
Three of the audited apps had a real secret permanently in git history: a webhook signing secret, a live AI-provider key, and a Stripe test key with its webhook secret. Those three come from 21 third-party apps I audited in June and July 2026, a set I chose rather than a random sample, so the count describes those apps and is not a rate for AI-built apps in general. My reading: a secret in history stays readable to anyone with a clone, which is why item 5 is rotation, not deletion.
With the accounts in hand, the code and environments group proves the receiver can run, change and restore the app without the builder. If you are unsure what a staging copy should be, start from what a staging environment is.
- (6) An environment inventory lists every environment and what each one connects to.
- (7) A deploy from a fresh clone goes out through the receiver’s own pipeline.
- (8) A new machine gets from clone to running by following the setup guide alone.
- (9) The data model is written down, and a backup has been restored.
When item 8 fails, the symptom is a developer who cannot run the project locally. The restore in item 9 belongs on a database backup checklist for startups, with the date of the last successful restore.
Then the paperwork. These four documents are the set of documentation templates for development handover, and each one is checked by someone who did not write it.
- (10) The README and a map of the repository.
- (11) The runbooks.
- (12) The architecture diagram.
- (13) The readiness report and its evidence pack.
For the README, the starting point is what belongs in a README. The runbooks follow a runbook template, the diagram comes from how to create an architecture diagram, and the report and evidence pack are the core of technical documentation for investors.
Acceptance, items 14 to 16, is where the receiver stops reading and starts running things.
- (14) A readiness review meeting has been held, with its decisions written down.
- (15) The receiver has run the acceptance check described below.
- (16) The handover session has been recorded.
The meeting runs from a production readiness review checklist, and planning the recording is a matter of how to run a technical handover session.
The last four lines are support terms, written down so both sides can point to them later instead of relying on a promise to help.
- (17) The defect window: how long the builder fixes defects in the delivered work.
- (18) The question window: how long the receiver can ask questions.
- (19) The channel those reports and questions go through.
- (20) The start and end date of each window.
What to put in each of those terms is a post-launch support checklist.
Who checks each item, and the test with its evidence:
| # | Item | Who checks | Test and evidence |
|---|---|---|---|
| 1 | Repository | Receiver | The repository shows under the receiver’s account or organization; a transfer to a personal account was accepted within its one-day window. Evidence: the repository’s settings page. |
| 2 | Hosting | Receiver | The receiver’s account is the owner on the host’s team page. Evidence: a screenshot of that page. |
| 3 | Domain | Receiver | The registrar account and the renewal card are the receiver’s. Evidence: the registrar page with the renewal date. |
| 4 | Provider accounts | Both | Each provider has the receiver as owner and a date when the builder’s access was removed. Evidence: the inventory. |
| 5 | Credentials | Receiver | The old key fails once the expiry set at rotation has passed. Evidence: the failed call and the rotation date. |
| 6 | Environments | Receiver | The receiver opens each listed environment and confirms what it connects to. Evidence: the inventory with a date per line. |
| 7 | Deploy | Receiver | A small change from a fresh clone goes live through the receiver’s pipeline. Evidence: the deploy log. |
| 8 | Local setup | Receiver | Someone who has never run the app reaches a running copy using only the setup guide. Evidence: the guide version and the questions they had to ask. |
| 9 | Data and backup | Receiver | A backup restored into a copy opens, and its tables match the data model. Evidence: the restore date and what was checked. |
| 10 | README | Receiver | A new reader finds the entry points, scripts and folders from the README alone. Evidence: the README’s commit. |
| 11 | Runbooks | Both | The receiver follows the deploy and rollback runbooks without help. Evidence: the date of that run. |
| 12 | Diagram | Receiver | Every box on the diagram matches a service or account in the inventory. Evidence: the diagram’s version. |
| 13 | Report and pack | Receiver | Every failed check in the report is marked accepted or fixed. Evidence: the report’s version. |
| 14 | Review meeting | Both | The meeting happened and its decisions are written. Evidence: the notes. |
| 15 | Acceptance check | Receiver | The three acceptance steps are done. Evidence: their dated results. |
| 16 | Session | Both | The recording sits in an account the receiver owns. Evidence: the file or link. |
| 17 | Defect window | Both | What counts as a defect, and for how long, is written. Evidence: the signed terms. |
| 18 | Question window | Both | What questions are covered, and for how long, is written. Evidence: the signed terms. |
| 19 | Channel | Receiver | One test message through the channel gets a reply. Evidence: the message and the reply. |
| 20 | Dates | Both | Every window has a start date and an end date. Evidence: the signed document. |
The table is the project handover checklist template: copy its four columns into a sheet and add a result column and a date column. When the builder is one freelancer rather than an agency, the developer handover checklist is the same 20 lines, because a small team leaves the same accounts and keys behind. An internal IT team taking a system over from a vendor runs it unchanged, as a system handover checklist with the IT team in the receiver column. For an agency, the client project handover checklist puts the client in that column. A vendor handing a custom build to a customer fills in the customer handover checklist the same way.
A project transfer checklist, for moving an app between two of your own companies, is mostly the access group. When an outside team passes day-to-day support to an in-house person, the support group becomes the IT support handover checklist. A software project closeout checklist is this list with the last group signed; I count a project as closed when the support dates are written down, not when the last commit lands. For an example of a handover checklist with every result filled in, the filled example further down runs all 20 rows on one app.
How to fill it in
Fill the document from the checklist, test by test, so every line in it has a result behind it.
The handover document: format and template
A handover document for a software project has six parts: the parties and the date, the asset table with the receiver’s test results, the checklist with dates, the documents delivered with version references, the support terms, and two signatures. The format is the table, not the file type.
On one page, a handover document looks like this:
| Part | What it holds |
|---|---|
| Parties and date | Who hands over, who receives, and the date access changes hands. |
| Asset table | Repository, hosting, domain, each provider account and each credential, with the owning account and the receiver’s test result. |
| Checklist with dates | Every checklist item, each with its result and the date it was checked. |
| Documents delivered | README, runbooks, diagram, report and evidence pack, each with a version reference (a commit, a file date or a version number). |
| Support terms | The defect window, the question window, the channel, and the start and end dates. |
| Signatures | One signature and date for each side. |
Examples of handover documents vary in layout; in my working format these six parts are the fixed core, and the filled example below shows the checklist part completed for one app. A project handover document template in Word or Google Docs is the six headings with empty tables under them. In Excel, put each part on its own sheet, so a project handover template in Excel opens on the parties and ends on the signatures. For an IT project, the handover checklist template in Excel is the checklist sheet: one row per item, with columns for who checks, the test, the result and the date.
What makes it a software product handover document template rather than a general one is the asset table and the test results in the checklist part. The project handover document format for a software developer is the same six parts with the technical rows filled: repository, hosting, domain, providers and credentials in the asset table.
To prepare a project handover document, fill the asset table from the access group first, because every later row depends on who owns what. Before anything is filled in, the same file is a document handover form template: six headings, empty rows and a signature line. Built inside a project management tool, a project management handover template works too, as long as the six parts are its fields. Handover documentation software is optional; a wiki page or a folder in the repository holds the six parts as well as a dedicated tool does.
To make a handover report, run the tests and write each result and date into the document; a project handover report template is the document with those result columns added. Once both sides sign, export it: the project handover document PDF is the copy each side keeps, and a project handover procedure PDF, if a company asks for one, is the checklist table printed in item order. Exported to PDF, the filled example below works as a handover report sample.
An agency closing a job adds a project completion handover letter to the client: three or four sentences on top of the signed document saying what changed hands and when support ends. There is no file to download here; copy the tables. The documents the table refers to are their own job, covered in how to write technical documentation for a vibe-coded app.
Acceptance: the test before the signature
Acceptance of a handed-over app is three things the receiver does: read the known failures and accept or fix each one, run the core user flows, and perform one deploy and one rollback. A user acceptance testing checklist is that middle step, written as flows with expected results.
My working rule has three lines, each done by the receiver, not the builder:
- The readiness report’s failures are read, and each one is accepted or fixed.
- The core flows are run by the receiver, using the smoke suite from how to write end-to-end smoke tests.
- One deploy and one rollback are done by the receiver.
For the flows in the second line, write each as steps with what should happen at the end: sign up with a new email, then expect the welcome screen and a new user row. A flow without its expected result is a demo, not a check. The software acceptance checklist the document records is those three lines, each with the date it passed.
When a developer leaves
A handover checklist when a developer leaves is the same 20 items run in their last week, in my working order: access and ownership first, the handover session recorded mid-week, the documents next, and credentials rotated on the last day. Rotating last matters because the developer still needs working keys until they stop working on the app.
The receiver’s side of that week is the same as for any takeover of someone else’s app. What a founder hands the developer who takes over is a separate packet, set out in what to give a developer taking over your app. The filled example below has one contractor leaving, so its rows are examples of a handover list for a leaver. Copy that table as a sample of a handover checklist, then change the dates and names of the accounts.
A filled example
This example is an illustration with its assumptions stated, not a client’s handover. An agency hands a Next.js and Supabase app with live Stripe payments to a founder, and one contractor who worked on it is leaving at the same time. Days are counted from the day the work starts.
| Item | Result | When |
|---|---|---|
| Repository | Transferred to the founder’s organization; contractor removed as collaborator | Day one |
| Hosting | Project moved to the founder’s team | Day one |
| Domain | Already in the founder’s registrar account | Day one |
| Provider accounts | Failed: the email provider account was still in the contractor’s name. Ownership moved, contractor removed | Failed day one, passed day two |
| Credentials | Stripe, Supabase and email keys rotated; old Stripe key failing after its expiry | Rotated day five, checked after expiry |
| Environments | Production and staging listed, each with its database and Stripe mode | Day two |
| Deploy | Copy change shipped from a fresh clone through the founder’s pipeline | Day two |
| Local setup | Founder’s new developer ran the app from the setup guide | Day two |
| Data and backup | Failed: no backup had ever been restored. Export restored into a copy and checked | Failed day two, passed day three |
| README | Repository map added | Day three |
| Runbooks | Deploy and rollback runbooks followed by the founder’s developer | Day three |
| Diagram | Matches the inventory | Day three |
| Report and pack | Two failures accepted in writing, the rest fixed | Day three |
| Review meeting | Held, notes filed | Day four |
| Acceptance check | Flows run, one deploy and one rollback by the founder’s developer | Day four |
| Session | Recorded, file in the founder’s storage | Day three |
| Defect window | Written | Day four |
| Question window | Written | Day four |
| Channel | Shared channel, test message answered | Day four |
| Dates | Start and end dates on both windows | Day four |
Two rows failed on the first pass and were fixed before anyone signed. The backup row depends on the Supabase plan: Supabase backs up all Pro, Team and Enterprise Plan projects daily, and recommends that free tier plan projects export their data regularly with the Supabase CLI db dump command and keep off-site backups. On the Free plan, the restored backup in this example is that export, restored into a separate copy of the database. The credentials row comes last on purpose: the contractor’s keys stop working only after everything else is in the founder’s hands.
Source code escrow: what a software escrow agreement is, what it costs, and when a client asks for one
Source code escrow is a third party holding a copy of the code under a three-party agreement that releases it to the client on agreed conditions, such as the vendor’s bankruptcy or discontinued support. In my reading, enterprise clients of agencies ask for it, and a client who owns the repository outright rarely needs it.
Codekeeper describes software escrow as “a three-party agreement between vendors, users, and Codekeeper”, in which vendors deposit source code, data and documentation, and the material is released to users under specific failure conditions: “vendor bankruptcy, discontinued support, or contract breaches”. Software escrow companies include Codekeeper, Escode and The Escrow Company (formerly Escrow London); I name them as examples, not as a ranking.
| Question | Answer |
|---|---|
| What is it? | A neutral agent keeps the vendor’s deposit and hands it to the user only when one of the agreement’s release events happens. |
| Who asks for it? | In my reading: an enterprise client buying a build from an agency, or a licensee of software whose code it does not hold. |
| What does it cost? | One published example, Codekeeper: Software Escrow from $139/mo (protection scope: on-prem software); SaaS Escrow from $199/mo (protection scope: SaaS applications). Monthly billing, or up to 12% saved on annual plans. By my reading, a web app falls under the SaaS plan’s scope. |
| When should a small client not bother? | In my reading: when it owns the repository outright, which is item 1 of the checklist above. |
For software escrow cost, those figures come from Codekeeper’s published escrow pricing, which lists further plans for backup, AI systems, continuity and custom setups; prices checked 2026-10-04. Escrow keeps a copy of the code safe; who keeps the app running after support ends is a question for application maintenance service providers.
How to verify the result
A software handover is verified in one pass: the receiver removes the builder from every account and repository, deploys a visible change from a fresh clone, runs the core flows, and both sides sign the document that day. The signed document with its dated test results is the record.
- 01 Remove the builder from every account and repository. Evidence: the member list of each one, with the builder gone.
- 02 Deploy a visible change from a fresh clone. Evidence: the change live on the site and the deploy log.
- 03 Run the core flows. Evidence: the test record with each flow passed.
- 04 Sign the document, both sides, with the date. Evidence: the signed document.
On GitHub, the first check includes the repository’s collaborator list, because the original owner is added there by the transfer.
Where the sprint does this
In the Production Hardening Sprint, the handover deliverables land in the documents, acceptance and support groups of this list; that mapping is mine. Item 11 is deliverable 13.3, operating runbooks: we document deployment, rollback, key rotation, backup restoration, and the response to each operational alert. For item 16, deliverable 13.4 is to conduct and record a 60-minute walkthrough with the client team and technical advisors. Item 17 matches deliverable 13.5, fourteen calendar days after handover to fix defects in the sprint deliverables. Item 18 matches deliverable 13.7, thirty calendar days after handover for questions about the delivered architecture, operation, and safe future changes. At handover the client receives the updated codebase, tests, and deployment configuration; a readiness report and technical due diligence pack; instructions for releases, backups, recovery, and incident response; guidance and automated checks for future AI-assisted changes; and a recorded 60-minute handover and a 20 to 30-minute codebase tour. Each deliverable and its check are listed in the published scope of the sprint.
Common questions about software handovers
What is a handover sheet?
A handover sheet is one page that holds the asset table and the checklist, dated and signed by both sides. It suits a small job; a larger handover uses the full six-part document.
What is the correct format for a handover in Excel?
Six sheets, one per part of the handover document, or six sections on one sheet if the project is small. The format is the table, so the columns matter more than the file: item, who checks, test, result, date.
What is the format for a handover form?
A handover form uses the same six parts as the handover document, left empty, with a signature line for each side at the bottom. Filled in and signed, the form becomes the document.
How to write a handover report example?
Write it as the handover document after the tests: one line per checklist item with its result and the date. An entry that names the domain, says it sits in the receiver’s registrar account with the renewal card changed, and gives the date checked is complete; an entry that only says done is not.
Is there a free escrow service available?
Not from Codekeeper, the provider whose prices are shown above: its pricing page lists paid plans and no free plan (checked 2026-10-04). For a small client, the free route in my reading is owning the repository outright, which removes most of the reason for escrow.
What are common UAT mistakes?
My working list has three: testing on the builder’s machine instead of the receiver’s setup, testing only the happy paths, and running flows with no written expected results. Each one lets a handover pass that the receiver cannot repeat on their own.
Owning an app means being able to run it, change it and recover it without guessing. The sprint below leaves you with the runbooks and documentation to do that.
Built it with AI. Now it has to hold up for real customers.
The Production Hardening Sprint takes the app you already have and builds the production foundation underneath it. Authentication and access rules, payments that stay consistent, error handling, monitoring, backups, automated tests and a documented handover. Our engineers work inside your existing codebase for ten working days. All 123 deliverables are included, and you get the evidence for each one.
See the Production Hardening Sprint → 
$2,500 fixed price · 10 working days · One codebase