Custom software maintenance after launch: who owns what?

Make “maintenance” a description of work

A monthly allowance of engineering hours does not tell an operations team what happens when its platform stops assigning requests. Start the discussion with the work the business depends on: receiving orders, approving requests or completing a service case. Then agree which parts of that work the supplier supports and what remains with your team or another provider.

Separate incident handling, preventive upkeep and new development. Investigating a failed approval is incident work. Reviewing dependency updates and testing a supported upgrade are preventive work. Adding another approval stage is product development. These can share one arrangement, but the priorities, capacity and approval process need to be explicit. Clarify whether corrective work is covered by an existing warranty, the maintenance scope or a separate estimate.

The GOV.UK Service Manual treats the live phase as sustainable operation alongside continued improvement and quality assurance. For a business platform, that is a useful planning principle: budget attention for keeping the current workflow usable as well as changing it.

Pair each responsibility with evidence

Response, restoration and resolution are different

Agree what each term means in your arrangement. Response can mean a person has taken ownership and started assessing the incident. Restoration means the agreed workflow is usable again, possibly through a temporary workaround. Resolution means the underlying fault has been corrected and the result checked. An automated receipt should not be mistaken for an engineer starting work, and a response target does not promise restoration by the same deadline.

Define severity by business impact, including a critical workflow that fails while the website still loads. Record the reporting channel, when each clock starts, coverage hours and timezone, update expectations and the escalation path outside those hours. If an uptime commitment is proposed, define separately what it measures, over which period and with which exclusions. Coverage hours alone establish none of that.

Also name the internal person who can approve a temporary process or interruption. A supplier can diagnose a fault without being authorized to decide how your staff should handle affected customers.

Rehearse a failure that an uptime check could miss

For example, imagine a platform that accepts service requests but stops assigning them after an update. Staff can sign in and every page loads. In a planned rehearsal, use test records in a safe environment and trace one request from submission to an assigned operator.

Ask the supplier to show how the failure reaches the support owner and how an unanswered alert escalates. Have the internal process owner decide whether to pause new requests or use an agreed temporary queue. Identify which requests were accepted before that decision, so staff know where work is waiting.

Next, walk through the recovery choice. Reverting application code may restore assignment, but it does not automatically repair requests already left in the wrong state. Agree who checks the affected records, how missing assignments will be completed and how duplicate work will be avoided. Close the exercise only when an operator can continue the workflow and the outstanding records are accounted for.

The useful output is a short record of who acted, what they needed, what worked and what still needs fixing. An inaccessible account, an unanswered alert or an unclear business decision becomes a specific task with an owner.

Ask for a recovery result, then keep it current

AWS’s reliability guidance recommends restoring backups and checking that the recovered data is usable, within the workload’s recovery-time and recovery-point objectives. The first concerns how long recovery may take; the second concerns how much recent data may be lost. Ask for the latest test result against your agreed objectives, including what was recovered, what was checked and any gaps.

A test of one database is not evidence that the entire platform can resume. Ask which files, configuration, access and external services the recovery needs. Agree a safe rehearsal scope and who will recheck it when the system changes. Keep test activity separate from live customer messages, payments or other business actions.

For routine updates, GOV.UK’s deployment guidance connects release cadence to the team’s ability to support changes and recommends checks of important functions and essential dependencies after deployment. Translate that into a concrete question: which workflow will the team check after this release, and what will it do if the check fails?

Could another team operate the platform?

Source-code access is one part of a handover. A receiving team also needs to know which version is live, how to release it, where configuration is managed, which services it depends on and where to find open incidents. Confirm that the business has the agreed administrative access to relevant accounts, with permissions appropriate to each role and account-recovery details managed by the business.

Before approving the ongoing arrangement, ask the supplier to demonstrate the answers to these questions:

• Can a designated colleague access the code, hosting and backup controls through their own authorized account?
• Can the receiving engineer follow the documented release and recovery procedures, and identify any missing prerequisites?
• Which licenses, provider accounts or specialist knowledge would need a separate transfer?
• If the engagement ends, who supplies the documentation, data export and open-work list, and when is outgoing access removed?