Software Maintenance Plan Template (ISO/IEC/IEEE 14764)

Maintenance concept, types, organisation, request process, metrics (backlog, MTTR), SLAs, CM, transition, budget, retirement

Software e ingenieríaCompletaISO/IEC/IEEE 14764:2022software maintenance plan mathActualizada 20 oct 2026

Abrir en el editorDescargar .md

Cómo usar: Use it before a product moves from development to maintenance. Fill the maintenance concept first (scope, maintainer, support levels, planned life), then process, service levels and budget. The main pitfall is leaving retirement unplanned or letting corrective work crowd out preventive work.

Vista previa

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.

Document control

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

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

Introduction
Maintenance concept
Maintenance types
Organisation and responsibilities
Maintenance process
Resources
Metrics and service levels
Configuration management
Tools and environments
Training and knowledge management
Transition from development
Budget
Retirement plan
Risks
Appendices
Standard and licence note

1. Introduction

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

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

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

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

The lifecycle of a request is shown below.

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

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

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

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

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

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

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

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

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

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

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.

Plantillas relacionadas

Software e ingeniería