After Go-Live: What Your Support Contract Must Cover

The project has been delivered. The business platform is live. The closeout meeting is done. This is the exact moment when the procurement director must open a new file, because what was budgeted and built only covers the delivery. What comes next (bug fixes, adaptations, enhancements) depends on a support contract that must be negotiated before the first incident reminds you of its absence.

No software is ever finished. A web platform managing procurement, supplier workflows, or service delivery tracking will continue to evolve under three types of pressure: bugs that emerge in real-world usage, business adaptation requests, and security updates. Without a support contract, every ticket becomes a commercial negotiation. With a poorly written contract, the invoice arrives anyway, simply disguised as "enhancement".

This article details the six contractual clauses a buyer must demand in an application maintenance contract, and the exact mechanics of service commitments (SLA, penalties, billing boundaries) that must be read before signing.

What the warranty covers after go-live, and until which date

The warranty is the only period when all bug fixes are included in the project package. It starts at final acceptance (or at go-live if acceptance is merged with production deployment) and typically runs between three and twelve months. After this date, any bug fix falls under the maintenance contract, therefore under a paid annual subscription.

Three timelines matter:

1. The legal warranty period: under French law, this is two years from delivery for hidden defects. Some contracts attempt to reduce this period by clause; a corporate legal counsel must validate compliance.
2. The contractual warranty period: the one written in the project contract, typically six or twelve months, during which the vendor or integrator commits to fixing any bug without additional billing.
3. The reporting deadline: some vendors require that any bug be reported during the warranty to be fixed for free, even if the fix is delivered later. A bug discovered the following month becomes billable. This clause must be identified and negotiated from project signature.

A procurement director must therefore mark the warranty end date in the calendar, because after this date, without an active support contract, a simple blocking bug may require an ad-hoc purchase order, with commercial delays that add weeks to the fix timeline.

The bug-vs-feature boundary: where post-project budgets leak

Post-project IT budgets almost always disappear at the same place: the boundary between what qualifies as a bug fix (included in the support contract) and what qualifies as an enhancement (billed as time-and-materials or additional fixed-price). This line is legally defined in the maintenance contract, but commercially interpreted at every ticket.

Standard definition of bug fix: any deviation between the current behavior of the platform and what was specified and validated during acceptance. If the supplier invoice validation feature requires three approval levels and the platform allows two, it's a bug. If it works as specified, but you want to add a fourth level, it's an enhancement.

Standard definition of enhancement: any functional change that goes beyond the initial scope, even if it seems minor to you. This includes new features, business process adaptations, integrations with new third-party systems, and any interface redesign request.

The commercial trap is simple: each vendor classifies its own tickets. If you request a fix and they respond "it's an enhancement", you'll need to prove that the initial specification covered this point. The three levers to frame this boundary:

1. A strict contractual definition: instead of the generic clause above, write that "any behavior non-compliant with specifications validated during project acceptance constitutes a bug fix", and attach to the support contract the latest version of signed specifications. Without this reference, everything is negotiable.
2. A classification committee: some contracts provide that in case of disagreement on the nature of a ticket (bug or enhancement), a joint committee (one client representative, one vendor representative, and possibly an independent business expert) meets within 72 hours to decide. This avoids unilateral blocking.
3. An arbitration log: require that any reclassification decision (bug reclassified as enhancement) be notified in writing with justification. This creates an audit trail useful during budget reviews and allows spotting vendors who use reclassification as a commercial lever.

In practice, this boundary is the exact place where maintenance budgets explode. An IT director who thought they had contracted 20,000 euros annually of support ends up at 45,000 euros because half the tickets were reclassified as billable enhancements.

Reading a severity grid: acknowledgment time versus restoration time

A support contract always mentions an SLA (Service Level Agreement), but you must distinguish two different commitments, often deliberately confused:

• Acknowledgment time: the maximum time between ticket declaration and the first support response (acknowledgment receipt, qualification, assignment).
• Restoration time: the maximum time between declaration and delivery of a functional fix or a workaround validated by the client.

Most contracts only commit to the first. Here's a standard grid for an 18,000 euro annual support subscription:

Three traps to identify before signing:

1. Severity is unilaterally decided by the vendor. Require that classification be jointly validated within 30 minutes for S1, one hour for S2. Otherwise, a bug blocking your procurement processes can be reclassified as S3 by support and handled three weeks later.
2. Restoration time for S3 and S4 is empty. The phrase "next minor version" means: we'll fix it when we decide. Negotiate a calendar commitment (for example: 30 business days maximum for S3).
3. SLA application hours are limited to business hours. A ticket declared Friday at 5:30 PM is only acknowledged Monday morning at 9 AM. If your platform runs continuously (case of a just-in-time supplier order management platform), the support contract must include 24/7 on-call for S1 and S2.

What a buyer must demand: a severity grid where the client validates classification, and a quantified restoration commitment for all severities, including S3.

