Ongoing Software Support: What It Covers and How to Specify It

Ongoing software support is the continuing engineering work that keeps a custom application secure, correct, compatible with its surrounding systems and able to change with the business after launch. A sound arrangement defines what is covered (maintenance, security patching, defect correction, monitoring, integration upkeep), how quickly each class of problem is answered and resolved, who escalates to whom, and how the application is allowed to evolve. Without those definitions, support degrades into an informal habit that works until the first serious incident.

TL;DR

• Ongoing support is a defined engineering service, not an open-ended favour: it covers maintenance, security updates, bug fixes, monitoring, integration upkeep and a controlled path for change.
• Software left unsupported accumulates known vulnerabilities, drifts out of compatibility with the systems around it and loses the people who understood it.
• A support agreement should state priority levels, response and resolution targets, escalation routes, reporting and the handover of knowledge, in writing.
• The partner chosen for support should be assessed on engineering practice and continuity (documentation, code review, testing, capacity limits), not on price per hour alone.
• Direct access to the engineers who maintain the system shortens diagnosis and keeps technical decisions aligned with business priorities.

Table of Contents

• What ongoing support actually includes
• Why a launched application still needs engineers
• Maintenance, security updates and bug fixes
• Keeping integrations working as other systems change
• Service levels, response times and escalation
• Choosing a partner for long-term support
• Our perspective
• How we structure support and advisory work
• FAQ
• Sources

What ongoing support actually includes

The term is used loosely, and the looseness is the first risk. A business that buys “support” may expect a help desk, while the supplier understands it as a number of hours available for fixes. For a custom business application, the scope is better described as five distinct streams of work, each with its own cadence and its own measure of success.

The distinction between the first four and the fifth matters contractually. The first four keep the existing system in a known good state; the fifth changes it. Agreements that blur the two tend to produce disputes, because a defect fix is an obligation while a new feature is a priced piece of work. Separating them, usually with a monthly allowance for evolution, makes the commercial arrangement predictable and protects the maintenance capacity from being consumed by feature requests.

Why a launched application still needs engineers

A release is the moment at which an application starts meeting conditions its authors could not fully reproduce: real data volumes, unusual user behaviour, third-party services that change without notice and security researchers who read the same dependency lists as the development team. The reasons for continuing support fall into four categories.

The first is the pace of the components. Modern applications are assembled from frameworks, libraries, container images and managed cloud services, each with its own release cycle and its own end-of-support date. An application built on Next.js, Spring Boot or Quarkus remains correct only as long as its dependencies stay within supported versions; the longer upgrades are deferred, the larger and riskier each one becomes. Small, regular upgrades are cheaper and safer than a single forced migration under deadline.

The second is the surrounding environment. Browsers, operating systems, identity providers, payment gateways and regulatory reporting formats all change on their own schedules. An application that was compatible on the day of delivery is therefore compatible only by default of nobody having changed anything, which is never a stable condition.

The third is knowledge. The engineers who designed a system hold context that is rarely fully written down: why a queue was introduced, which edge case a certain validation handles, what the deployment sequence must respect. When no one is responsible for the system, that context decays, and the cost of the next change rises with every departure.

The fourth is the business itself. Volumes grow, products are added, customers ask for integrations. A platform that has a maintainer can absorb these changes incrementally; one that has none is typically replaced wholesale, at far higher cost than the support that would have prevented it.

Maintenance, security updates and bug fixes

The three activities share tooling but differ in urgency, and a support agreement should treat them separately.

Bug fixes begin with reproduction. A competent support function asks for the minimum data needed to recreate a failure, writes a failing automated test that captures it, corrects the code, and releases the fix through the same pipeline as any other change. The regression test then remains in the suite, so that the same defect cannot return unnoticed. Fixes applied directly to production without a test and a review are the main source of repeated incidents.

Security updates rest on knowing what the application contains. The US National Institute of Standards and Technology frames vulnerability management as addressing known software defects, and notes that the CVE and CWE identifiers help to name specific vulnerabilities and the coding weaknesses behind them, while patching and better coding limit the success of attacks. In operational terms, this means maintaining an inventory of dependencies, monitoring advisories against it, assessing whether a published vulnerability is reachable in the application, and applying a patch within a period proportionate to the severity. The quality of the surrounding practice, notably code review processes, determines how many weaknesses reach production in the first place and how safely a patch can be introduced.

