Software maintenance and support: what it includes and how to plan for it

Software maintenance and support is the work that keeps a live system secure, working and useful after it launches. Maintenance means changing the software: fixing defects, applying security and dependency updates, adapting to new operating systems, browsers and third-party APIs, and making improvements. Support means helping the people who use it: answering questions, handling incidents and keeping the service running within agreed response times. Most products need both for as long as they are in use.

Launch is not the end of a software project; it is the start of its longest phase. Yet maintenance is the part buyers plan least, and it is often sold as a vague monthly retainer with no clear scope. This guide explains the types of maintenance, why software needs it even when nobody is asking for changes, what a good support service and service level agreement (SLA) look like, how to estimate the effort in hours and team shape, and how to take over maintenance of software someone else built.

Maintenance, support and evolution: three different jobs

These words are used loosely, which causes most of the disappointment in maintenance contracts. It helps to separate them before you agree on anything.

• Support is reactive and people-facing: someone answers when users or your team report a problem, triages it, communicates, and makes sure it reaches the right engineer. It is measured in response times and availability.
• Maintenance is engineering work that keeps the existing software healthy: fixing bugs, patching vulnerabilities, upgrading frameworks and runtimes, keeping up with platform rules, monitoring, backups and small improvements. It is measured in system health and how quickly problems are fixed.
• Evolution is new development: features, integrations and redesigns that change what the product does. It is measured like any development work, by the value delivered.

A contract that says 'maintenance' but means 'we'll fix bugs if you report them' leaves your dependencies to rot. A contract that bundles evolution into a fixed maintenance fee usually ends with either the vendor or the client feeling short-changed. Name each part and decide how each is paid for.

The four types of software maintenance

Software engineering standards have classified maintenance work for decades, and the categories are still the clearest way to plan it. The international maintenance standard, now ISO/IEC/IEEE 14764:2022, and its earlier editions describe four classic types:

Corrective work is what most people picture, but in a healthy product it is the smallest share. Adaptive and preventive work are what keep corrective work small. A maintenance plan that only budgets for fixing bugs is planning to have more of them.

Why software needs maintenance even when nobody changes it

Software does not wear out, but the world around it moves. The computer scientist Meir Lehman described this decades ago as the law of continuing change: software used in the real world must keep being adapted, or it becomes steadily less useful. Today the forces are concrete and often come with dates attached.

• App store rules. Since 28 April 2026, Apple requires apps uploaded to App Store Connect to be built with Xcode 26 or later using the iOS 26 family of SDKs. From 31 August 2026, Google Play requires new apps and updates to target Android 16 (API level 36), and existing apps that fall too far behind become unavailable to new users on newer devices. A mobile app nobody touches for a year can lose the ability to ship even an urgent fix.
• Runtimes and frameworks reach end of life. Node.js, for example, gives its long-term support releases roughly 30 months of critical fixes, and is moving to a yearly release cycle. Languages, frameworks, databases and operating systems all have similar clocks. Running past end of life means no more security patches.
• Dependencies get vulnerabilities. A typical web application often pulls in hundreds of open-source packages. New vulnerabilities are published in them every week, and some are actively exploited soon after disclosure.
• Third parties change. Payment providers, mapping services, email platforms, identity providers and AI model APIs deprecate versions, change pricing and retire endpoints, usually with a few months' notice.
• Browsers and devices change. New screen sizes, privacy restrictions, cookie rules and security defaults can break features that worked last year.
• Certificates, domains and keys expire. A forgotten certificate or API key renewal can take a service offline on a precise date.
• Data grows. A query that was instant with ten thousand records can time out with ten million. Storage fills, backups take longer, costs climb.
• Rules change. Data protection, accessibility and sector regulation evolve, and so do your customers' security questionnaires.

Unmaintained software does not stay the same. It gets quietly older every month until one day a small change becomes a large project.

What a maintenance and support service should include

Scope varies with the product, but a complete service covers these areas. When comparing proposals, check each one off and ask who does it and how often.

