Web Application Support and Maintenance

Set operational expectations around these areas

What does web application support include?

Support for a web application covers everything that happens after the initial build is accepted and goes live. It is not a single activity but a set of distinct responsibilities that keep the system running, secure and useful as the business changes.

The core components typically fall into these categories:

Infrastructure management: keeping servers, databases and related services operational. This includes applying operating-system updates, managing certificates, monitoring disk space and ensuring the hosting environment remains stable.
Application maintenance: fixing defects that appear in production, making small adjustments to existing features and ensuring the codebase continues to work correctly as underlying dependencies change.
Security upkeep: applying patches to frameworks and libraries, reviewing access controls, responding to vulnerability disclosures and maintaining any compliance-related logging or reporting.
Data management: running backups, verifying restore procedures, managing data retention and handling data migration when structures change.
Third-party integration monitoring: checking that connections to external services — payment processors, accounting software, email providers — continue to work after either side makes changes.
User support: handling queries from people who use the system, diagnosing issues they report and, where appropriate, making configuration changes rather than code changes.

A common mistake is assuming that support simply means fixing things when they break. In practice, the majority of support effort for a stable application goes into planned maintenance and monitoring, not reactive fixes. When scoping a support arrangement, it is worth asking a supplier to break down what they include under each of these headings, because the gap between a basic bug-fix-only retainer and a comprehensive support package can be substantial.

How to plan for web application updates and patches

Updates and patches fall into two broad types: those that keep the existing system working — dependency updates, security patches, minor compatibility fixes — and those that add or change functionality — feature releases, workflow changes, integration additions.

For the first type, the planning question is not whether to do them but when and how often. Most web applications rely on a stack of open-source libraries, frameworks and runtime environments, each of which publishes updates on its own schedule. Left unmanaged, these accumulate into a backlog that becomes progressively harder and riskier to address.

A practical approach is to agree a regular patching cadence with whoever manages the system. This might be monthly, quarterly or twice a year depending on the application's risk profile and the resources available. The key elements of that cadence should include:

A dependency audit: listing every external library and its current version, then comparing it against the latest available release and any known security advisories.
A risk assessment for each update: not every patch needs immediate application, but security-critical ones usually do. The assessment should consider what the library does, how exposed it is and whether a vulnerability is actively being exploited.
A testing window: running the updated application through a defined set of checks before deploying to production. The depth of testing should be proportionate to the change.
A deployment procedure: including a rollback plan if the update causes unexpected problems.

For functional updates, the planning process is closer to a small-scale project. Each change should have a clear description, acceptance criteria and an understanding of how it interacts with existing features. Grouping several small changes into a single release cycle is usually more efficient than deploying each one individually, provided the group is tested together.

End-of-life planning for web applications

Every web application will eventually reach a point where continued operation is no longer practical or cost-effective. That might be because the underlying technology is no longer supported, because the business processes it serves have changed beyond recognition, or because the cost of maintaining it exceeds the value it delivers.

End-of-life planning is the process of recognising that point early enough to manage the transition on your own terms rather than being forced into it by a failure.

The first step is establishing clear criteria that would trigger an end-of-life review. These might include:

The primary framework or language reaching its end of official support.
The cost of a single year's maintenance exceeding a defined proportion of the system's measured business value.
The loss of a critical integration partner or third-party service that cannot be replaced within the current architecture.
An inability to find developers willing or able to work with the technology stack.

Once a review is triggered, the next question is what replaces the system. That might be a rebuilt version on a modern stack, a shift to a commercial off-the-shelf product, or the absorption of the system's functions into a broader platform. Each option has different implications for data migration, user transition and timing.

Data handling is often the most sensitive part of end-of-life planning. You need to know what data the system holds, where it is stored, what retention requirements apply and how it will be extracted, transformed and either migrated to the replacement system or securely disposed of. This should be documented before the decision to retire the system is finalised, because the extraction process itself may require changes to the existing application.

How to handle a web application that needs urgent fixes

An urgent fix — often called a hotfix — is a change made outside the normal release cycle because a problem is actively causing significant harm. That harm might be a security breach, a complete outage, a data corruption issue or a critical function that has stopped working for a meaningful number of users.

The first priority in any urgent situation is containment: stopping the problem from getting worse. Depending on the nature of the issue, that might mean taking a feature offline, restricting access, switching to a backup or reverting a recent change. The instinct to fix forward is strong, but reverting to the last known-good state is often faster and safer when the root cause is not yet understood.

Once the immediate impact is contained, the process should follow a structured sequence:

Diagnosis: establishing what changed, when and why. This is where audit logs and deployment records become directly valuable.
Fix development: writing and reviewing the code change in isolation, with at least one other person checking it before it goes anywhere near production.
Targeted testing: checking that the fix resolves the specific problem without introducing a new one. Full regression testing is usually not appropriate at this stage because of time pressure, but the fix itself should be verified thoroughly.
Deployment: applying the fix to production with someone available to monitor the result immediately afterwards.
Post-incident review: once the situation is stable, documenting what happened, why the normal process did not prevent it and what should change to reduce the likelihood of recurrence.

