What is a software maintenance contract and what should it cover?
A software maintenance contract is the written agreement that says which work a supplier will do to keep delivered software running in production, how fast, and for what fee. A good one spells out four things: the scope of maintenance, response and resolution times (the SLA), how out-of-scope work is priced, and how the contract ends.
Maintenance is not one kind of work. It helps to think in four groups:
- Corrective maintenance: fixing faults that appear in production.
- Adaptive maintenance: keeping up with changes in the operating system, browser, libraries, a bank or the e-invoicing system.
- Perfective maintenance: adding a feature, report or screen. Most contracts treat this as separate, chargeable work.
- Preventive maintenance: security patches, backup checks, performance monitoring and reducing technical debt.
Software engineering standards use the same split; ISO/IEC 14764 divides software maintenance into similar types. What matters is that the contract says which types are included in the fee and which are charged separately. Otherwise "maintenance" means "everything" to one side and "bug fixes only" to the other, and a dispute follows.
Google's search suggestions in Turkey include phrases such as "yazılım bakım sözleşmesi" (software maintenance contract), "yazılım bakım sözleşmesi örneği" (sample contract) and "yazılım bakım türleri" (types of software maintenance). Most readers are asking the same thing: I pay a fee every year, so what exactly do I get for it?
What does a scope and SLA clause checklist look like?
The table below summarises the main clauses we expect to see in a maintenance and support contract. Times and amounts differ from company to company; the table shows only what should be written down.
| Clause | What to write | Common gap |
|---|---|---|
| Scope | Which systems, versions, environments | Test environment and integrations forgotten |
| Maintenance types | Corrective, adaptive, preventive included? | "Maintenance" left generic |
| Severity levels | Definitions of critical, high, medium, low | Nobody says who assigns the level |
| Response and resolution | First response and fix target per level | Office hours or 24/7 not stated |
| Out-of-scope work | New features, training, data migration | No hourly rate defined |
| Reporting | Monthly ticket and time report | No records, so no measurement |
| Term and exit | Period, renewal, notice, handover | Source code and knowledge transfer missing |
How do you set response and resolution times in an SLA?
An SLA (service level agreement) defines measurable targets for the service the supplier provides. A maintenance contract has two separate times, and they should not be confused. Response time is how long until the report is acknowledged and someone starts work. Resolution time is how long until the problem is fixed or a workaround is running. If response time is short but resolution time is undefined, the "we have received your request" message arrives quickly and the problem lasts for days.
- Define severity by business impact. "The whole system is down" and "a column in one report is wrong" cannot share a level.
- Say when the clock starts. State whether reports go by email, phone or a ticket system, and which of them starts the timer.
- Be clear about working hours. Weekdays 09:00-18:00, or is there an on-call rota? Do public holidays count?
- Define a workaround. If a permanent fix takes time, does a workaround that restores service meet the resolution target?
- Write down the customer's obligations. If you must provide access, test data or answers to questions, that waiting time should not count against the supplier's clock.
- Set the remedy. What happens when a target is missed: a fee reduction, a contractual penalty or a right to terminate?
One point on remedies. The penalty clause provisions in Articles 179 to 182 of the Turkish Code of Obligations let the parties set the amount of a penalty freely, but allow the judge to reduce a penalty considered excessive. Articles 123 and 125 of the same code deal with giving a debtor extra time and withdrawing from the contract after a delay. Keeping the SLA remedy reasonable and measurable is therefore safer, both for enforceability and for dispute risk. How these articles apply to your type of contract should be assessed separately; ask your lawyer for a firm view.
Hour bank or fixed monthly fee?
Maintenance fees are usually built in one of two ways. In the first you pay a fixed monthly or annual fee, and a defined scope of work is included. In the second you buy a pool of hours in advance and each request draws it down. A mix is common too: the fixed fee covers monitoring and bug fixes, while development comes out of the hour pool.
| Model | Strength | Watch out for |
|---|---|---|
| Fixed monthly fee | Predictable budget | Out-of-scope work must be defined |
| Hour bank | Pay for what you use | Carry-over and expiry must be written |
| Hybrid | Separates fixes from development | Which work uses which pot must be clear |
| Pay per use | Low cost when little is used | Critical outages may cost extra |
For an hour bank, put three details in writing: how time is measured (15-minute blocks or whole hours), whether the pool resets at the end of the month or the year, and how often the balance is reported. When these are missing, the most common dispute begins with "where did the hours go?"
How should the term, termination and handover work?
Maintenance contracts usually run for a year and renew automatically. Put the notice date for renewal in your calendar; otherwise you may be bound to a period you did not want. In the termination clause, look for:
- When either side may terminate immediately for good cause, for example repeated SLA breaches on critical faults.
- What happens to fees already paid for the current period: refund or set-off.
- The supplier's handover duty after termination: documentation, source code, environment details, backups and a transition period of support.
- Where personal data is involved, Article 12 of Law No. 6698 (KVKK) makes the data controller jointly responsible, with anyone processing data on its behalf, for security measures. When the maintenance team can reach live data, this provision may be relevant, so access logging, confidentiality and deletion or return of data should be in the contract.
Is VAT withholding applied to maintenance invoices?
This is a frequent question (phrases like "yazılım bakım tevkifat" appear in Google suggestions), but the answer depends on the exact nature of the service. The Value Added Tax Law No. 3065 refers to those made responsible for withholding tax, and which services fall into that group is set by secondary legislation that can change. Combining items such as hardware maintenance, software licences, cloud services and development on one invoice can also change the outcome.
In practice: list the invoiced items on separate lines in the contract, confirm the VAT rate and any withholding treatment with your accountant before signing, and check the current communiqué. We do not give a rate here because rates change with the regulation.
Example: how scope might be shared in a maintenance contract
For example, take a maintenance contract for an order-tracking application with 40 users. All figures are hypothetical. The contract might include:
- Critical level (system down): response within 1 hour in office hours, with a target to fix or work around on the same day.
- High level (an important function not working): response within 4 hours, with a fix target of 2 working days.
- Medium and low levels: response within 1 working day, fixed in a planned release.
- Included in the fixed monthly fee: bug fixes, security patches, backup checks, a monthly report.
- From the hour bank: new reports, screen changes, extra integrations. For example a pool of 40 hours a year.
Suppose 12 requests arrive in a month: 1 critical, 3 high and 8 low. The monthly report shows when each was opened, first answered and resolved. At month end you can see which targets were met; if the critical request overran, the remedy in the contract applies. A 5-hour request for a new report in the same month is drawn from the pool, leaving 35 hours. Nobody has to argue about whether it was included in maintenance.
What mistakes do people make in maintenance contracts?
- Leaving "maintenance and support" undefined, without separating corrective, adaptive and perfective work.
- Writing a response time but leaving the resolution time undefined.
- Letting only the supplier decide the severity level.
- Not saying how source code, environment details and documentation are handed over at exit.
- Not asking for ticket records and a monthly report, so you cannot tell whether the SLA is being met.
- Merging invoice items into one line and thinking about VAT afterwards.
How Hatson Tech helps
In our custom software development solutions, we discuss the maintenance scope, severity levels and reporting for the systems we deliver at the start of the project. Hatson does not publish fixed prices; the first meeting and the discovery work are free. If you want to review a contract you already have, Caseon, our due diligence and contract review product for legal teams, can also be used to scan documents of this kind. If you are deciding whether to keep maintaining an old system or replace it, see our application modernisation decision guide, and for the questions to put to a supplier, our guide to choosing an AI supplier.