Post Launch Support
Launch is the start of a system's working life, not the end of the project. Post-launch support covers the weeks of close attention after release, then the longer-term routine of fixes, updates and improvement, with responsibilities and service levels agreed in your contract.
Start your project
The first weeks after release
Real users and real data expose problems that testing did not. A short hypercare period, planned before launch, puts engineers on close watch: monitoring dashboards, a fast route for reports, and daily review of errors and feedback. The aim is to stabilise quickly and learn what the first users actually do.
The length and staffing of hypercare depend on the system's criticality and are agreed before go-live, not improvised.
What support can include
- Defect fixing for faults against the agreed specification.
- Monitoring of availability, errors and performance, with alerts to named people.
- Security patching and dependency updates on a regular schedule.
- Backup verification and recovery rehearsal.
- Small enhancements and configuration changes from a prioritised queue.
- Advice and user questions routed through a single channel.
- Periodic review of incidents, trends and recommended improvements.
How a request flows
Report
Users or monitoring raise a ticket with description, evidence and affected users.
Classify
Severity is set using the definitions agreed in the contract, based on business impact.
Respond and fix
The queue acknowledges, investigates and restores service, with updates to the reporter.
Release
Fixes are tested and deployed through the normal release process, or as an emergency change if justified.
Review
Repeated or serious issues receive a cause analysis and preventive action.
Share the outcome you need and Renvric will recommend the smallest useful next step.
Responsibility split
Your team
Triage business questions, report issues with detail, approve changes, and provide first-line support to users if agreed.
Renvric
Investigate and resolve faults within scope, monitor, patch, report and recommend.
Both
Define severity, maintenance windows, release approvals and what counts as defect versus enhancement.
Defect or enhancement
Most arguments in support arise from this distinction. A defect is behaviour that differs from the agreed specification or acceptance criteria; an enhancement is a new wish. Defects within a warranty or support period are corrected under the agreement. Enhancements are estimated and prioritised like any other work.
For example, a booking tool that fails to send confirmation emails is a defect. A request to add a reminder text message is an enhancement.
Service levels and cost
Related areas to explore: Compare Engagement Models, Software Maintenance and Support and Large language models.
- Response and resolution targets are set per severity in your contract, not published as standard figures.
- Cover hours may be business hours or extended, with out-of-hours support priced separately.
- Support may be a fixed monthly fee, a pool of hours, or both.
- Unused capacity and rollover are stated in writing.
- Review points allow cover to be raised or lowered as the system matures.
Common questions
Who needs post-launch support?
Any organisation with a live system that users or customers depend on. Even a well-tested release needs monitoring, patching and a route for fixes. The scope can range from a short stabilisation period to continuing managed support, depending on how critical the system is.
What do you need from us to set it up?
Details of who will raise issues, how users are supported, your business hours and criticality of functions, the approval route for emergency changes, and access to environments. These are normally agreed in the weeks before launch.
What happens in the first weeks after go-live?
A hypercare period applies: engineers watch monitoring and error reports closely, issues are triaged daily and fixes released quickly through a tested process. Findings are reviewed with you, and the arrangement then moves into the longer-term support rhythm.
Are bug fixes included or charged?
It depends on the contract. Faults against the agreed specification are typically covered during a defined warranty or support period, while new features are estimated separately. Your agreement should state the period, the definition of a defect and how disputed cases are decided.
What if we want to support the system ourselves?
That is a legitimate choice. Knowledge transfer, documentation and runbooks are provided so your team can take over. Many clients keep a lighter arrangement for escalation or specialist help, which can be agreed as a retainer or as needed.
Other ways to work together
Agree who can raise tickets, how users will find help, what monitoring will alert on, and who approves emergency changes. Make sure documentation and runbooks are ready. A short rehearsal of an incident before go-live often exposes gaps in contact lists and access.