When the clock starts, and which exclusions suspend it

An SLA is only useful if the clock starts at the right time and cannot be arbitrarily stopped. Two negotiation areas:

SLA starting point

Does the contractual delay start when you send the email to support, or when the vendor validates that your ticket is admissible? Some contracts write that "SLA starts once the ticket is qualified as compliant with reporting requirements". This means that if your ticket doesn't contain the required screenshots, the clock never starts, even if the bug is obvious.

What to negotiate: SLA starts upon ticket receipt by support, regardless of its initial completeness. If the ticket is incomplete, support can request additional information, but the clock continues. This avoids delaying tactics where each request for complement resets the counter to zero.

Exclusions that suspend SLA

All contracts provide legitimate exclusions (natural disaster, strike, third-party hosting outage). The problem arises with extensible exclusions:

• "Awaiting client information": if support asks you for additional logs, SLA is suspended until your response. Some vendors use this clause to ask a question every 48 hours and maintain the ticket in perpetual waiting. Negotiate a maximum suspension time (for example: SLA can be suspended 72 hours maximum per information request, then automatically resumes).
• "Bug in third-party component": if the incident comes from an external module (CRM, ERP, banking API), SLA doesn't apply. This clause is legitimate, but must be framed: the vendor remains responsible for escalation to the third party, and the client must be informed within 24 hours if the incident falls outside contractual scope.
• "Non-compliant environment": if your infrastructure (servers, databases, network) doesn't meet the vendor's technical specifications, SLA is void. This covers legitimate cases (you installed an unsupported firewall), but some contracts expand this clause to include any configuration not validated in writing. Require a closed list of technical prerequisites, and that any deviation be notified before SLA suspension.

A well-written contract must state that "any SLA suspension must be notified in writing to the client within 12 hours, with justification and expected clock resumption date".

What happens in case of breach: penalty, credit, escalation, or nothing

An SLA without penalty mechanism is a commercial promise, not a contractual commitment. Yet, most support contracts provide no consequence in case of overrun. Three models exist:

Model 1: Automatic financial penalty

The contract provides that in case of SLA overrun, a penalty is applied, calculated either as percentage of monthly subscription, or as fixed amount per hour of delay. Example:

• S1 exceeded by 2 hours: penalty of 500 euros per hour of delay, capped at 10% of annual contract amount.
• S2 exceeded by 1 day: penalty of 200 euros per day of delay, capped at 5% of annual amount.

This model imposes strict operational discipline on the vendor. However, it is rarely accepted by integrators on contracts below 50,000 euros annually. It must be requested from initial negotiation, as no vendor will accept it as an amendment.

Model 2: Commercial credit on renewal

Rather than an immediate penalty, the contract provides that in case of repeated breaches (for example: three S1 or S2 SLA overruns in a quarter), the client receives a credit equivalent to one month of subscription, deducted from annual renewal. This model is more acceptable to vendors, but only protects the client if they renew the contract.

Model 3: Escalation clause and right to terminate

Failing financial penalty, the contract must at minimum provide that in case of serious breach (for example: critical incident unresolved within 72 hours, or three major SLA overruns in a quarter), the client can:

1. Trigger escalation to vendor management, with mandatory response within 48 hours.
2. Suspend subscription payment until resolution (retention clause).
3. Terminate support contract without penalty and transfer maintenance to a third party, with obligation to deliver technical documentation and source code within 15 days.

This third model is the strict minimum. Without any of these three clauses, a support contract is purely declarative, and the vendor can ignore SLAs with impunity.

The enhancement subscription: buying a priced menu rather than abstract capacity

Corrective maintenance never suffices. Any business platform requires functional adjustments (new business rules, system integrations, process redesigns). Vendors therefore offer an "enhancement package", sold either in prepaid person-days, or in monthly capacity (for example: "10 hours of enhancement per month included in subscription").

The classic trap of this offer is that capacity is abstract: you buy "10 hours per month", but you don't know what these hours will concretely produce, nor what happens if you don't consume them. Three mechanisms must be framed:

1. Rollover or loss of unconsumed hours

If you consume 6 hours in January, what happens to the remaining 4 hours? Some contracts provide quarterly rollover (you can accumulate up to 30 hours over three months, then they are lost). Others impose strict monthly use-it-or-lose-it. Negotiate annual rollover with liquidation at renewal, to avoid creating false urgencies at month-end.

2. Time valuation in case of overrun

If you consume 14 hours in February, how are the 4 additional hours billed? The contract must specify the hourly rate outside package (typically 20 to 30% higher than the implicit package rate). Without this clause, the vendor bills at full commercial rate, which makes the package useless.

3. Transparency of consumed time

Require a detailed monthly statement (ticket by ticket, with time spent per developer and delivery status). Without this statement, you cannot verify that billed hours match actually consumed time. Some vendors artificially inflate estimates to exhaust the package and switch to paid time-and-materials.

