Website maintenance: what should the contract include?
Paying for hosting does not tell you who fixes the website, tests the form or restores data. A maintenance contract should make those responsibilities clear, with a scope, response times and limits the business understands.
06 chapters
List what keeps the website running
Find the components and account access
The visible website is only part of the service. It depends on the domain, hosting, code or CMS, extensions and sometimes payments, a calendar or an email service. List these components and the people who can administer them.
Separate hosting from the application
Distinguish hosting management from application maintenance. A server can respond normally while a form or shop no longer works. Ask which journeys are checked and who handles a failure caused by an external service.
Define the scope of a takeover
The website ownership guide helps locate the accounts. This step is particularly useful when taking over a site: the provider needs to know what they are taking on before promising a fixed fee.
- Domain, hosting, code or CMS and licences.
- Payments, email, calendar and other connected services.
- Important journeys: contact, purchase, sign-in and publishing.
- Account holders and authorised providers.
Separate upkeep, repairs and new features
Distinguish upkeep, fixes and changes
Preventive maintenance reduces avoidable problems through updates, checks and backup verification. Corrective maintenance fixes a defect. Development adds or changes a use: a new form, section or integration does not automatically belong in the same package.
Classify each request
The contract should say how each request is classified. A text change may be included, charged by time spent or left to a team trained to use the administration panel. Any of these choices is acceptable if made explicit before the first request.
Plan for unsupported components
Also ask how unsupported technologies and abandoned extensions will be handled. Maintaining a website does not always allow every component to be kept indefinitely. Technical remediation may require a separate project, with a quote and acceptance checks.
Check what happens after an update
Check key journeys after the work
A list of up-to-date versions is not an acceptance test of the website. After an intervention, essential uses need checking: signing in, sending an enquiry, publishing and placing an order if there is a shop. The level of testing depends on the site and should be included in the scope.
Prepare a rollback
Before a significant change, keep a recoverable version and prepare a rollback. On an active online shop, restoring an old database can erase recent orders. The strategy needs to distinguish code, files and data created during the intervention.
Announce and document the intervention
Agree a maintenance window when the change could interrupt the service. A short report should state what changed, which checks were performed and what remains to be addressed. The business does not need every technical command to understand the website’s condition.
Ask for a tested restoration, not just a backup
Specify what the copies contain
A backup can exist but be unusable: a missing database, incomplete files, lost access or an unreadable format. The contract should specify what is backed up, how often, for how long and where the copies are kept.
Test a restoration separately
- A useful test restores the backup in a separate environment, then opens the pages and features you need.
- Record the date, the components restored and the result.
- This check must not risk overwriting the live website.
Set acceptable data loss and downtime
Define two needs with the business: how much data it can accept losing and how long the service can remain unavailable. A rarely updated catalogue and a shop receiving orders call for different arrangements.
Copy, protect and test
The CNIL recommends regular, protected backups checked through restoration tests.
- Copies
Separate from the service
Avoid one incident affecting the website and all its copies.
- Protection
Controlled access
Backed-up data still needs protection.
- Test
Verified recovery
Check integrity and the ability to restore the service.
Distinguish a response from a return to normal service
Clarify what the promised time means
- “Intervention within four hours” may mean acknowledging the alert, starting a diagnosis or restoring the service.
- Ask which one.
- Also specify the covered hours, alert channel and what counts as an emergency.
Set priorities by impact
A misaligned secondary page, an unavailable form and blocked payments have different impacts. The contract can set different priorities. It should state who informs the business, who contacts the host and how decisions are approved.
Plan who informs whom
When an incident involves personal data, responsibilities go beyond simply restarting the service. The provider and the business need to know their obligations and how information will be passed on. Infrastructure and security should be scoped around these uses, not server capacity alone.
Identify the provider and the reporting process
The CNIL calls for defined data-processing arrangements, including incident management and the end of the service.
- Incident
Who notifies whom?
Describe the channel and responsibilities for keeping people informed.
- Exit
What happens to the data?
Plan its return and the handling of remaining copies.
Read the budget alongside exclusions and exit terms
Compare the same scope
Compare packages with the same scope: journey checks, response times, backups, restoration and included hours. Separate hosting charges, licences, new features and out-of-hours work. A monthly price alone does not let you make this comparison.
Example: the limits of a fixed fee
In a fictional example, a package might cover updates and monthly checks while excluding a new page. The business needs to know how that request will be estimated and approved before it is carried out. Do not assume a higher fee covers more: read the tasks included.
Prepare a change of provider
The end of the contract should allow an orderly takeover: accounts, code according to the agreed rights, exports, documentation and a transfer schedule. The quote review guide complements this review. Have access and a restoration checked before removing the previous provider’s permissions.
- Clearly named included tasks and exclusions.
- Covered hours and the exact meaning of promised times.
- Pricing and approval for additional requests.
- Accounts, data and documents handed over on exit.
The remaining decisions
Does hosting include website maintenance?
That depends on the contract. Hosting provides an environment to run the website; it does not automatically cover website updates, form repairs or journey tests.
Is a daily backup enough?
The frequency should match the data being created. You also need to check the content, protection, retention and restoration of the copy. A high frequency does not fix an incomplete backup.
Should text changes be included?
They can be, or the business can make them in its administration panel. The contract should state that choice and the cost of requests outside the scope.
How do I take over a website from another provider?
Start with an inventory of accounts, components and rights. Check a backup and a usable export, then organise the transfer and tests before revoking the old access.
Put the guide against a real project.
A few lines are enough: context, the main constraint, and the expected result.