• Monitoring and alerting: uptime checks, error tracking, performance and resource monitoring, with alerts that reach a person who can act.
• Incident handling: a clear way to report problems, triage by severity, communication while a fix is in progress, and a short written review after serious incidents.
• Bug fixing: reproducing, fixing, testing and releasing corrections, with regression tests so the same bug does not return.
• Security maintenance: regular dependency and operating system updates, urgent patching when an actively exploited vulnerability appears, and periodic checks of access and configuration.
• Platform and dependency upgrades: planned upgrades of frameworks, runtimes, databases and mobile SDKs before they reach end of life or a store deadline.
• Backups and recovery: automated backups, and restores that are actually tested on a schedule.
• Infrastructure and cost care: right-sizing, renewing certificates and domains, keeping infrastructure code current, watching the cloud bill.
• Small improvements: a budget for minor changes and performance work, so small requests do not wait for a project.
• Documentation: keeping runbooks, architecture notes and the change log current, so knowledge does not live in one person's head.
• Reporting: a regular, plain-language summary of incidents, fixes, updates, risks on the horizon and recommended next steps.

Service level agreements: what to put in writing

An SLA turns 'we'll look after it' into commitments you can check. The most important part is a shared definition of severity, because response targets mean nothing if the two sides disagree about what counts as urgent. Here is an example structure; the right targets depend on your business and what you are willing to pay for out-of-hours cover.

Beyond the table, a good SLA defines:

• Response versus resolution. Response means a qualified person has acknowledged and started work. Resolution means the problem is fixed or worked around. Many vendors commit only to response; know which you are buying.
• Support hours and time zones. Business hours where, and what is covered at night, at weekends and on public holidays in each relevant country.
• Channels. How to report (a ticket system, email, a phone line for critical issues) and who on your side is allowed to raise critical incidents.
• Availability targets for the hosted service, if the provider runs your infrastructure, with clear exclusions for planned maintenance and for outages in third-party services.
• What is in and out of scope, including how small improvements and new features are requested, estimated and approved.
• Reporting and review: monthly reports and a regular review meeting to adjust priorities.
• Exit terms: how code, credentials, documentation and knowledge are handed over if either side ends the arrangement.

Support models compared

How you pay matters too. Fixed monthly fees suit well-defined maintenance; time and materials suits unpredictable change. Our article on fixed price versus time and materials explains the trade-offs.

How to estimate maintenance effort

Maintenance effort is driven less by the size of the original build than by these factors:

• Number of platforms. A web app, an iOS app, an Android app and an admin panel are four things to keep current, each with its own release cycle.
• Number of dependencies and integrations. Every third-party API and framework is a source of future change.
• Code quality and test coverage. With good automated tests, an upgrade can be verified in hours. Without them, every change needs careful manual checking.
• Age of the stack. Software that is several major versions behind needs catch-up work before routine maintenance becomes routine.
• Criticality and support hours. Round-the-clock cover for a critical system needs a rota of people, not one engineer.
• Rate of business change. A product whose rules, prices or regulations change often needs more adaptive work.
• Usage and data growth. More users find more edge cases; more data exposes slow queries.

These worked examples show how estimates are built. They are illustrations, not quotes, and they assume software in reasonable health.

Example 1: an internal web tool. A single web application with a database, used by one department during business hours, few integrations, decent tests. Monitoring, monthly dependency updates, occasional bug fixes and a quarterly check on backups and access might need in the region of one to two engineer-days a month, handled by one engineer who knows the system, with response targets in business hours only.

Example 2: a customer-facing product with mobile apps. A web app, iOS and Android apps, an API, payments, push notifications and five or six integrations, with customers who expect it to work at weekends. Expect a steady load of dependency and security updates across three codebases, at least one significant mobile platform upgrade a year to meet store deadlines, regular small fixes, and someone reachable for critical incidents out of hours. That typically means a small team sharing the work (for example a lead engineer and a mobile engineer, with infrastructure help as needed), in the order of several engineer-days a month for maintenance alone, before any new features.

If you are budgeting for a new build, plan its maintenance at the same time; our software cost calculator helps you size the build itself.

Taking over software someone else built

Many maintenance engagements start with a handover: the original developer has left, the agency relationship ended, or the internal team moved on. The first weeks decide whether the new arrangement works. Before committing to response times, a responsible provider will want to understand what it is taking on, and you should want that too. A short software audit is the usual starting point.