A common mistake is treating every reported issue as urgent. If a non-critical feature behaves unexpectedly but the core functions of the system are unaffected, that is a normal support ticket, not a hotfix. Agreeing clear definitions of what constitutes urgency with your supplier or internal team in advance prevents the normal maintenance queue from being constantly disrupted.

Transitioning between web development suppliers

There are many reasons a business might change the supplier responsible for supporting a web application: the original developer may no longer be available, the relationship may have broken down, or the application may have outgrown the current supplier's capabilities.

Regardless of the reason, the transition needs to be planned as a distinct piece of work, not left as an afterthought. The practical steps fall into three phases.

Before the handover begins

Ensure you have complete access to everything the current supplier controls. That typically includes: the source-code repository and its access credentials; the hosting infrastructure and administrative access; the database and its credentials; any third-party service accounts such as email, payment and analytics; domain registrar access; SSL certificate management; and any documentation that exists. If any of these are missing or contested, resolve that before the new supplier starts. Ownership and access rights should already be clear from the original contract, but in practice they are often ambiguous until someone tries to exercise them.

During the handover

The new supplier needs to establish a working understanding of the system. That means a structured knowledge-transfer process, not simply handing over a codebase and hoping for the best. A practical approach is to have the outgoing supplier walk through the architecture, the deployment process, the known issues and the areas of the code that are most fragile. If the outgoing supplier is not cooperative, the incoming one will need to reverse-engineer that understanding, which takes longer and costs more.

After the handover

Allow a defined period — often a month or two — where the new supplier runs the system with a safety net. That might mean keeping the previous supplier on a reduced retainer for consultation, or ensuring the new supplier has fully tested their own backup and restore procedures before the old supplier's access is fully removed.

How to manage a long-term support relationship

A long-term support relationship works best when both sides have clear, aligned expectations about what the arrangement covers, how requests are handled and how the relationship will evolve as the application ages.

The starting point is a support agreement that specifies, in concrete terms:

The scope of what is included and what is excluded. "Support" is too vague. Does it cover only defect fixes, or does it include small enhancements? Does it cover infrastructure, or only the application code? Does it include user support, or only technical maintenance?
The response and resolution targets for different severity levels. These should be realistic and tied to actual business impact, not arbitrary service-level numbers copied from a template.
The process for raising, prioritising and tracking requests. A shared ticket system is standard, but the important thing is that both sides agree on how priorities are assigned and what happens when the queue exceeds capacity.
The cadence of planned maintenance activities, such as patching, backup testing and dependency updates.
The arrangements for communication: who is the primary contact on each side, how often do you review the relationship, and what happens if either side needs to escalate an issue.

A frequent source of friction in long-term support relationships is the boundary between support and new development. A business asks for a change that feels small, the supplier treats it as a new feature, and a disagreement follows about whether it is covered by the retainer. The most effective way to prevent this is to define that boundary explicitly: for example, any change that requires more than a defined number of hours, or that alters the data model, or that affects more than one module, is treated as a separate piece of work.

It is also worth reviewing the support arrangement periodically — at least annually — to check whether it still reflects the application's current state and the business's current needs. An application that was mission-critical three years ago may now be peripheral, or vice versa. The support package should reflect that reality rather than continuing on autopilot.

Planned vs emergency maintenance for business systems

Understanding the distinction between planned and emergency maintenance matters because they require different processes, different resources and different budgeting approaches.

Planned maintenance is the work you schedule in advance because you know it needs to happen. This includes dependency updates, security patches, backup testing, log rotation, certificate renewals, performance reviews and any preventive work identified through monitoring. The characteristics of planned maintenance are that it is predictable, can be tested before deployment and can be scheduled for low-impact windows.

Emergency maintenance is the work you did not plan for because it is a response to an unexpected failure or discovery. This includes production outages, security incidents, data corruption and the sudden failure of a third-party integration. The characteristics of emergency maintenance are that it is unpredictable, often requires fast decisions with incomplete information and carries a higher risk of introducing further problems.

The practical goal for any business system is not to eliminate emergency maintenance entirely — that is unrealistic — but to minimise it through effective planned maintenance and to ensure that when emergencies do occur, the response is structured rather than chaotic.

A useful way to think about the balance is to track the ratio of planned to emergency work over time. If emergency work consistently consumes a large proportion of the total maintenance effort, that is a signal that the planned maintenance programme is insufficient or that the system has underlying stability problems that need to be addressed as a project in their own right, not as a series of ad-hoc fixes.

Budgeting should reflect this distinction. Planned maintenance can be costed with reasonable accuracy because the scope is known. Emergency maintenance should be budgeted as a contingency, with an understanding that some months will use none of it and others will exceed it. A support retainer that bundles both together without distinguishing between them can obscure whether the planned work is actually getting done or whether the budget is being consumed by reactive fixes.