Your shop takes orders, your application produces quotes and your website receives enquiries. Everything works until an update blocks a payment or an export stops running. You call your provider. Who responds? How quickly? And how much time can they spend on the issue without consulting you?
A maintenance contract that includes ongoing improvements should answer these questions before an incident occurs. The monthly hours and fee matter, but they do not fully describe the service you are buying. You also need to define responsibilities, the conditions for intervention and how the existing system can evolve.
Clarify what “maintenance” covers
The corrective maintenance service restores expected functionality: a form stops sending messages, a calculation returns an incorrect result or an import fails. You need to be able to describe the intended behaviour and reproduce the problem.
The preventive maintenance service reduces risks through updates, error checks, access reviews and backup verification. Updating a plugin without checking critical user journeys can cause an outage. The contract should include those checks, not just the installation of new versions.
The ongoing improvement work addresses new needs: adding a field, adapting an export, improving search or connecting a business tool. This requires agreement on the expected outcome and approval after delivery.
These three activities can share a budget, provided the rules are clear. Otherwise, emergencies consume the available hours and improvements are repeatedly postponed. Ask how the provider reserves time for preventive work and prioritises improvements.
Identify the components and assign responsibilities
“Website maintenance” is still vague. An online shop may depend on WordPress, WooCommerce, a custom theme, a payment platform and an email marketing service. Some components belong to the client; others are operated by third-party providers.
A short schedule should identify the domains, environments and components involved, then distinguish between those the provider maintains and those for which it only coordinates support.
| Area | What to clarify |
|---|---|
| Code, theme and plugins | Which components are covered, and what versions or known limitations apply? |
| Hosting and third-party services | Who monitors the service, opens a support ticket and follows up with the supplier? |
| Licences and subscriptions | Who owns the accounts, pays for renewals and receives alerts? |
| Small improvements | What budget or level of complexity allows them to be handled within the contract? |
| Migration or redesign | When does the work require a separate quote and approval? |
A payment service can be unavailable without the maintenance provider being able to restore it. The provider can, however, assess the impact on the shop and pass on relevant information. The contract should specify whether this coordination is included and how it is billed.
Allow for onboarding before ongoing commitments begin
A provider taking over an application does not yet know its weak points. A separate handover and assessment phase makes the subsequent commitments more realistic.
At a minimum, this phase should provide a map of the components, a list of critical user journeys, working access credentials, an overview of dependencies and a deployment procedure. Backup and restoration processes need their own checks. Existing defects should be recorded so they are not mistaken for new incidents.
This phase also establishes initial priorities: what needs securing immediately, what can wait and what requires a separate project. If your application uses Laravel, our guide to taking over maintenance of a Laravel application explains this approach.
The contract should state when service commitments begin, what prerequisites must be met and what limitations arise from the system’s initial condition.
Distinguish response, service restoration and resolution
These three time commitments refer to different outcomes:
- Response: a qualified person reviews the incident and starts investigating. An automated acknowledgement is not enough.
- Service restoration: the service becomes usable again, possibly through a workaround or a rollback to the previous version.
- Resolution: the underlying cause is fixed and the fix is verified.
A promise to “intervene within four hours” does not identify which of these outcomes is covered. The support hours, reporting channel and point at which the clock starts must also be documented. Evening or weekend on-call support requires an appropriate staffing arrangement and price.
Priority then depends on the impact on the business. The following table is an example to adapt, not a WEVE response-time commitment:
| Priority | Situation | Immediate objective |
|---|---|---|
| Critical | All payments are blocked or a core function is unavailable | Limit the impact and work towards restoring service |
| High | An important function is impaired, with no acceptable workaround | Investigate and address it as a priority |
| Routine | A limited issue with a temporary workaround | Schedule the fix |
| Improvement | A new requirement, with no failure of the existing system | Define the outcome, estimate the work and obtain approval |
Technical complexity can vary considerably within the same priority level. A reliable response time therefore does not, on its own, guarantee an equivalent resolution time.
Check what your backups actually allow you to recover
A daily backup may be adequate for a content website but insufficient for a shop taking orders throughout the day. Two questions help determine what you need: how much data could you afford to lose, and how long could you operate without the service?
The first is the maximum acceptable data loss, measured in time, known as the recovery point objective (RPO). With nightly backups, restoring the system can mean losing records created since the last backup. The second is the target time to restore service, or recovery time objective (RTO): this includes retrieving the backup, restoring it and checking the result. These concepts are explained in the Microsoft backup glossary.
These objectives should be agreed according to your business needs and available resources. They require procedures and testing, not just two figures in a contract schedule.
The contract should specify what is backed up, how often, how long backups are retained, where they are stored and who is responsible for restoring them. It should also provide for checks that restores work. For a shop, restoring an older database can remove orders even though their payments still exist with the payment provider. Reconciling those records is part of the work to plan for.
Finally, rolling back a code change does not always require restoring the entire database. The rollback procedure should distinguish between these operations.
Set out how a request progresses through to approval
For an improvement, the process can be straightforward: the client describes the need; the provider clarifies the outcome, estimates the effort and obtains approval; the change is implemented and checked before deployment. The client validates the business rules, while the provider checks the technical behaviour. A test environment should be available where the risk justifies it.
In an emergency, this process needs to be shorter. Agree in advance which actions can be taken without further approval, what budget is available and who must be notified.
Consider a hypothetical example: after an update, no payments go through. The investigation confirms the fault, and rolling back to the previous version restores purchases. The team then checks the affected orders and transactions, tests the permanent fix and deploys it. Service restoration comes before resolution here. A clear contract structures these decisions; it does not encourage anyone to declare the issue “fixed” as soon as the page works again.
Make the budget clear, including any additional charges
The fixed fee may pay for an allocation of hours, availability, defined tasks or a combination of these. Compare how the arrangement works, not just the monthly total.
Clarify whether unused time rolls over, which activities count towards the allocation and when further approval is required. Investigation, meetings, testing, deployment and documentation can account for a substantial share of the work. A fix involving a few lines of code is not necessarily a few minutes’ work.
Time records should link the work to a request and an outcome. When an improvement falls outside the agreed scope, the provider should estimate it and obtain approval before starting. Licence purchases and external services should remain separately identifiable.
Define rules for access and personal data
The provider may have access to administrator accounts, orders, forms and logs. Use individual accounts, permissions limited to what is needed and a secure way to share credentials. A copy of production data used for testing also needs appropriate safeguards.
When the provider processes personal data on your behalf, the data-processing agreement must meet the applicable requirements of Article 28 of the GDPR. The French data protection authority, CNIL, highlights the need to define responsibilities, security measures, incident management and the terms for returning or deleting data. Its guidance on managing data processors helps you identify these issues with your legal adviser or data protection officer.
Request regular reviews and plan the handover
The periodic review should explain what has changed, the time spent, recurring errors and risks still to address. It helps set the next priorities, particularly when technical debt makes small improvements more complex than expected.
WEVE’s published case studies illustrate this complexity in two ways. For an organisation’s website supported over the long term, the work covers content, search, events, forms and payment flows, in coordination with a partner agency. The contract therefore needs to identify the relevant contacts and how the affected user journeys are approved.
In an e-commerce ecosystem with private content, WordPress and WooCommerce work alongside applications, a CRM and email marketing integrations. Restricting the scope to the website alone would leave several dependencies without a clearly assigned owner.
Planning the end of the contract completes this work. Who retains the code, accounts and documentation? In what format is data returned? How much handover time is included? Changing providers should be possible without relying on a shared password or knowledge that has never been documented.
Questions to ask before signing
- Which components and user journeys are covered?
- What preventive checks are actually included?
- What does the stated time commitment mean, and which support hours apply?
- Who can authorise emergency work or additional spending?
- Have backups been restored and checked?
- How are requests estimated, tested and approved?
- How are the budget and third-party services tracked?
- What will be handed over at the end of the contract?
A useful contract makes decisions clear while everything is still working. That framework then helps you resolve incidents and improve the system with less improvisation.
Would you like to define a maintenance framework for your website or application?