Routine maintenance covers the unglamorous work that prevents emergencies: renewing certificates, rotating secrets, upgrading runtimes before they leave support, verifying that backups can actually be restored, and pruning dependencies that are no longer used. A monthly or quarterly maintenance window, reported in writing, converts this from an invisible risk into a visible, auditable activity.

For regulated sectors or customers who ask security questionnaires of their suppliers, the written record is itself a deliverable. A log showing when each advisory was assessed and when each patch was applied answers most audit questions without further effort.

Keeping integrations working as other systems change

Integration is where custom applications most often fail silently. A system that exchanges data with an ERP, a CRM, a payment provider or a partner’s API depends on contracts it does not control. Fields are renamed, authentication schemes are retired, rate limits are tightened, and message formats gain mandatory elements. Each change breaks something only if nobody is watching.

Ongoing support addresses this in four ways. Contract tests run against the interfaces the application consumes, so that an incompatible change is detected in a test environment rather than by a customer. Monitoring tracks the health of each integration separately, with alerts on error rates and on the absence of expected traffic, since an integration that stops sending data produces no errors at all. Versioned APIs and message schemas, with a stated deprecation policy, allow the systems on either side to move at different speeds. Finally, a maintained register of integrations, recording owner, protocol, credentials location and failure behaviour, gives incident responders the map they need at the worst possible moment.

Message-driven architectures deserve a particular mention. Queues and event streams decouple systems well, but they also hide failures: a growing backlog, a poison message or a consumer that has fallen behind can persist for days. Support for such a system should include explicit alerting on queue depth and age, together with a documented procedure for replaying or discarding messages.

Legacy estates add a further dimension. Where a modern application sits beside an older system that cannot be changed, the support function becomes the keeper of the adapter between them, and its stability determines how long the older system can safely remain in service.

Service levels, response times and escalation

A support agreement is only as useful as its service levels are precise. Four elements need to be written down: how incidents are classified, how fast each class receives a response, how fast it should be resolved or mitigated, and what happens when the target is missed.

The classification is normally a four-level priority scale. As a published example, BT’s managed services schedule for Microsoft Azure sets the following targets.

These figures describe a large infrastructure service and should be treated as an illustration of the structure, not as a benchmark every application must meet. The appropriate numbers depend on the cost of downtime: an internal reporting tool may tolerate a next-business-day response for most issues, while a transactional platform serving customers across time zones may require round-the-clock cover for the highest priority. What matters is that the definitions are objective. A P1, for example, should be described by observable conditions such as complete unavailability or data loss, not by the urgency felt by whoever raises it.

The same discipline applies to first-line handling. Where a business expects users to report problems by telephone, structured priority-based response and resolution commitments at the first line determine how quickly an issue reaches the engineers who can act on it, and how well it is described when it arrives.

The agreement should also specify the following in narrative form, since the arrangement is only workable if both parties read it the same way:

The channels through which incidents are raised, and which of them is authoritative for measuring time. The hours of cover for each priority, distinguishing business hours from continuous cover. The escalation path, naming roles rather than individuals, with the time after which an unresolved incident passes to the next level and the point at which senior engineering and business stakeholders are informed. The communication cadence during a major incident, for instance regular written updates until service is restored. The post-incident review, with a written analysis of cause, impact and corrective action for every P1 and for any repeated P2. The reporting period and content, including incidents by priority, performance against targets, open vulnerabilities and the state of the dependency inventory. And the remedies if targets are repeatedly missed, whether service credits, a remediation plan or a right to terminate.

Each of these items costs little to write at the outset and a great deal to negotiate during an outage.

Choosing a partner for long-term support

Selecting a team to maintain a system for years is a different decision from selecting a team to build it, although the best outcomes occur when the two coincide. The criteria below concern the engineering organisation more than the commercial offer.

Proximity to the engineers comes first. In a model where the client communicates directly with the people who diagnose and change the software, an incident description is not filtered through an intermediary, and decisions about trade-offs are taken with the technical facts at hand. Layers of coordination add delay precisely when delay is most expensive.

