Software Maintenance: What a Maintenance Contract Should Include

A maintenance contract should settle who keeps your software up to date, secure and running. That includes security and version updates, backups with restore tests, monitoring, bug fixing, tiered response times, a quota for small changes and a regular report. Software is never finished: even when your code stands still, its environment keeps changing.

Even if a website, customer portal or app runs flawlessly today, operating systems, browsers, programming languages, libraries and connected services keep evolving. This article shows which services belong in a good maintenance contract, how to separate maintenance, support and further development, and how to tell the right scope.

Why software ages without maintenance

Modern software consists largely of third-party building blocks: frameworks, libraries, plugins and cloud services. Each of these receives updates – often because of security vulnerabilities. If you don’t apply them, you leave known weaknesses open and accumulate technical debt along the way.

• Security vulnerabilities in frameworks and plugins become public and are exploited deliberately.
• Programming languages such as PHP have fixed support periods; after that there are no more security updates.
• Operating systems and browsers change behavior and requirements – apps have to be adapted regularly.
• External interfaces of payment providers, shipping services or platforms change or are shut down.
• Legal requirements such as data protection or accessibility keep evolving.

Obligations that make maintenance necessary

Maintenance is not only a technical question but also a legal one. Three examples:

• Data protection: the GDPR requires appropriate technical and organizational measures in line with the state of the art (Art. 32). That includes closing known security vulnerabilities promptly.
• Accessibility: the German Accessibility Strengthening Act (BFSG) has applied since June 28, 2025 to certain digital products and services, such as online stores for consumers. Changes and updates must not make accessibility worse.
• Cyber Resilience Act: the EU regulation applies to manufacturers of products with digital elements, such as software and devices with software offered on the EU market. The reporting obligations for actively exploited vulnerabilities apply from September 11, 2026, the remaining obligations from December 11, 2027. Whether your product is affected depends on the individual case.

Companies that fall under the NIS2 directive also have to keep an eye on the security of their supply chain and therefore of their service providers. A maintenance contract does not replace a compliance review, but it creates the routines with which such requirements can be met on a lasting basis.

What belongs in a maintenance contract

Security and version updates

Regular updating of frameworks, libraries, plugins and the server environment – tested on a staging environment first, then applied live. Define the rhythm of feature updates and how quickly critical security updates are applied.

Backups with restore tests

A backup is only as good as its restoration. Good maintenance includes automatic backups in a separate location – following the 3-2-1 rule: three copies on two media, one of them off-site – and regular tests to confirm that a working system can actually be restored from them.

Monitoring

Availability, load times, expiring SSL certificates, storage space and error logs are monitored automatically. That way problems surface before customers notice them. If something looks off, those responsible are notified immediately – by email or in the ticketing system.

Bug fixing and response times

How are bugs reported, how quickly is there a response and what does the contract cover? Distinguish between response time (when work begins) and resolution time (when the system is running again) and agree on both, tiered by urgency. An example of such a tiering – the actual times are a matter of negotiation and depend on how important the software is:

• Critical (total outage, data loss, security incident): immediate response, outside business hours if required
• High (core function such as ordering or login impaired): response on the same business day
• Normal (bug with a workaround): response within a few business days
• Low (display glitches, wishes): handled in the next maintenance window

If you need a particular level of availability, regulate it separately as a service level agreement (SLA).

Quota for small changes

A text block, a new form field, a modified email template: a fixed block of hours makes small changes easy to plan.

Docu­menta­tion and reporting

What was updated, which incidents occurred, where is action needed? A regular report creates transparency and helps with budget planning.

Separating maintenance, support and further development

These terms are often mixed up. The following overview shows where the boundaries lie:

Area	Goal	Examples	Usually billed through
Maintenance	preserve the current state and security	updates, backups, monitoring, certificate renewal	flat fee or quota
Support	resolve questions and incidents in operation	usage help, error analysis, user management	quota or by effort
Further development	create new features	new module, new interface, redesign	a separate quote
Warranty	remedy defects from the original development	bugs that were already in the code at acceptance	the development contract, not the maintenance flat fee