Gather the following before or during the handover:

1. Ownership and admin access to every source code repository, cloud account, domain, DNS provider, app store account, email service and third-party API. Confirm these are registered to your company, not to a person or the previous vendor.
2. Credentials and secrets, rotated after the handover so former suppliers no longer have access.
3. Instructions to build, test and deploy the system, and proof that someone new can actually follow them.
4. Architecture notes: components, data flows, integrations and where data is stored.
5. A list of known bugs, workarounds, scheduled jobs and anything done manually on a regular basis.
6. The state of dependencies and runtimes: what is out of date, what is close to end of life, and any upcoming platform deadlines.
7. Backups: where they are, how often they run, and when a restore was last tested.
8. Licences and contracts for third-party services, with renewal dates.

The audit should end with a plain list of risks and a stabilisation plan: urgent security updates, missing monitoring, untested backups, the upgrades needed before routine maintenance can start. Expect this catch-up work to be scoped separately from the ongoing monthly service.

When maintenance is no longer enough

At some point, maintaining a system costs more, or risks more, than changing it. Signs you are there:

• Small changes regularly take weeks and break unrelated features.
• The framework, language version or database is out of support, and upgrading means rewriting large parts.
• Only one person understands the system, and they are leaving or already gone.
• Security patches can no longer be applied because the stack is too old.
• The business has changed so much that the software's design fights every new requirement.
• Hosting or licence costs keep rising for a system nobody wants to touch.

That does not automatically mean a rewrite. Incremental modernisation (upgrading in steps, replacing one module at a time, wrapping old parts behind clean interfaces) is usually safer. Sometimes the honest answer is to replace a custom system with an off-the-shelf product. Our legacy software modernisation guide covers the options in detail.

Good maintenance practice: what to expect from a provider

You do not need to be technical to tell whether maintenance is being done well. Ask to see these:

• Automated tests and a delivery pipeline, so fixes and updates can be released quickly and safely. Our DevOps services guide explains what a sensible setup looks like.
• A regular update rhythm, for example monthly for routine dependency updates and immediately for actively exploited vulnerabilities, with automated pull requests from tools such as Dependabot or Renovate.
• A forward calendar of known deadlines: runtime end-of-life dates, app store requirements, certificate renewals, contract renewals.
• Error tracking and monitoring that the provider actually looks at, with evidence in the monthly report.
• Restore tests of backups on a schedule, with the date of the last successful one.
• Written incident reviews for serious problems, focused on fixes rather than blame.
• Up-to-date documentation that would let another competent team take over.

The last point is the real test. A provider confident in its work makes itself replaceable.

How to choose a maintenance and support partner

1. Who will actually work on our system, and will the same people stay with it over time?
2. How do you get to know a system before you commit to response times?
3. What exactly is included in the monthly service, and how are improvements and new features handled?
4. What are the response and resolution targets per severity, and what is covered outside business hours?
5. How do you handle security updates and urgent vulnerabilities?
6. What will your monthly report show us?
7. Will all accounts, code and documentation stay ours, and what happens at the end of the contract?

Prefer partners who ask hard questions about your system before quoting. A fixed monthly price offered without looking at the code is a guess, and one side will pay for it later.

How Authect approaches maintenance and support

Support and evolution is one of Authect's three ways of working, alongside fixed-price projects and monthly sprints. As a founder-led studio, you talk to the founders who work on your software, never a salesperson, and a senior engineer leads every engagement, so the person who answers an urgent call understands the system.

For software we did not build, we start with an audit and a stabilisation plan before committing to response times. From there we keep dependencies, platforms and infrastructure current, watch errors and performance, test backups, and report in plain language each month. Our delivery is AI-accelerated, with an engineer reviewing every line, which helps with repetitive upgrade work without lowering the bar. You own the code, infrastructure and documentation from day one, with no lock-in, and we keep the documentation good enough that another team could take over. Our team works from Dubai and Spain, with partners in Lithuania, for clients across Europe, the Middle East and beyond. Read more about our support service or tell us about your system.