Capacity discipline follows. A supplier that accepts every project simultaneously cannot guarantee attention to any of them. A stated limit on concurrent engagements is a sign that response commitments are backed by real availability.

Engineering practice is the third criterion, and it can be verified. Reviewers should ask to see how code is reviewed before merging, what proportion of critical paths is covered by automated tests, how releases are deployed and rolled back, and what monitoring exists in production. A team that cannot show these will not be able to support a system safely.

Transparency of reporting is the fourth. Written recommendations, regular reports and open access to the issue tracker allow the client to see the condition of the system without asking. This also reduces dependency: the documentation, infrastructure definitions and runbooks should belong to the client, so that the arrangement can continue, change or end without loss of the ability to operate the system.

The fifth is technological neutrality. A partner with no commercial interest in a particular vendor can recommend a framework migration, a cloud service or a retirement of a component on technical merit. Where recommendations are delivered in writing, the client also holds a record of the reasoning, which is valuable when the decision is reviewed later.

Continuity and growth planning is the last. The agreement should anticipate team changes on both sides, specify a knowledge-transfer procedure, and set out how capacity can be scaled up for a growth phase or a migration, for example by moving from a small monthly retainer to a larger allocation without renegotiating the whole contract. An initial assessment of the existing codebase and infrastructure is a sensible way to begin, since it replaces assumptions about the system’s condition with a documented baseline against which support can be priced and measured.

Our perspective

We regard ongoing support as part of the architecture, not an afterthought attached to it. A system designed to be maintained has observable behaviour, automated tests, reproducible deployments and documentation written while the decisions are still fresh, and these properties cost very little at the start and a great deal to add later. When we take on a system built by someone else, the first piece of work is an honest assessment of its state, delivered in writing, because support priced on assumptions is support that disappoints both sides.

We also hold that the people who maintain software should be the people the client speaks to. Our engineering-first model removes the account-manager layer, so questions about risk, upgrade timing and technical debt reach the engineers responsible, and the business can weigh them against its own priorities with accurate information. We limit the number of projects running at the same time for the same reason: a response commitment is credible only if someone has the time to honour it.

Finally, we advise clients to treat support as a way of preserving optionality. A maintained application can be extended, integrated, migrated or handed over; an unmaintained one can mostly be replaced. The monthly cost of keeping the first condition is almost always lower than the one-off cost of recovering from the second.

— Pepe F.

How we structure support and advisory work

For organisations that want continuing technical ownership without building a full in-house team, we offer CTO Advisory from €1,800 per month, Fractional CTO from €4,000 per month and CTO Partner from €7,500 per month, with an initial assessment from €3,500 as a one-off. Details of each tier are on the CTO subscription page. Maintenance, code audit, technical debt reduction, integration work and AI and automation are described under our services, and examples of delivered work can be found in the case studies. For a system that needs a new or continuing development team, the custom software development page explains how an engagement begins.

FAQ

What is the difference between maintenance and support?

Maintenance is the planned engineering work that keeps software healthy: updates, patches, dependency upgrades and preventive checks. Support is the responsive part, handling incidents and questions as they arise. In practice a good agreement covers both, with maintenance scheduled and reported and support governed by priority-based response targets.

How long should custom software be supported?

For as long as it remains in productive use, since its dependencies, integrations and threat environment continue to change. The practical decision is not whether to stop but at what level to continue, for example reducing to security maintenance and monitoring for a stable system with few changes. Reviewing the level annually against the roadmap keeps the cost proportionate.

What should a support agreement specify about response times?

It should define priority levels by observable conditions, a response target and a resolution or mitigation target for each, the hours during which those targets apply, and the escalation route when they are missed. Published schedules, such as the four-level example above, show the usual structure, but the figures should reflect the cost of downtime for the specific application.

Can a different team take over support for software it did not build?

Yes, provided the handover begins with an assessment of the code, infrastructure and documentation. That baseline reveals missing tests, outdated dependencies and undocumented integrations, which can then be priced and prioritised before the support commitments take effect. Attempting to promise service levels on an unexamined system is the most common cause of later disagreement.

Sources

• NIST IR 8011 Vol. 4, Automation Support for Security Control Assessments
• BT Microsoft Azure Cloud Managed Services Schedule

Recommended

• Custom Software Development Services

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.