Most software budgets are written as if launch day is the finish line. Then the first invoice for "maintenance and support" arrives and the obvious question follows: the system works, so what exactly is being paid for?

This guide explains what happens to a website, mobile app or custom system after it goes live, which parts of that work are optional and which are not, how support is usually packaged, and what a maintenance agreement should say. It is written for owners and managers in the US and UK who sign the contract but do not write the code.

Quick answer

Software maintenance is the work needed to keep a live system secure, compatible and useful while everything around it keeps changing. You are paying for four things:

• Fixing defects that only show up with real users and real data.
• Keeping up with changes you do not control: security patches, framework and operating system versions that reach end of life, app store rules, browser releases and third-party APIs.
• Improving the product as you learn how people use it.
• Preventing failures through monitoring, backups, restore tests and housekeeping.

Support is the human side of the same service: someone who answers when something breaks, within an agreed time. The first two items above are not discretionary. They arrive on other people's schedules whether or not you have budgeted for them.

Why finished software still needs work

A building does not change because the street outside was repaved. Software does. A typical business application sits on a programming language, a framework, dozens or hundreds of open-source packages, a database, a server operating system, a hosting platform, and several outside services such as payments, email and maps. Each has its own owner, release schedule and retirement date.

Your code can be untouched for a year and still stop working, because a payment provider retired an old API version, a phone operating system changed a permission rule, or a package it depends on was found to have a security flaw. Maintenance is mostly the cost of staying in step with that moving environment.

The four types of maintenance in plain terms

Software engineers commonly sort maintenance work into four categories. The labels are useful because they show which costs you can plan and which you cannot avoid.

A useful question for any provider is how your monthly fee or hours are split across these four. A plan that is all corrective means you are only paying for firefighting. A plan with no perfective capacity means the product stands still.

Security patches and dependency updates

Very little of a modern application is written from scratch. Most of it is assembled from third-party packages, and vulnerabilities are found in those packages continuously. When a fix is published, the flaw becomes public knowledge at the same moment, so the gap between "patch available" and "patch applied" is the period of greatest exposure.

Regulators and security agencies on both sides of the Atlantic treat patching as a baseline expectation, not an extra:

• The US Federal Trade Commission's Start with Security guide tells businesses to have a reasonable process to update and patch third-party software, and describes security as an ongoing process.
• The UK National Cyber Security Centre's vulnerability management guidance advises installing security updates as soon as possible and triaging vulnerabilities by business risk.
• CISA publishes a Known Exploited Vulnerabilities catalog and recommends using it as an input when deciding which fixes come first.

If your system holds personal data, this also has a compliance angle. In the UK, the Information Commissioner's Office guide to data security says organizations must use appropriate technical and organizational measures, be able to restore access to personal data in a timely manner after an incident, and regularly test those measures. This is a high-level summary, not legal advice; ask a qualified adviser how the rules apply to you.

Patching is not a one-click job on a custom system. Each update has to be applied in a test environment, checked against your own code, and then released. That testing is a large part of what a maintenance fee buys.

Support windows: every version has an expiry date

Languages, frameworks and operating systems are supported for a fixed period. After that, security fixes stop. The dates below were checked on the official pages on October 4, 2026 and will change, so treat them as an illustration of the pattern and follow the links for current figures.

The practical lesson: a system launched today on current versions will need at least one framework upgrade and probably a language upgrade within roughly two to three years, simply to stay inside security support. That is adaptive maintenance, and it can be scheduled well ahead because the dates are published. A provider who shows you an upgrade calendar for your stack is doing the job properly. If your application is built on Laravel, our Laravel development page explains the framework in more detail.

Upgrades are cheapest when done one version at a time. Skipping several major versions and then catching up turns a routine task into a small project, because breaking changes pile up.

App stores and browsers force updates too

Mobile apps

Apple and Google both set deadlines that apply to every app, including ones that work perfectly.

• Google Play: since August 31, 2026, new apps and updates must target Android 16 (API level 36) or higher. Existing apps must target Android 15 (API level 35) or higher to stay available to new users on newer devices; apps that fall behind are only offered on older Android versions. Extensions can be requested to November 1, 2026. Internal apps restricted to one organization are exempt. See Google's target API level requirements.
• Apple App Store: Apple has stated that from April 2027, iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 27 SDK or later (Apple, Submitting). Apple also reviews old apps: those not updated within the last three years that fall below a minimal download threshold can be flagged for removal, with 90 days to submit an update, and apps that crash on launch are removed immediately (App Store Improvements).

Both requirements move forward every year, so a mobile app needs at least one planned compatibility release annually even if no features change. Your choice of technology affects how that work is done; our comparison of native, Flutter and React Native covers the maintenance tradeoffs.

Websites and web applications

Browsers update constantly. Chrome ships a major release every four weeks, and each one can retire old behavior or tighten security rules. Most releases cause no visible problems, but someone has to be watching for the one that does.

Certificates are another example. The CA/Browser Forum has approved a schedule that reduces the maximum lifetime of public TLS certificates from 398 days to 47 days in stages between March 2026 and March 2029. Sites that still renew certificates by hand will need automated renewal, or they will show security warnings to visitors when a certificate lapses.

Content management systems add their own layer. WordPress applies minor and security releases automatically on most sites, but major versions, themes and plugins still need someone to update and test them, and WordPress itself recommends a backup before updating.

Monitoring and backups: the work you never see

Preventive maintenance is invisible when it works, which makes it the first thing cut from budgets. It usually covers:

• Uptime and error monitoring, so the provider knows about a failure before your customers report it.
• Performance and capacity checks: disk space, database growth, slow pages, queue backlogs.
• Expiry tracking for domains, certificates, API keys and app store accounts.
• Backups of the database and uploaded files, kept separately from the live server.
• Restore tests. A backup that has never been restored is an assumption, not a safeguard.