An alternative more protective for the buyer is the per-ticket package: instead of buying hours, you buy a volume of enhancement tickets (for example: 12 tickets per year, regardless of their complexity, within a defined workload envelope). This transfers the sizing risk to the vendor.

Measuring actually delivered capacity each month

A maintenance subscription is a flow, not an event. Yet, many companies pay a support contract for years without ever measuring what it concretely produces. Three indicators must be tracked monthly by the procurement director or IT manager:

SLA compliance rate

The vendor must publish each month a report indicating, for each severity, the number of tickets handled and the percentage meeting contractual SLA. Example:

• S1: 2 tickets, 100% on time
• S2: 8 tickets, 75% on time (2 overruns)
• S3: 15 tickets, 60% on time

If this rate drops below 80% two months in a row, it's a signal of service quality degradation. The contract must provide that a rate below 75% over a quarter triggers a service review with corrective action plan.

Average resolution time by severity

Beyond binary SLA compliance (on time or not), measure the actual average resolution time. If S2 SLA is 5 days and average resolution time is 4.8 days, the vendor formally meets their commitment, but systematically works at the deadline edge. This indicates structural under-capacity.

Bug-to-enhancement reclassification rate

If 40% of your bug fix requests are reclassified as enhancement by support, it's either a problem of fuzzy contractual definition, or a vendor commercial tactic. Request monthly reporting of reclassified tickets count, with written justification. Beyond 20%, demand a revision of the contractual bug definition.

These three indicators must be published by the vendor as a monthly dashboard, ideally accessible online. Their absence is a warning signal: a provider who doesn't measure their own performance has no incentive to improve it.

The six lines to demand in a support contract

Summary of contractual clauses that actually protect your maintenance budget:

1. Strict definition of bug-vs-enhancement boundary: "Any behavior non-compliant with specifications validated during project acceptance constitutes a bug fix. In case of disagreement, a joint committee decides within 72 hours."
2. Severity grid with quantified restoration times for all categories, including S3 and S4, and joint validation of severity assigned to each ticket.
3. SLA starting point at ticket receipt, with strict framing of suspension reasons (maximum duration, mandatory written notification).
4. Penalty or escalation mechanism in case of breach: automatic financial penalty, credit at renewal, or right to terminate without penalty after repeated breaches.
5. Enhancement package transparency: annual rollover of unconsumed hours, contractually fixed overrun rate, detailed monthly statement of time spent per ticket.
6. Mandatory monthly reporting: SLA compliance rate, average resolution time, bug-to-enhancement reclassification rate, published within 5 business days after month closure.

Without these six lines, a maintenance contract is a subscription to uncertainty. With them, you transform an opaque expense into a measurable service, and you give procurement the levers to negotiate based on facts, not promises.

To go further in structuring your application contracts, discover our digital consulting services and support on business applications.

FAQ

What is the standard duration of an application maintenance contract?

A maintenance contract typically runs for 12 months, renewable by tacit renewal. Some vendors offer multi-year commitments (24 or 36 months) with degressive pricing, which can be interesting if the platform is strategic and the vendor proved themselves during warranty. Always negotiate an early termination clause without penalty in case of serious breach (for example: three consecutive months with SLA compliance rate below 70%).

Can a support contract cover multiple applications?

Yes, some support contracts pool maintenance of several platforms (for example: an ERP, a CRM, and a supplier portal) under a single global subscription. This approach allows negotiating a more advantageous rate and simplifying contractual management, but it requires clear allocation of time spent per application in monthly reports, to avoid one platform consuming the entire package to the detriment of others.

Should source code be required in escrow from support contract signature?

Yes, particularly if the platform is strategic and the vendor is a small structure. The escrow clause provides that source code is deposited with a trusted third party (notary, specialized organization) and automatically transmitted to you in case of vendor failure (liquidation, cessation of activity, serious contractual breach). This allows resuming maintenance with a third party without losing months rebuilding the application.

How to negotiate a realistic SLA without overpaying?

A very demanding SLA (for example: S1 restoration within 2 hours, 24/7) structurally costs more, as it requires permanent on-call from the vendor. For a controlled budget, favor business-hours SLA (Monday-Friday, 9 AM-6 PM) with a 24/7 on-call option activatable on demand for a monthly supplement. This gives you flexibility to scale up requirements if platform criticality increases, without paying this service level all year.

What to do if the vendor refuses to write delay penalties in the contract?

If the vendor refuses any penalty clause, negotiate at minimum an escalation clause with right to terminate without penalty in case of repeated breach. You can also condition quarterly subscription payment to achievement of a minimum SLA compliance rate (for example: 80% of S1 and S2 tickets on time). This incentive clause is less punitive than a penalty, but creates real budget constraint for the vendor.