How to prepare a custom software project handover
After custom software is live, the handover names who takes each responsibility, where the repository and access live, who receives the documents and the operating runbook, what training was recorded, where residual defects are listed, and how a fix inside the warranty stays separate from a change request. The cutover runbook is the sequence for the night of go-live. The handover is who holds the system afterwards, and who is called when it fails.
On this page
- Keep the handover separate from the cutover
- Name who holds each responsibility after go-live
- Name the account manager on the handover
- Keep administrator documentation apart from the daily runbook
- Record who attended training, and what was taught
- List residual defects on their own sheet
- Separate a warranty fix from a change request
- Until the sheet is complete, the cover still names the original owner
Keep the handover separate from the cutover
The cutover runbook says what stops first that night, who signs the go or no-go, and what sends the service back to the old environment. The handover says, once users are on production, who takes the daily calls, where the code sits, where the documents sit, and who follows defects that are still open. The two documents can point at each other by version. Do not rewrite the cutover steps as the handover list. The sequence for that night is in How to cut custom software over to production.
Acceptance criteria say what counts as done. User acceptance says who produced each result on the list. The handover does not repeat either document. The cover carries the specification version, the date production was opened, and the version of the handover itself. If scope still has to change before handover, open a change request. Do not write a new screen into the residual-defect list during the handover meeting. How a change is recorded is in How to control scope changes in custom software. Delivery stays with Custom software, websites, and applications.
Name who holds each responsibility after go-live
The handover names four roles: the system owner, the first person who takes an incident, the person who may change production, and the contact used when calling the supplier. One person may hold two roles. The columns stay separate. A line that only says "the project team" or "IT" does not tell the next incident whom to call. If the named person will be away, the deputy is already on the sheet. The group chat does not pick a replacement on the day.
The system owner is responsible for daily running after go-live, not for the signature on the night of the cutover. The same person may be both. The two columns are still filled, with the date each one takes effect. The supplier contact is a name, a channel, and the hours they can be reached. An arrival time written in the contract stays in the contract. It is not copied onto this sheet, and it is not rewritten as a status.
Name the account manager on the handover
Read on 21 October 2026, the catalog page for NIST SP 800-53 Rev. 5 gives the publication date as September 2020, including updates as of 10 December 2020. The control text below is from that publication, DOI 10.6028/NIST.SP.800-53r5. AC-2, Account Management, says to define and document the types of accounts allowed and specifically prohibited; to assign account managers; to specify authorized users, group and role membership, and access authorizations (privileges) for each account; to require approval before an account is created; and to create, enable, modify, disable, and remove accounts under the organization's own rules. The time allowed for notification is an organization-defined assignment. The control states no number of hours.
The handover therefore names which accounts production allows, whether shared accounts are prohibited or allowed, who the account manager is, and who approves a new account. Where a group account is still used, AC-2 also requires a process for changing the shared or group authenticator when someone leaves the group. On the day of handover, people who have left the project are removed from the list, with the date the account was disabled. The secret itself is not written on the handover. The sheet names the store that holds it, and who may open that store.
Keep administrator documentation apart from the daily runbook
SA-5, System Documentation, says to obtain or develop administrator documentation that describes secure configuration, installation, and operation of the system, component, or service; effective use and maintenance of security and privacy functions; and known vulnerabilities regarding configuration and use of administrative or privileged functions. The same control says user documentation describes the user-accessible security and privacy functions, methods of interaction that let people use the system more securely and protect privacy, and user responsibilities for security and privacy. Documentation is distributed to organization-defined personnel or roles. When documentation cannot be obtained, the attempt is recorded and organization-defined actions are taken. The discussion says secure operation includes initially starting the system and resuming secure operation after a lapse.
The daily runbook is the project's own document: who runs which job, which page to open when it fails, how production is started, and how the business is resumed after an interruption. It sits on a different line from the SA-5 security documentation. Both lines carry a path, a version, and a date. The path names the folder and the file. "In the chat" is not a path the next person on duty can open. The discussion names system owners, system security officers, and system administrators among the roles that need documentation. The distribution list matches those roles, and adds the person on duty for the daily runbook.
Record who attended training, and what was taught
The business-training record is the project's own page: the date, the names present, which procedures were taught, and who signed. A page with no signature is not a record that the teaching happened. The version of the material is on the same page, so a later reader can see which screens were shown. Someone who was absent is booked for the same material. Absence is not marked complete on the handover.
AT-3, Role-Based Training, says to provide role-based security and privacy training to organization-defined roles before authorizing access to the system or information, or before they perform assigned duties, and when system changes require it. Content is updated at an organization-defined frequency and after organization-defined events, and lessons from internal or external security incidents are incorporated. AT-4, Training Records, says to document and monitor those security and privacy training activities. How long individual records are kept is organization-defined. The discussion says records of specialized training may be kept by individual supervisors. The sign-in sheet for business training does not stand in for the AT-4 record, and the AT-4 record does not stand in for "this person has seen the production screens". Both pages are kept, each on its own line of the handover.
List residual defects on their own sheet
Each defect still open after go-live has one line: what happens, which screen or record shows it, who found it, the date, whether users can keep working, and who owns the fix. A line with no owner stays on the sheet, and the cover says that an unassigned item remains. Defects already closed in acceptance are not copied back in to fill the page.
Severity uses the words the team already uses. The handover meeting does not invent a second scale. Where users can keep working, the line says what they do in the meantime, and which page of the runbook states that workaround. A workaround that was never written into the runbook will only be repeated in chat. A sentence that lives only in chat is not entered in the workaround column.
Separate a warranty fix from a change request
The start and end of the warranty are the dates in the contract. The handover records those two dates and the contract number. A count of days, an arrival time, and a price stay in the contract. An item already on the residual list, where the behaviour departs from the result that was agreed, is followed as a fix during the warranty. A wish that was never in the specification is a change request. It is not written onto the residual list as if it were an unfinished defect.
CM-3, Configuration Change Control, says to determine and document which types of change are configuration-controlled; to review them and approve or disapprove, with explicit consideration of security and privacy impact; to document the decision; to implement approved changes; and to retain the records for an organization-defined period. A warranty fix that changes the system, where that type of change is configuration-controlled, still follows this record. The word warranty in the contract does not skip the approval. The residual list says what is to be repaired. The change record says who approved the change. The two sheets point at each other with the same defect number.
Until the sheet is complete, the cover still names the original owner
If the system owner, the account manager, a document path, the residual list, or the line that separates warranty fixes from change requests is still blank, the contact on the cover remains the person responsible during implementation, and the handover date stays blank. The blank column is named. The date is filled when that column is filled. With no deputy named, the last person to speak in the chat is not written down as the new owner.
Time limits, defect counts, and support hours stay in the company's own rules and in the contract, with a date. The periods in AC-2, AT-4, and CM-3 are organization-defined. None of them assigns a number of days to a custom project. Before the handover is treated as given, three things are visible: every role has a name, the documents and the repository have a path, and every residual defect has an owner or is marked unassigned. The handover date goes into the notice when those three are on the sheet.