# Software Maintenance Plan: [System or product name]

> Software Maintenance Plan describing how a software product will be
> kept useful after delivery: the maintenance concept, types of
> maintenance, organisation, process from request to release, resources,
> metrics and service levels, configuration management, transition from
> development, budget and eventual retirement. The structure is aligned
> with the maintenance process of ISO/IEC/IEEE 14764:2022 (process
> implementation, problem and modification analysis, modification
> implementation, maintenance review and acceptance, migration and
> retirement). Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Prepare the plan before transition from development, ideally with the
  team that will do the maintenance. Maintenance usually costs more over
  the life of a product than development did.
- Fill section 2 (maintenance concept) first: scope, who maintains, how
  long and to what level. Everything else follows from it.
- Make service levels and metrics measurable from your tracker and
  monitoring. Agree them with the product owner and users.
- Plan retirement from the start. Products without an end-of-life plan
  tend to linger, unpatched, long after anyone owns them.
-->

## Document control

<!-- Guidance: Identify the plan, the product and versions in scope, and the approvers from the maintainer, the product owner and operations. -->

| Field | Value |
|---|---|
| Document ID | [SMP-PRODUCT-001] |
| Product / system | [Name], versions [2.x] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@maintenance-manager] |
| Maintainer organisation | [Team or contractor] |
| Effective period | YYYY-MM-DD to YYYY-MM-DD |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
| Related | [Software transition plan], [SCM plan], [SLA], [Architecture description], [Retirement plan] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Maintenance manager | [@name] | [Approved] | YYYY-MM-DD |
| Product owner | [@name] | [Approved] | YYYY-MM-DD |
| Operations / service owner | [@name] | [Approved] | YYYY-MM-DD |
| Acquirer or budget holder | [@name] | [Approved] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Review the plan at least yearly and after major changes such as a new maintainer, platform migration or change of service levels. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft during transition |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at transition acceptance |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* SLA for priority 2 changed from 5 to 3 working days |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Introduction](#1-introduction)
2. [Maintenance concept](#2-maintenance-concept)
3. [Maintenance types](#3-maintenance-types)
4. [Organisation and responsibilities](#4-organisation-and-responsibilities)
5. [Maintenance process](#5-maintenance-process)
6. [Resources](#6-resources)
7. [Metrics and service levels](#7-metrics-and-service-levels)
8. [Configuration management](#8-configuration-management)
9. [Tools and environments](#9-tools-and-environments)
10. [Training and knowledge management](#10-training-and-knowledge-management)
11. [Transition from development](#11-transition-from-development)
12. [Budget](#12-budget)
13. [Retirement plan](#13-retirement-plan)
14. [Risks](#14-risks)
15. [Appendices](#15-appendices)
16. [Standard and licence note](#standard-and-licence-note)

## 1. Introduction

<!-- Guidance: State the purpose of the plan, the product and versions covered, and the documents it relies on. -->

### 1.1 Purpose

This plan defines how [Product] will be maintained from [date] to [date or
"retirement"]: who does the work, how requests are handled, what service
levels apply, what it costs and how the product will eventually be
retired.

### 1.2 Product overview

[Product] [purpose in two sentences]. It is used by [users, number] at
[sites] and depends on [key platforms and external systems].

*Example:* A web-based crew planning system used by 420 dispatchers in
nine centres. It runs on the acquirer's private cloud and exchanges data
with the national incident system through a message gateway.

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Server, web client and gateway, versions 2.x | *Example:* Hosting platform (operated by infrastructure team) |
| *Example:* Database schema and reference data | *Example:* National incident system (other contractor) |
| *Example:* User and support documentation | *Example:* New major features (funded as projects) |

### 1.4 References

| Document | Version | Use in this plan |
|---|---|---|
| *Example:* Software transition plan STrP-01 | 1.0 | Inputs for sections 6 and 11 |
| *Example:* Service level agreement SLA-07 | 2.0 | Targets in section 7 |
| ISO/IEC/IEEE 14764:2022 | 2022 | Process structure (cited, not reproduced) |
| [Document] | [Version] | [Use] |

## 2. Maintenance concept

<!-- Guidance: The maintenance concept sets the scope of maintenance, who performs it, the level of support and how long support lasts. Agree it before writing the rest. -->

| Element | Decision |
|---|---|
| Scope of maintenance | *Example:* All four maintenance types in section 3, for the items in 1.3 |
| Maintainer | *Example:* Internal platform applications team (6 FTE) |
| Support levels | *Example:* Level 1 service desk, level 2 application support, level 3 maintenance team, level 4 vendors |
| Support hours | *Example:* Business hours 08:00-18:00 for changes; 24x7 on-call for priority 1 incidents |
| Release cadence | *Example:* Monthly maintenance release; emergency fixes as needed |
| Supported versions | *Example:* Current minor version and the previous one; security fixes only for the previous one |
| Planned life | *Example:* Until replacement by the national system, expected YYYY |
| Funding model | *Example:* Fixed annual maintenance budget plus change requests above 10 days funded separately |

## 3. Maintenance types

<!-- Guidance: Define the categories used to classify every request, in your own words, with examples. Consistent classification makes metrics and budgets meaningful. -->

Every request is classified into one of the following types. Corrective
work is reactive; the other three types are planned.

| Type | Meaning in this plan | Example | Budget share target |
|---|---|---|---|
| Corrective | Fixing faults that users or monitoring have found in the delivered software | Shift report omits crews on leave | [30%] |
| Preventive | Finding and removing latent faults or weaknesses before they cause failures | Upgrading a library approaching end of support; fixing a race condition found in code review | [20%] |
| Adaptive | Keeping the software working in a changed environment | New browser version, operating system upgrade, new interface schema from a partner | [25%] |
| Perfective | Improving performance, maintainability, usability or other attributes, or small enhancements requested by users | Faster search, clearer error messages, a new report filter | [25%] |

The current edition of ISO/IEC/IEEE 14764 may define further categories or
sub-categories (for example for emergency changes); check the standard if
you need to align classification exactly. Requests that exceed [10 person
days] are treated as projects, not maintenance.

## 4. Organisation and responsibilities

<!-- Guidance: Name roles, their responsibilities and their decision rights. Show how the maintainer works with operations, the product owner and vendors. -->

| Role | Name / team | Responsibilities |
|---|---|---|
| Maintenance manager | [@name] | Owns this plan, budget, priorities with product owner, reporting |
| Product owner | [@name] | Approves perfective and adaptive changes, sets priorities |
| Change advisory / control board | [Members] | Approves modifications and releases; meets weekly |
| Maintenance engineers | [Team] | Analysis, implementation, testing, documentation |
| Test lead | [@name] | Regression suite, acceptance testing |
| Configuration manager | [@name] | Baselines, releases, status accounting |
| Service desk | [Team] | Logs requests, first-line triage |
| Operations | [Team] | Deploys releases, monitors production |
| Vendors | [Vendor names] | Support for commercial components under contract |

The RACI below shows responsibilities per process activity (R =
responsible, A = accountable, C = consulted, I = informed).

| Activity | Maintenance manager | Product owner | Engineers | CCB | Operations |
|---|---|---|---|---|---|
| Request analysis | A | C | R | I | C |
| Approve modification | C | R | I | A | I |
| Implement and test | A | I | R | I | C |
| Acceptance | C | A | C | R | C |
| Release to production | A | I | C | C | R |

## 5. Maintenance process

<!-- Guidance: Describe each process activity: inputs, steps, outputs and records. Keep the process light enough to be followed for small fixes and rigorous enough for risky changes. -->

The lifecycle of a request is shown below.

```mermaid
stateDiagram-v2
  [*] --> Logged
  Logged --> Analysed: triage
  Analysed --> Rejected: not justified
  Analysed --> Approved: CCB or product owner
  Approved --> InProgress
  InProgress --> InReview: code and test complete
  InReview --> Accepted: acceptance passed
  InReview --> InProgress: rework
  Accepted --> Released
  Released --> Closed
  Rejected --> Closed
  Closed --> [*]
```

### 5.1 Process implementation

The maintainer sets up the procedures, tools and records needed before
taking over: request intake in [tracker], classification rules (section
3), priority scheme (section 7.3), CCB terms of reference and the link to
configuration management (section 8).

### 5.2 Problem and modification analysis

| Step | Description | Output |
|---|---|---|
| Log | *Example:* Service desk records the request with reporter, product version, symptoms, impact | Request MR-NNNN |
| Triage | *Example:* Engineer confirms or reproduces, classifies type and priority within the response time | Classified request |
| Analyse | *Example:* Identify affected items, options, effort, risk, impact on interfaces and documents | Impact analysis |
| Decide | *Example:* Priority 1 and 2 decided by maintenance manager; others by CCB or product owner | Approved or rejected |

### 5.3 Modification implementation

Approved modifications are implemented on a branch, with code review,
unit and regression tests, documentation updates and an updated
traceability record. Design changes that affect architecture are
recorded as decision records.

### 5.4 Maintenance review and acceptance

Before release, the test lead confirms the regression suite passes and the
requester or product owner accepts the change against its acceptance
criteria. The CCB approves the release contents. Records: test report,
acceptance sign-off, release notes.

### 5.5 Migration

When the product must move to a new environment (for example a new
database version, operating system or cloud platform) the maintainer
prepares a migration plan covering: analysis of what changes, parallel
operation if needed, data conversion and verification, user notification,
rollback, and a post-migration review. *Example:* migration from
PostgreSQL 14 to 16 planned for Q[n], with two weeks of parallel run in
staging.

### 5.6 Retirement

Retirement of the product or a component follows section 13.

## 6. Resources

<!-- Guidance: People, facilities and external support needed. Base estimates on history where available. -->

| Resource | Quantity / capacity | Source |
|---|---|---|
| *Example:* Maintenance engineers | 4 FTE | Platform applications team |
| *Example:* Test engineer | 1 FTE | Shared QA pool |
| *Example:* Release / configuration engineer | 0.5 FTE | Platform team |
| *Example:* On-call allowance | 1 engineer per week | Rotation of maintenance engineers |
| *Example:* Vendor support | Map SDK premium support | Annual contract |
| [Resource] | [Quantity] | [Source] |

## 7. Metrics and service levels

<!-- Guidance: Define a small set of metrics with formulas and targets, and the service levels per priority. Measure from the tracker, not from memory. -->

### 7.1 Metrics

| Metric ID | Metric | Definition | Target | Source |
|---|---|---|---|---|
| M-01 | Backlog size | Open requests at period end (see formula below) | Stable or falling | Tracker |
| M-02 | Mean time to repair (MTTR) | Mean time from logging to fix released, per priority | P1 under 8 h | Tracker |
| M-03 | Backlog age | Share of open requests older than 90 days | Under 10% | Tracker |
| M-04 | Change failure rate | Share of releases causing a production incident | Under 10% | Release log |
| M-05 | Maintenance type mix | Effort share by type in section 3 | Within 10 points of targets | Timesheets |
| M-06 | Escaped defects | Corrective requests caused by previous maintenance releases | Under 2 per quarter | Tracker |

Backlog at the end of period $t$:

$$
B_t = B_{t-1} + A_t - C_t
$$

where $A_t$ is requests arriving and $C_t$ requests closed in the period.
*Example:* $B_{t-1} = 84$, $A_t = 37$, $C_t = 45$ gives $B_t = 76$.

Mean time to repair over $n$ requests of a given priority:

$$
MTTR = \frac{1}{n} \sum_{i=1}^{n} \left( t_{\text{released},i} - t_{\text{logged},i} \right)
$$

*Example:* five priority 2 fixes released after 30, 46, 52, 70 and 42 hours
give $MTTR = 240 / 5 = 48$ hours.

### 7.2 Service levels

| Priority | Definition | Response time | Resolution or workaround | Fix released |
|---|---|---|---|---|
| P1 Critical | Core function unavailable or data at risk, no workaround | 30 min, 24x7 | 4 h | Emergency release within 24 h |
| P2 High | Core function degraded or workaround costly | 4 business hours | 2 business days | Within 5 business days |
| P3 Medium | Non-core function affected; workaround exists | 1 business day | Next monthly release | Next monthly release |
| P4 Low | Cosmetic, minor improvement | 3 business days | Planned by product owner | As scheduled |

### 7.3 Reporting

A monthly maintenance report to [audience] shows metrics M-01 to M-06,
SLA performance per priority, top requests by impact, and budget used.

## 8. Configuration management

<!-- Guidance: Summarise how baselines, changes, releases and status accounting work for maintenance. Reference the SCM plan for detail. -->

| Topic | Approach |
|---|---|
| Configuration items | *Example:* Source, build scripts, database migrations, reference data, documentation, infrastructure code |
| Baselines | *Example:* Tagged release per maintenance release; production baseline recorded in the CMDB |
| Change control | *Example:* All modifications approved per section 5.2; emergency changes approved retrospectively within 2 business days |
| Versioning | *Example:* Semantic versioning; patch number for maintenance releases |
| Status accounting | *Example:* Release notes and version description generated from the tracker per release |
| Audits | *Example:* Quarterly check that production matches the recorded baseline |

## 9. Tools and environments

<!-- Guidance: List the tools and environments the maintainer needs, their owners and licence status. -->

| Tool / environment | Purpose | Owner | Licence / renewal |
|---|---|---|---|
| *Example:* Issue tracker | Requests, analysis, approvals | Platform team | Enterprise licence, renews YYYY-MM-DD |
| *Example:* Source repository and CI | Code, review, build, test | Platform team | Enterprise licence |
| *Example:* Staging environment | Acceptance testing on production-like data | Operations | Cloud budget |
| *Example:* Monitoring and logging | Detect issues, verify fixes | Operations | Shared service |
| [Tool] | [Purpose] | [Owner] | [Licence] |

## 10. Training and knowledge management

<!-- Guidance: Plan how maintainers learn the product and how knowledge is kept when people leave. -->

| Item | Approach |
|---|---|
| Onboarding | *Example:* Two-week onboarding with architecture walkthrough, paired fixes and runbook reading |
| Knowledge base | *Example:* Runbooks, decision records and known-issue articles in [wiki]; updated with every P1 and P2 fix |
| Cross-training | *Example:* Each component has at least two engineers able to change it |
| Vendor training | *Example:* Map SDK course for one engineer per year |

## 11. Transition from development

<!-- Guidance: Describe how maintenance responsibility is taken over from the development team, with entry criteria and a joint support period. -->

| Item | Detail |
|---|---|
| Transition plan | *Example:* Software transition plan STrP-01 |
| Joint support period | *Example:* 8 weeks with 2 developer engineers available |
| Handover items | *Example:* Source and build environment, as-built design, test suites, open problem reports with analysis, runbooks |
| Entry criteria for take-over | *Example:* Build reproduced by maintainers; regression suite passes in maintainers' environment; three fixes delivered by maintainers |
| Warranty | *Example:* Developer fixes defects in delivered code for 6 months at no cost |

## 12. Budget

<!-- Guidance: Estimate yearly cost by category and show the basis. Compare with actuals each year. -->

| Category | Basis | Annual estimate |
|---|---|---|
| *Example:* Staff | 5.5 FTE at [rate] | [Amount] |
| *Example:* Tools and licences | Tracker, CI, map SDK | [Amount] |
| *Example:* Environments | Staging and test cloud costs | [Amount] |
| *Example:* Vendor support | Map SDK premium support | [Amount] |
| *Example:* Contingency | 10% of the above | [Amount] |
| **Total** | | [Amount] |

Changes above [10 person days] or outside the maintenance types are
funded through change requests or projects.

## 13. Retirement plan

<!-- Guidance: Plan how the product will be withdrawn: triggers, notification, data handling, archive, and decommissioning. Even a rough plan avoids orphaned systems. -->

| Item | Plan |
|---|---|
| Retirement triggers | *Example:* Replacement system in production at all centres; or platform end of support without funded migration |
| Notification | *Example:* Users and dependent systems told at least 6 months before end of support |
| Parallel operation | *Example:* 3 months of read-only access after cut-over |
| Data | *Example:* Records exported to the replacement system; full archive retained for 7 years per records policy; personal data deleted when retention expires |
| Archive | *Example:* Final source, build tools, documentation and data schema archived with checksums |
| Decommissioning | *Example:* Remove servers, DNS, credentials, firewall rules and licences; confirm in CMDB |
| Post-retirement support | *Example:* None after archive; data queries handled by records team |

## 14. Risks

<!-- Guidance: List risks to maintenance itself, with mitigations and owners. -->

| Risk ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| MR-01 | *Example:* Key knowledge held by one engineer for the gateway | Medium | High | Cross-training; documented runbooks | [@name] |
| MR-02 | *Example:* Map SDK end of support before replacement | Medium | Medium | Budget adaptive upgrade in year 2 | [@name] |
| MR-03 | *Example:* Corrective work crowds out preventive work | High | Medium | Reserve 20% capacity; monitor M-05 | [@name] |
| [MR-NN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |

## 15. Appendices

<!-- Guidance: Glossary and supporting material referenced from the body. -->

| Term | Meaning |
|---|---|
| CCB | Change control board |
| MR | Modification request, the record for any maintenance request |
| MTTR | Mean time to repair |
| SLA | Service level agreement |

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 14764:2022 (Software engineering,
Software life cycle processes, Maintenance), for the maintenance process
activities and the maintenance concept and plan. Maintenance type
definitions, metrics, service levels and examples are written for this
collection. This template is original text written for this collection
and reproduces no text from the standard; obtain the standard for its
normative requirements. Template licence: MIT.