Launch is the start of an application’s operating life. A useful handover makes it clear who runs the service, how routine tasks are performed, where questions go, and what happens when the application changes. Agree these responsibilities before the project team moves on.
Name the people who own the application
Identify the business owner who sets priorities and the technical owner who manages the operating environment. Record who administers user access, renews subscriptions, handles support requests, and approves changes. One person may hold several responsibilities, but none should depend on an unstated assumption.
Confirm which accounts the business controls and how an authorized replacement person would obtain access. Keep credentials in the agreed secure system, not in the handover document. The document should explain where access is managed and who can approve it. Use the roles and permissions guide to review administrative access as well as ordinary users.
Hand over a usable operating record
Include the application purpose, current release, important connections, known limitations, and the location of source files and documentation where included in the agreement. Separate everyday user instructions from technical operating procedures so each audience can find the information it needs.
| Handover item | What it should establish |
|---|---|
| Account inventory | Ownership, administrator, and renewal responsibility |
| Operating instructions | Routine tasks, prerequisites, and expected results |
| Release record | What was accepted and which limitations remain |
| Support contacts | Who receives requests and when to escalate |
| Recovery documentation | Applicable approach, authorized owner, and verification record |
Ask the receiving person to use the instructions for an agreed task. A folder full of documents is not proof that the handover is understandable. Record gaps and assign them to an owner.
Agree the maintenance and support arrangement
List routine work such as application updates, dependency reviews, access reviews, and checks of relevant connections. Identify the person receiving operational alerts and what they are expected to do. Clarify any backup and recovery responsibilities for the chosen environment; an application being hosted does not by itself explain its recovery arrangement.
Microsoft’s guidance on standardizing operations recommends actionable procedures and documentation that remains current. Adapt the procedure to the actual application, including testing an update and recording the result, rather than copying steps from a different platform.
Distinguish a defect report from a request for new functionality. Agree support availability, response expectations, exclusions, and any separate charges with the provider. Include recurring commitments in the application budget so ongoing operation has an explicit owner and resources.
Plan changes and the next review
Keep the accepted release and its user acceptance results available. When a change is proposed, describe the user need, affected workflow, and checks required before release. Use the deployment checklist to carry approval, recovery, and live verification into subsequent updates.
Schedule an initial review based on the application’s use and the agreed support arrangement. Ask which tasks are confusing, which issues remain open, and whether the operating instructions match reality. Record decisions rather than allowing follow-up to become an untracked stream of messages.
Also discuss how a future provider transition would work: what assets and data can be handed over, who authorizes access changes, and what dependencies remain. Treat the handover record as something the business maintains throughout the application’s life, not as a document that is filed away after launch.
For help planning the build and its operating handover, discuss application design and deployment with Your Expert Tech. Bring the workflow, current arrangements, and responsibilities you need to clarify.