A software launch changes the type of work; it does not end it. Responsibility moves from building features to operating a live service, responding to incidents and managing controlled change. A support handover makes that transition explicit so the business knows who owns the system, how problems are handled and which knowledge and access have been transferred.
The handover should be planned before launch. Waiting until the development team is leaving creates avoidable dependence on individual memory.
Define the support operating model
Identify the organisations and roles involved in:
- receiving user reports;
- triaging incidents and requests;
- investigating application and infrastructure issues;
- contacting third-party providers;
- approving emergency changes;
- communicating with affected users;
- maintaining the backlog and release plan.
A named support email address is not an operating model. Define responsibility, availability, escalation and decision authority.
Separate defects, incidents, requests and changes
Users may describe every problem as “the system is broken”. The support process should classify the report:
| Type | Meaning | Typical route |
|---|---|---|
| Incident | An unexpected interruption or degradation of the live service. | Assess impact, restore service and investigate cause. |
| Defect | The application does not behave as agreed. | Confirm, prioritise, correct and retest. |
| Service request | A routine request such as access, configuration or guidance. | Follow the approved operating procedure. |
| Enhancement | A proposed new or changed capability. | Assess value, scope and delivery priority. |
| Training or process issue | The system works, but the user or operating process is unclear. | Improve guidance, training or process ownership. |
This prevents every request from entering an urgent development queue.
Transfer access and control
Create an inventory of the accounts and assets needed to operate the service. Depending on the system, this may include:
- source-code repositories;
- cloud and hosting accounts;
- deployment pipelines;
- domain and DNS control;
- databases, storage and backup systems;
- monitoring and alerting services;
- email, SMS, payment and other integration accounts;
- administrative application roles;
- licence and billing access.
Confirm the agreed ownership model and test access with the receiving team. Do not place credentials in a general handover document; transfer them through an approved secure method.
Provide documentation that supports action
Useful support documentation helps someone diagnose and recover a service, not merely understand the project history. It should include:
- a system overview and dependency map;
- environment and deployment instructions;
- configuration and integration inventory;
- monitoring dashboards and alert routes;
- backup and recovery procedures;
- common incident runbooks;
- data import, export and reconciliation procedures;
- administrative tasks and permission management;
- known limitations and technical debt;
- support contacts and escalation.
Assign an owner and review date. Documentation becomes unreliable when no one is responsible for keeping it current.
Handover knowledge through supervised work
A presentation alone is not enough. The receiving team should perform representative tasks while the delivery team observes. Examples include deploying a safe change, restoring a test backup, tracing a failed integration and adding an administrative user.
Record questions and update the documentation. The purpose is to prove that the knowledge can be used, not that it was presented.
Confirm monitoring and alert ownership
List the services and business processes that are monitored, the alert thresholds and the response owner. Check that alerts reach a channel someone actually watches during the stated support period.
Include:
- application availability and critical journeys;
- failed background jobs and growing queues;
- integration failures;
- backup completion and restoration evidence;
- capacity or performance conditions important to the business;
- certificate, domain or service expiries where relevant.
Test the route by generating controlled alerts before handover.
Prepare the initial support backlog
The live service will usually begin with known defects, deferred improvements and operational tasks. Create one controlled backlog showing:
- the item and its impact;
- whether it is a defect, enhancement, risk or maintenance task;
- the agreed priority;
- the owner;
- the target review or delivery point;
- any temporary workaround.
Do not allow items accepted conditionally at sign-off to disappear into an unowned list.
Define the early-life support period
The first days after launch often need closer observation because real usage reveals issues that controlled testing did not. Define:
- the period of enhanced monitoring;
- the people available to investigate;
- the daily review of incidents, data and feedback;
- the threshold for pausing or rolling back a release;
- the communication route for users and managers;
- the point at which normal support arrangements begin.
Keep the process proportionate. A small internal tool may need a short, focused review; a business-critical migration may need a more formal command structure.
Agree service levels and commercial boundaries
Document the support hours, response targets, included activities, exclusions and change process. Clarify the difference between correcting an agreed defect and delivering a new requirement. Terms such as warranty, defect-liability period or service level can have contractual consequences, so confirm the applicable wording in the actual agreement and obtain advice where necessary.
Verify backup, recovery and supplier exit
The handover should demonstrate that the receiving organisation can access backups, understand the recovery process and obtain a usable export of important data. Record third-party dependencies and the steps required if a provider or development supplier changes.
Access to source code alone is not a complete exit plan. The business may also need infrastructure configuration, database knowledge, service accounts, licences and deployment instructions.
Use a handover acceptance checklist
| Area | Evidence |
|---|---|
| Responsibilities | Named owners, support hours and escalation route. |
| Access | Receiving team has tested the agreed accounts and administrative controls. |
| Documentation | Current operational, deployment, recovery and integration guidance. |
| Monitoring | Dashboards and alerts are active, tested and routed. |
| Recovery | Backup access and restoration evidence are available. |
| Backlog | Known issues and deferred work have owners and priorities. |
| Knowledge | Receiving team has completed supervised operating tasks. |
| Commercial support | Scope, response arrangements and change route are understood. |
Questions to put to a supplier
- Which tasks still depend on a named individual rather than documented knowledge?
- Which accounts or services remain under supplier control, and why?
- Can the receiving team deploy, diagnose and restore the service?
- Which alerts are active, and who responds to each one?
- How are known defects and post-launch changes separated?
- Which third-party contracts, licences and renewal dates affect operation?
- What is the tested route for transferring support to another provider?
Practical next step
Ask the future support owner to perform three supervised tasks before launch: trace a failed transaction, access the current backup and deploy or reverse a safe change. Any step that depends on undocumented supplier knowledge should become a handover action before project closure.