What Website Maintenance Actually Covers: Contract Models, SLAs, and Handover
The day a website goes live is not the end of the project. It is the beginning of a different kind of spending.
Most business owners read a build contract carefully and then skim straight past the word “maintenance” — until the day the site will not load, or an unexpected invoice arrives, and the question finally gets asked: what exactly did this buy? This article is not about numbers. It is about what maintenance actually consists of, what these contracts usually look like, and what to settle before you sign one.
What the maintenance fee is really buying
“Website maintenance” is a loose term covering at least seven kinds of work that have almost nothing in common with one another.
Hosting and the domain name. The domain is your address, it renews annually, and letting it lapse makes the site disappear outright. Hosting or cloud services are where the files and data live, billed according to specification and traffic. Both behave like rent: they continue whether or not you ever update a word of content.
SSL certificates. The certificate that puts the padlock in the address bar and encrypts data in transit. Most cloud plans include one and renew it automatically, but confirm who owns that renewal.
Backups. Copying the site files and database on a schedule. The question is not whether backups exist but how often they run, how many versions are kept, and whether a restore has ever actually been rehearsed. A backup nobody has restored from is not a backup.
Package and system updates. The framework, plugins, and libraries underneath the site keep releasing new versions. Leaving them untouched for long periods means leaving publicly documented vulnerabilities sitting at your front door.
Security remediation. The active work beyond routine updates: urgent patching after a vulnerability is disclosed, blocking abnormal traffic, and cleaning up and recovering after a compromise.
Content updates. Rewriting copy, swapping images, adding products, publishing announcements. This is the category both sides most often assume the other party is handling.
Emergency response. The site is down, payments have stopped working, the contact form is not delivering. The value here is not in the hours worked but in somebody picking up the phone when it matters.
Laid out side by side, the billing logic behind these is clearly not the same: the first three behave like fixed costs, the middle two are technical labor, and the last two depend entirely on how much you use them. A contract that says only “maintenance, one lot” has merged seven separate things into a single number nobody can interpret.
Where the one-time build cost ends and recurring cost begins
Almost every dispute happens along this line, and the principle for drawing it fits in one sentence: keeping the website the way it was at acceptance is maintenance; making the website into something it never was is a new project.
Follow that through. Fixing a feature that was always supposed to work and has stopped working falls under warranty or maintenance. Swapping text and images normally sits inside the content update allowance. But adding a page type that did not previously exist, connecting a new external service, or changing a business process is new development work.
What actually needs writing into the contract is the gray area in between: whether rearranging the layout of an existing page counts, how the monthly allowance is measured (by number of requests, by hours, or by items), whether unused allowance rolls over, and how anything beyond it is priced. Settle those once and you will not be renegotiating every time. For a full breakdown of the cost structure underneath a build, see how website costs are calculated.
Three common maintenance contract models
Monthly or annual retainer. A fixed payment in exchange for an agreed scope of service and a set allowance for adjustments. The advantages are a predictable budget and a vendor with a real incentive to keep the system stable; the drawback is that in months with few requests it can feel like paying for nothing. This suits businesses whose website carries real operational load, or whose content needs updating on a regular cycle. NETVANA’s software development process treats maintenance as its fifth phase, offered as a monthly technical support plan covering performance monitoring, scheduled backups, and security updates.
Per-request billing. You raise a ticket when you need something, and it is settled by hours or by item. The advantage is no standing cost; the drawback is that nobody is proactively watching your system, security updates are routinely missed, and there is no guarantee anyone is available in an emergency. This suits sites that are purely presentational, rarely updated, and have basic operational upkeep covered some other way.
Hybrid. Core operations — hosting, backups, security updates, monitoring — on a retainer, with content and functional changes billed separately by item or by hour. In practice this is the most common model and the easiest one in which to state responsibility clearly.
The deciding question is not which is cheapest. It is: if the site were down for a day, what would that cost the business? Where the answer is obviously significant, core operational upkeep does not belong on per-request billing.
The three things to check in an SLA
An SLA is a service level agreement, and its purpose is to translate “we will deal with it as soon as we can” into something you can hold up and check.
One: response time, tiered. A site that is entirely unreachable, or payments that have stopped processing, should not share a deadline with “I would like to change this photo”. At minimum the contract should separate emergencies from ordinary requests and state a response time for each. Note that response time is not resolution time; most contracts commit to the former, which is reasonable, but you should know the difference.
Two: service hours. Business hours on working days, or holidays included? E-commerce sites are most likely to have incidents during long holiday trading periods, so if your revenue concentrates into particular windows, negotiate this clause specifically.
Three: availability and resilience. Backup frequency, number of retained copies, how long a restore takes, and whether there is a staging environment where changes can be verified before going live. A high availability figure usually comes with a correspondingly expensive architecture; what matters is whether the number is backed by real redundancy, not how impressive it looks on paper.
One more question worth asking: what is the reporting channel? A single named contact reachable only through a personal messaging app goes offline the moment that person takes leave.
What happens when there is no maintenance agreement
Nothing breaks immediately, and that is exactly the danger. The typical sequence runs like this.
The first six months are fine, because the system is still new. Then security update notices start appearing for the packages, and nobody acts on them. Some time after that, the domain or the certificate expires with no reminder reaching anyone. One day the site shows an error, or the browser flags it as insecure, and you go back to the original vendor — only to find their team has been allocated to other projects, or that you cannot reach them at all.
At that point the cost is not just the repair. It is that somebody has to understand the system first. Taking over a site with no documentation and no maintenance history nearly always means spending extra time up front on a technical audit. The same logic applies to larger systems, where a more severe version of this becomes a legacy system modernization question.
What you should get back when you change vendors
Starting the handover conversation at the moment you decide to leave is the point of least leverage. The correct approach is to write the delivery list into the original development contract, covering at least:
- Registrar account access or transfer authorization for the domain name
- Accounts and administrative access for hosting and cloud services
- Complete source code and a database backup
- Deployment and environment configuration documentation (this is what lets a new vendor rebuild the environment)
- Original design files
- Third-party service accounts: payments, email marketing, analytics, maps, support tools
- A list of the current scheduled jobs and monitoring configuration
NETVANA’s practice is that once the project fee is settled, the source code, design files, and documentation are transferred in full; the maintenance relationship and the ownership of the code are two separate matters. This is worth confirming when you evaluate any vendor, and there is a fuller method for doing so in how to choose a software development company.
There is one more thing that regularly gets overlooked during a handover: do not let the switchover day be the first time anybody tests the new environment. The sensible rhythm is for the incoming vendor to rebuild the site completely in a staging environment, compare it against the original, and only then point the domain across — which protects your search rankings and existing links. The steps involved are covered in the website redesign SEO checklist.
The recurring arguments: is this maintenance or not?
The following situations arise in almost every contract, and stating the position in advance stops them becoming disputes.
“The site was hacked — is fixing it extra?” It depends on the cause. If the compromise followed from the vendor not applying the security updates they were contracted to apply, it normally falls within maintenance. If credentials on your side were leaked, or someone installed a plugin outside the agreed scope, responsibility sits differently. The contract should state which layers of security work maintenance actually covers.
“What if I break something myself?” If you have admin editing rights, you have the ability to break things. The reasonable arrangement is that a restore service is available but billed separately, with a backup frequency sufficient to support it.
“What if a third-party service raises its prices or shuts down?” The pricing and specifications of payment gateways, mapping services, and email platforms are outside the vendor’s control. What the contract needs to handle is who evaluates the alternatives when it happens, and how the hours for switching are accounted for.
“Does a slow website count as a fault?” Put measurable performance indicators into the monitoring scope and agree the procedure for when they fall outside range, rather than opening the discussion only after somebody complains.
“Can I use the allowance to add a new page?” This is the single most common gray area. Writing the boundary between “content update” and “new page type” as concrete examples works far better than writing an abstract definition.
Checklist before signing a maintenance contract
- Which of the seven work types are included and which are not, listed item by item
- The unit used to measure the monthly allowance, and whether it rolls over
- The definition of emergency versus ordinary issues, and the response time for each
- Whether service hours cover holidays
- Backup frequency, retained copies, and restore rehearsals
- Monitoring scope and notification method (who finds out first that the site is down)
- The content and frequency of regular reporting
- The handover procedure and deadline on termination
- Ownership of accounts and source code (unchanged by the end of the maintenance relationship)
The above is a summary of general principles; have a lawyer confirm the actual wording.
Maintenance fees make people uncomfortable, and usually not because of the amount. It is because it is hard to see what the money bought. Once the seven categories are separated out, responsibility is written down, and the SLA carries specific conditions, the expense stops being an unexplained monthly charge and becomes a piece of risk management you can evaluate.
If you are reviewing a maintenance contract you already hold, or preparing to hand a website over to a new partner, talk to NETVANA about what you need. Software services are quoted after a consultation rather than sold as fixed packages; for what each service includes and delivers, see the software services overview.
Further reading: for the cost structure during the build phase, see how website costs are calculated. If you are changing vendors or redesigning, see the website redesign SEO checklist. And for what to watch when systems need to talk to one another, see the guide to system integration and API development. For how your hosting choice changes the maintenance scope, see How to Choose Web Hosting; and for where the maintenance contract draws the security line, see Website Security Basics for Businesses. For the ongoing cost each extra language adds, see The Multilingual Website Development Guide; and for the signals that maintenance is no longer enough, see How a Website Redesign Actually Runs. Once the maintenance contract is set, here is how to report an issue when one comes up; see How to Report Bugs to Your Vendor. To check whether your contract actually spells out backup terms, see Website Backup and Disaster Recovery.
