What belongs in a software maintenance plan?

Once people depend on an application, somebody needs to keep it useful. That includes responding to problems, looking after its dependencies, and understanding when the business needs it to change.

A maintenance plan should explain that work in language the business and its technical provider both understand.

Separate different kinds of work

Use categories that make the agreement easier to discuss. The following is a planning framework, not a universal contract definition.

Ask which categories the proposed arrangement includes, which are separately charged, and which remain your responsibility.

The Government Digital Service's live-phase guidance treats live operation as sustainable support and continuing improvement. It also calls for changes to be researched and tested. Those principles are useful beyond government, although its assessment requirements are specific to government services.

Name the owner for each dependency

List the services the application relies on: hosting, email delivery, identity, payments, integrations, and any other relevant supplier. Record the account owner, technical contact, renewal responsibility, and escalation route.

Do not assume the development team automatically controls every account. Equally, an account billed to your business may still lack a usable administrative handover.

For an illustrative booking system, a working application with a failed confirmation-email connection still creates a customer-service problem. Decide who investigates across those boundaries.

Define response and recovery separately

A response commitment should explain when somebody acknowledges and begins handling an issue. A recovery target describes the desired return of service. They are different commitments; confirm the wording of the actual arrangement.

Agree how severity is assessed using business impact. A minor display defect and an inability to accept orders should not enter the same queue without distinction.

Include contact methods, coverage hours, escalation, and who communicates with affected staff. If a workaround is available, record who can authorize it and how records created during the workaround will be reconciled.

Ask for evidence of routine care

Choose a reporting cadence that fits the application. A useful maintenance note could summarize recent changes, unresolved incidents, important dependency notices, and upcoming decisions.

Ask for a visible owner and next action on each unresolved item. Avoid turning the report into a list of reassuring technical terms with no decision attached.

Include periodic checks of the recovery procedure. Our backup restoration guide explains why a successful backup notification is only part of that evidence.

Keep the plan current as the business changes

Revisit the arrangement when the application gains a new integration, more operating hours, or a more important role in the business. The support plan should reflect the service people now depend on.

At review time, separate recurring defects from requests for new capability. Both deserve attention, but they need different decisions about scope and priority.

Before the original project team steps back, use a software handover to check that the maintainer can access, understand, and operate the actual system. Maintenance becomes easier to evaluate when responsibility is explicit from the start.