Website Maintenance: What an Application Maintenance Contract Must Include to Stay Secure and Fast

Website maintenance: what should a TMA contract cover?

A TMA contract (third-party application maintenance) should cover security updates, tested backups, performance monitoring, bug fixes, a defined volume of enhancements, and written response times. Without these six points, maintenance remains a vague promise.

Why maintenance should be defined in writing

Without a framework, every incident becomes a negotiation. Who steps in? How quickly? At what cost? A website maintenance contract answers these questions before the outage, not during it.

What TMA protects

• Security: an unpatched vulnerability exposes your data and your customers' data.
• Availability: an offline site means lost sales or lost enquiries.
• Conversion: a slow or buggy site drives visitors away before they take the action you want.

How to structure the contract

We follow a simple logic: the technical foundation (updates, backups), monitoring (supervision, reporting), scope (corrective and evolutive work), commitments (SLAs), and exit clauses (code ownership, reversibility). The following sections go through each block in detail.

Security updates and patches: the foundation of the contract

The contract must list what the provider keeps up to date: framework, dependencies, CMS, plugins and server. Each area has its own frequency, set out in black and white.

• Routine updates: a regular cycle (monthly or quarterly depending on the project), batched together to limit risk.
• Critical patches: handled outside the cycle, as soon as a vulnerability is published.

No update goes straight to production. The provider first applies it to a test environment that closely mirrors production, then runs checks: key user journeys, forms, payment.

If a test fails, the release waits. If something goes wrong after deployment, a rollback must be possible. Require this procedure in the contract.

Backups and a tested recovery plan

A backup that can't be restored protects nothing. The contract should therefore set out four points:

• Frequency: daily for the database, adjusted to the pace of orders or content updates.
• Retention: a stated duration, with several possible restore points.
• Storage: a location separate from the main hosting.
• Restore tests: carried out at regular intervals, with a report and a measured recovery time.

Without these tests, you discover the limits of your backups on the day of the incident.

Monitoring and performance: what should be measured

Monitoring turns performance into usable data. Four indicators are enough to get started:

• Availability: does the site respond at any hour?
• Response time: does the server respond quickly, including at peak times?
• Application errors: which pages or actions fail?
• Core Web Vitals: loading, responsiveness and visual stability, as experienced by the user.

A slow page makes visitors give up before the form or the payment. That's lost conversion.

Every threshold must trigger an action: an alert, a ticket, a named owner, a response time. Without that, the alert is just noise.

Corrective and evolutive maintenance: defining the scope

The scope is defined in three categories.

• Corrective: fixing behavior that no longer meets the specification (a bug, a payment error). It is included.
• Evolutive maintenance: adjusting what already exists (a new field, an improved user journey). It draws on a volume of included hours.
• New development: a brand-new feature. It is quoted separately.

Set a monthly volume of hours, then prioritize the backlog together each month. Also include a written rule: any overrun is estimated and approved before work begins.

SLA: what response and resolution times should you require?

An SLA sets two time limits for each severity level: response (acknowledgment and the start of analysis) and resolution (a fix or a workaround).

• Blocking: site or payment is down. Fastest response, immediate intervention.
• Major: a key function is degraded. Response within a few business hours.
• Minor: a defect with no business impact. Handled according to the schedule.

Also require the hours covered, the channels (ticket, phone for blocking issues) and the definition of each level.

Limitation: an SLA commits to time limits, not to the absence of incidents.

Budget and reporting: managing TMA in a measurable way

Two models dominate TMA budgeting. A monthly flat fee gives predictable spending, but it may go underused. A bank of hours follows actual usage, but requires rigorous tracking.

In both cases, require a monthly report:

• tickets resolved and pending;
• incidents and resolution times;
• updates carried out;
• performance indicators.

This report makes spending measurable.

Code ownership and reversibility: staying in control

Before signing, check five points:

• Code ownership: it belongs to you, deliverables included.
• Access to the repository, in your name, from day one.
• Up-to-date documentation: installation, deployment, access.
• A defined exit notice period.
• Reversibility: transfer to another provider, with a handover period.

Without these clauses, you depend on your provider.