CISA's ransomware guide advises keeping offline, encrypted backups of critical data and regularly testing them, because many ransomware variants look for reachable backups and delete or encrypt them. Ask your provider three questions: how often are backups taken, how long are they kept, and when was the last successful restore?

Support models compared

Maintenance is the work; the support model is how you buy it. There are three common arrangements, and many agreements combine them.

What drives the cost in any model: how complex and how old the system is, how many integrations it has, whether automated tests exist, the hours of coverage you need, how fast a response you require, and how much improvement work you want included. A system with good test coverage is cheaper to maintain because updates can be verified quickly.

If your provider is offshore, check that support hours match your working day. A team in India can cover UK business hours comfortably and US mornings with some overlap, but out-of-hours emergency cover for US time zones has to be written into the agreement, not assumed. Our guide to outsourcing software development from the US and UK covers contracts and working patterns in more depth.

What a maintenance agreement should contain

• Scope. Which systems, environments and third-party services are covered, and what is excluded.
• Included work. Whether security updates, version upgrades, monitoring and backups are part of the fee or billed separately.
• Severity levels. Written definitions (for example: system down, major function impaired, minor issue) with a response time and a target resolution time for each. Response and resolution are different promises.
• Support hours and channels. Time zone, public holidays in both countries, how to raise a ticket and how to escalate.
• Update schedule. How often dependencies are reviewed and how quickly critical security patches are applied.
• Backup terms. Frequency, retention, storage location and restore test frequency.
• Change requests. How new features are estimated and approved so they do not consume the maintenance budget unnoticed.
• Reporting. A regular summary of hours used, updates applied, incidents and upcoming end-of-life dates.
• Ownership and access. The source code repository, hosting, domain and app store accounts should be in your company's name, with the provider given access.
• Data protection and confidentiality. Terms covering any personal data the provider can reach. Have these reviewed by your own legal adviser.
• Exit. Notice period, handover obligations and documentation, so you can move to another team without starting again.

The cost of doing nothing

Skipping maintenance does not remove the cost. It moves it to a later date and makes it less predictable.

• Security exposure grows. Once a version is out of support, newly found flaws stay open. NCSC guidance notes that after support ends no security updates are published and an alternative approach is needed.
• Upgrades get harder. Each skipped version adds breaking changes, until a routine upgrade becomes a partial rebuild.
• Distribution is restricted. Mobile apps that miss store requirements lose visibility to new users or are removed.
• Integrations fail without warning. Third-party providers retire old API versions on their own timetable.
• Knowledge disappears. If nobody has touched the code for two years, the first emergency begins with someone relearning the system at emergency rates.

An illustrative scenario, not a client case: a retailer launches an online store and declines a maintenance plan. For eighteen months nothing appears wrong. Then the hosting company retires an old language version, the site throws errors after the forced upgrade, and the payment plugin turns out to be incompatible with the new version. The fix now involves upgrading the language, the framework and several plugins at once, under time pressure, with the store offline. None of those steps was avoidable. Doing them together and unplanned is what made them expensive.

For technical readers

• Keep a dependency inventory (lock files plus a software bill of materials) and run automated vulnerability scanning in CI so advisories surface without manual checking.
• Maintain a staging environment that mirrors production, and an automated test suite that covers critical paths. Without both, every patch is a risk.
• Track end-of-life dates for the runtime, framework, database and OS in one calendar, and plan upgrades a quarter ahead.
• Define recovery point and recovery time objectives with the business, then size backup frequency and restore procedures to meet them.
• Automate certificate issuance and renewal before shorter lifetimes take effect.
• Keep a runbook for deployment, rollback and incident response, stored where a new team could find it.

Frequently asked questions

What is the difference between software maintenance and support?

Maintenance is work done on the software itself: fixes, updates, upgrades and improvements. Support is the service around it: answering questions, investigating reported problems and responding to incidents within agreed times. Most agreements bundle the two, but it helps to know which one a given clause is describing.

Is maintenance the same as a warranty?

No. A warranty period, where one is offered, normally covers defects in what was delivered for a limited time after launch. It does not cover security patches for third-party components, version upgrades, app store changes or new requirements. Maintenance begins where the warranty's scope ends.

How much should I budget for software maintenance?

There is no reliable universal figure, and percentages quoted online rarely fit a specific system. The budget depends on the system's size and age, the number of integrations, test coverage, the required support hours and response times, and how much improvement work is included. Ask for a written breakdown by activity instead of a single number.

Can we handle maintenance in-house?

Yes, if you have developers who know the stack and can be available when incidents happen. Many companies split the work: internal staff handle content and first-line questions, and an external team handles updates, upgrades and escalations. Either way, one named party must own each task.

Does a simple brochure website need maintenance?

Less, but not none. It still runs on a CMS, plugins, a server and a certificate that all need updates, and it still needs backups. A light plan with scheduled updates and monitoring is usually enough.

What happens if we change maintenance providers?

The move is straightforward when you own the accounts and the code, and when documentation exists. It is difficult when the previous provider holds the hosting, domain or app store account. Check ownership now, before you need to move.

Conclusion

Maintenance and support pay for three outcomes: the system stays secure, it keeps working as the platforms around it change, and someone accountable responds when it does not. The security and compatibility work is driven by published dates you can see in advance, which means it can be planned and budgeted instead of discovered.

A sensible next step is a short audit of what you already run: list the language, framework, operating system and SDK versions in use, look up their end-of-support dates on the official pages linked above, confirm who owns each account, and ask when a backup was last restored. If you would like a second opinion on that list or on a maintenance agreement you have been offered, you can contact Entrant Technologies, which builds and maintains websites, web applications, mobile apps and custom software.