A good contract states clearly what is covered by the flat fee and what is commissioned separately. The boundary with the warranty is especially important: bugs that were already in the original code generally fall under the development contract within the warranty period. Legally, maintenance contracts often mix elements of a service contract (Dienstvertrag) and a contract for work (Werkvertrag); have the structure reviewed.

Maintenance in practice: PHP update, emergencies and apps

Practical example: the PHP update

Many websites, shops and portals run on PHP. Each PHP version receives security updates only for a fixed period: PHP 8.1 reached that point at the end of 2025, and PHP 8.2 follows at the end of 2026. Updating to a new version is not a matter of pressing a button: deprecated functions in the code and in plugins have to be adapted and tested.

With ongoing maintenance this is a plannable routine step: compatibility of plugins and libraries is checked early, the switch is tested on a staging environment and applied at an agreed time. Without maintenance it often turns into an emergency – usually when the hosting provider shuts down the old version or a security vulnerability becomes known.

What can happen without maintenance

• A plugin with a known security vulnerability becomes an entry point for malicious code.
• An expired SSL certificate shows visitors a warning message that scares them off.
• A payment interface suddenly stops accepting orders after a change on the provider’s side.
• A filling-up disk or a failed backup is only noticed in an emergency.

Each of these cases costs revenue and trust – and fixing them under time pressure is almost always more expensive than preventive upkeep.

Special considera­tions for apps

For apps, store requirements come on top. Google Play requires apps to be regularly targeted at current Android versions, and Apple also requires current development tools for new versions. If you don’t maintain your app, at some point you can no longer publish updates – and in the worst case it is no longer shown to new users.

Making maintenance efficient

Good maintenance is not manual clicking through admin interfaces. Automated tests check after every update whether the most important workflows still work. A deployment pipeline applies changes reproducibly and allows a quick return to the last stable state if problems occur. And automatic alerts about vulnerable dependencies show where action is needed. That saves time and lowers the risk of every update.

How maintenance is billed

Model	Suitable if …	Advantage	Risk
Flat monthly fee	the software is business-critical and the scope of services can be clearly defined	predictable costs, fixed response times	the scope has to be described precisely
Block of hours	demand fluctuates and mostly updates and small changes come up	flexible to use	maintenance can get lost in day-to-day business
Billing by effort	the software is rarely used and not critical	you pay only when needed	no predictability, no guaranteed response

For business-critical software, a flat fee with fixed response times is usually the best choice – it makes costs predictable and ensures that maintenance does not get lost in day-to-day business.

Finding the right scope and reviewing the contract

Not every piece of software needs the same level of care. These questions help you classify yours:

• What does it cost you if the software is unavailable for a day?
• Are personal or sensitive data processed?
• How many extensions, plugins and interfaces are in use?
• How often are small changes needed?
• Is there someone in-house who can verify updates?

Checklist for your maintenance contract

• Scope of updates and test procedures described
• Backup rhythm, storage location and restore tests defined
• Monitoring with notifications agreed
• Response and resolution times set by urgency
• Quota for small changes defined
• Boundaries with further development and warranty clearly worded
• Access, documentation and rights to the code settled
• Data processing agreement in place if the provider has access to personal data
• Term, notice periods and handover on a change of provider defined
• Regular reporting agreed

How Nano Concepts can help

Maintenance is not a tedious duty but insurance for your investment. We offer software maintenance and maintenance and support for websites, shops, portals and apps, take care of web security and automate updates and deployments with DevOps and CI/CD.

Do you have software that another provider developed and nobody looks after it any more? We also take over existing projects. First we review code, server and dependencies and show you where the risks are. If a rebuild makes more sense than further development, we tell you so honestly. In the free initial consultation we clarify the scope, after which you receive a transparent quote.

This article does not replace legal advice.