MaintenanceBusiness softwareContractsSubscriptionSMEs
Business application maintenance: what really happens after go-live, and what your contract must say
8 min read
Go-live feels like a finish line. For a business application, it is the starting point: from that day, people depend on the software to do their jobs, and it has to keep running, stay secure and follow the business as it changes.
That is what maintenance is for. The word means very different things from one provider to the next, which is where most disappointments start. Some vendors sell "support" that only answers tickets; others include hosting, patching and a monthly allowance of new features. This guide explains what maintenance actually contains, how it is usually organised and priced, and the questions to put to any provider before you sign.
Software does not stay stable on its own
It is tempting to think that delivered, tested software keeps working forever as long as nobody touches it. The opposite happens.
A modern application rests on dozens of components: a programming language, a framework, libraries, an operating system, a database, a hosting platform. Each of them ships regular patches, some of which close publicly known security holes. Browsers change, third-party services retire their APIs, TLS certificates expire, and payment or tax rules move.
So an application nobody maintains does not stay frozen. It drifts away from its environment until a forced update breaks it, or a known vulnerability stays open for anyone who looks. The longer the drift, the more expensive the catch-up.
The first weeks after launch are a special period
The weeks after go-live look like no other. Users meet the application in real conditions, with their real data and their real edge cases. Defects that user acceptance testing did not reveal appear, some workflows turn out less practical than planned, and change requests arrive in bulk.
This period, often called hypercare, needs preparing. Decide in advance who collects feedback, how it is sorted into defects and enhancements, and how often fixes are released. A provider who considers the job done on launch day leaves you alone at the moment you most need support.
The four kinds of maintenance work
The international standard on software maintenance, ISO/IEC/IEEE 14764, distinguishes four categories of change after delivery. They are a useful checklist, because a contract that only mentions one of them is usually silent on the other three.
| Type | What it does | Example | How it is usually triggered |
|---|---|---|---|
| Corrective | Fixes defects found in use | A discount is not applied to an invoice in one edge case | A user reports an incident |
| Adaptive | Keeps the software working in a changed environment | A payment provider retires its old API | An external change, often with a deadline |
| Perfective | Improves features, usability or performance | A new user role, a faster report | A request from the business |
| Preventive | Removes latent faults before they cause failures | Upgrading a library before its end of life | The provider's own schedule |
Two practical points follow.
Preventive and adaptive work is invisible, so it gets cut. Users never see a framework upgrade or a dependency patch. Budgets under pressure drop it first, and it is precisely the work that prevents most bad surprises.
Perfective work is where the value is. The first months of real use almost always surface adjustments that save hours every week. If your contract covers only bug fixes, every one of those becomes a separate quote and a negotiation.
Operations: the fifth line item
Alongside code changes sits operations: hosting, backups, monitoring and security patching of the servers. A backup is worth something only if a restore has been tested. Monitoring is worth something only if a named person is alerted when it fires. Operations are sometimes handled by a different company from the developers, which makes it essential to write down who does what, including where the data is stored and under which jurisdiction.
What a maintenance agreement must specify
A maintenance agreement is best read for what it does not say. These are the questions to ask, whoever the provider is.
- What exactly is covered? All four kinds of work plus operations, or bug fixes only? Are security updates included or billed on demand?
- How do you report an incident? Through which channel, during which hours, and who decides on its severity?
- What are the response and resolution targets? They must distinguish a full outage from a minor annoyance. A single target for everything means very little.
- Who hosts, who backs up, where does the data live? How often are restores tested, and who has access to production?
- How are enhancements requested and priced? Case by case, from a monthly or yearly allowance of days, or included in a subscription?
- What happens when the contract ends? Documentation, access, data export and handover assistance are far easier to negotiate at the start than at the separation.
A typical severity grid looks like this. The figures are yours to negotiate; the structure is what matters.
| Severity | Definition | What the contract should state |
|---|---|---|
| Critical | The application or a core function is down, no workaround | Response time, target for a workaround, out-of-hours cover or not |
| Major | A function is degraded, the workaround is painful or risky | Response time, target for a fix in a scheduled release |
| Minor | An annoyance with no effect on the business | Logged and fixed in a planned release |
A commitment that is not written down is not a commitment. If an answer is vague at signature, it will be just as vague on the day of the incident. Our article on software development contract clauses covers the rest of the agreement.
Two ways to organise life after launch
There are two main models, and they split responsibilities differently.
A fixed-price build, followed by a separate maintenance contract. The software is delivered, then a distinct agreement covers its life. This model is easy to read, provided the maintenance terms are negotiated at the same time as the build, and not once the application is in production and your bargaining position has changed. The maintenance can be handled by the original team or outsourced; our guide to application maintenance outsourcing explains how that market works.
A subscription that includes everything. The provider builds, hosts, maintains and evolves the application for a monthly fee. Maintenance stops being a line item to negotiate: it is part of the service, and the provider has every reason to keep the code healthy, since it carries the cost of its own shortcuts. The trade-off is that the provider remains the publisher and operator of the software, with rights defined case by case in the contract.
Neither model is better in absolute terms. The first suits a company that wants to run operations itself or hand them to its own IT team. The second suits one that wants software that works without managing the technical side. The two are compared in detail in software subscription vs upfront build, and LPR Studio's own formulas are on the offers page.
Warning signs of a poorly maintained application
Some situations should worry you, even when the application seems to work.
- Nobody can say which versions it runs. Not the framework, not the database, not the operating system of the server.
- Backups have never been restored. An untested backup is a hypothesis, not a guarantee.
- Every fix breaks something else. A sign of an application without automated tests, where every change is made blind.
- Every change request gets the same answer: "it's complicated". The application has become too risky to modify.
- One person knows the code. And nothing is written down.
When several of these signals stack up, the question is no longer how to maintain the application but how to take it back in hand, or replace it. Our guide to replacing unsupported business software covers that decision.
Documentation: your insurance policy
The best protection against failing maintenance is a documented application: how to install it, how to deploy it, what it depends on, where its data lives, and which business rules it applies. That documentation serves the current provider as much as the one who might take over.
Ask for it when you sign the contract, not when you change provider. What is handed over at the end depends on the model chosen and on rights defined case by case in the contract, which makes it a question to ask at the same time as the price.
A business application is judged less on its launch day than in its third year. If you are preparing a project, a free visual prototype lets you validate what the application will do; maintenance decides what it will become.