What this resource covers
Software needs operational ownership after launch. Maintenance addresses defects, dependencies, security updates, changing integrations, environments, performance, backups, and approved improvements throughout the supported life.
- Define included systems, environments, hours, channels, responsibilities, and exclusions
- Classify incidents by impact and urgency using agreed definitions
- Set response and communication expectations without confusing them with guaranteed resolution times
- Monitor application health, jobs, integrations, storage, and provider dependencies where applicable
- Plan backup checks, recovery exercises, dependency updates, and supported versions
- Maintain an enhancement backlog separate from incidents
- Record recurring problems and preventive improvements
Information to prepare
Prepare system inventory, owners, service hours, users, dependencies, monitoring, backup and recovery, incident history, release cadence, security obligations, vendor contracts, and knowledge gaps.
- Deployed system inventory and architecture
- Support responsibilities and contact channels
- Business-critical workflows and impact definitions
- Monitoring, backup, recovery, and vendor arrangements
- Warranty, maintenance, and enhancement agreements
Expected planning outputs
Define support channels, severity and response targets, escalation, monitoring, maintenance windows, patching, backup checks, knowledge ownership, change handling, reporting, and improvement review.
- Support and escalation model
- Severity definitions and communication process
- Maintenance calendar
- Incident and problem records
- Prioritized enhancement backlog
Practical example
How it can be applied
A fleet platform support model may classify complete booking outage as critical, a report formatting issue as lower severity, and a new dashboard request as an enhancement. Each follows a different review, communication, and planning path.
Common mistakes to avoid
- Calling every request an urgent defect
- Promising resolution times before diagnosing the issue
- Ignoring dependency and certificate expiry
- Keeping no record of production configuration or recurring incidents
- Mixing unlimited enhancements into corrective maintenance
FAQ
Common questions
What is the difference between an incident and an enhancement?
An incident is an interruption or failure against expected operation. An enhancement adds or changes capability and normally requires prioritization and estimation.
Does response time equal resolution time?
No. Response acknowledges and begins handling. Resolution depends on diagnosis, impact, dependencies, data, testing, and release requirements.
When should maintenance planning begin?
Before deployment, because monitoring, backups, access, support ownership, and recovery cannot be added reliably at the last moment.