Before a new system becomes part of daily operations, the business needs to know who will run it and how problems will be handled. Feature demonstrations alone do not establish that the application can be maintained, supported or recovered after an incident.
A launch review should bring together the business owner, the delivery team and the people responsible for operation and support. The evidence required should reflect the importance of the system and the consequences of a failure.
Agree on the conditions for launch
Define the essential business activities the system must support. Record how those activities have been checked, which issues remain and who can accept any outstanding limitations.
A useful launch review includes:
- Evidence that the agreed business processes work, including relevant exception cases
- Access permissions for users, administrators and support staff
- Checks against expected usage and performance requirements
- The release plan, monitoring and recovery procedures
- Named owners for support and the decision to proceed
Set dates and owners for work deferred until after launch. Make sure an unresolved issue is not simply lost when the project moves into operation.
Assign operational responsibilities
Record who owns the application, data, infrastructure and business process. These responsibilities may be split between internal teams and suppliers.
The team should know who can approve and release a change, who receives alerts and how a reported issue is escalated. Agree on support hours and response targets rather than assuming someone will always be available.
Confirm that the people taking responsibility have the required access and documentation. Include the arrangements for transferring or removing access when responsibilities change.
Review deployment and recovery together
Document how the application is released, how configuration is managed and which checks take place before and after a release. Use appropriate secret-management tools for credentials rather than including them in source files or public build outputs.
Agree on what the team will do if the release fails. Reverting application code may not reverse changes already made to business data. A database change may also make an older application version incompatible with the updated database.
Ask the technical team to explain the recovery options for the actual release. Where reversal is unsuitable, the plan may require a corrective update or a documented data-recovery procedure.
Set recovery targets from business needs
Two measures help turn recovery expectations into requirements:
- Recovery time objective (RTO): the maximum acceptable time between a service interruption and restoration.
- Recovery point objective (RPO): the maximum acceptable gap between the interruption and the data recovery point, expressing how much recent data loss the business can tolerate.
AWS’s guidance on recovery objectives explains how these targets should reflect business impact. More demanding targets can require additional cost and complexity. They are objectives that need supporting design and evidence, not automatic guarantees.
Check the dependencies as well. An application recovery plan may depend on another service, access to credentials or a supplier whose recovery arrangements differ from your requirements.
Demonstrate that backups can be restored
A successful backup job does not establish that the application can be recovered. Restore the required data in a suitable environment, confirm that it is usable and measure how long the process takes.
AWS’s backup recovery guidance recommends recovery tests that check data integrity and whether the recovery objectives can be met.
For a complete service recovery, also account for configuration, application versions and external dependencies. Document the steps and the access required to carry them out.
Monitor business operations as well as servers
An application can be available while an important function is failing. Choose monitoring that reflects the operations users depend on, such as submitting a request or completing a background job.
Agree on which errors and delays require action. Send alerts to the responsible team with enough context to investigate, and explain how users should report problems that monitoring does not detect.
Complete the handover
Provide an operating guide covering releases, configuration, access, monitoring, recovery and common support tasks. Walk through it with the team that will use it and resolve missing information before responsibilities transfer.
At the end of the launch review, record the decision, any accepted limitations and the owners of follow-up work. This gives the business a clear account of what is ready and what still needs attention.
AgentixBrain’s Cloud & Platform Engineering service covers cloud environments, deployment automation and observability. Our delivery approach includes technical enablement through documentation, knowledge transfer and practical training.
