What a system maintenance contract should include: 12 clauses to check before you sign

"I read the contract. It's one page. Looks fine." That is how a lot of system maintenance contracts get signed: the vendor provides system maintenance services, so much per month, one-year term, auto-renews at expiry. Six months later, on a Friday night, the shipping system won't open, and the vendor says they'll handle it Monday. You want to add a field, and they say it's a new requirement that needs a separate quotation. You want to switch vendors, and only then find out the server account is registered in their name. Every time you go back to the contract, it says nothing about any of it.

I'm Johnny Yang, founder of Brightstream Technology in Taiwan. In 7 years I've done 252+ projects across 32+ industries, and we deliver more than NT$20,000,000 in systems a year. I sign post-launch maintenance contracts with my own clients, and I've reviewed plenty of other vendors' versions for business owners. The most common problem isn't unfair terms. It's that the things that should be written down aren't written at all.

The short answer: a system maintenance contract that actually protects you spells out at least 12 things, in four groups. Scope: what's included, what's not, and how much room there is for small adjustments. Time: how issues are graded, how fast each grade gets a response and a fix, who decides the grade, and what hours someone is on call. Control: who holds the source code, the server and domain accounts, and the backups and restore tests. Exit: how fees change and how the contract ends, and what gets handed over when it does. The test is simple. Run three scenarios against it: "the system goes down on a Friday night," "the engineer on your account quits," and "you decide to switch vendors." If the contract can answer who handles it, how fast, and at what cost, it passes.

Why are maintenance contracts so often one page?

A thin maintenance contract usually isn't anyone's plan. The implementation contract took months to negotiate. Both sides spent their energy on features, price, and the launch date. By the time they get to maintenance, everyone is tired, and everyone assumes a finished system won't have problems. So someone grabs a template, changes the company name and the amount, and it gets signed.

The other reason is that the value of maintenance is invisible until something goes wrong. An implementation contract buys features you can see. A maintenance contract buys "someone picks up when it breaks," and at signing, nothing has broken yet. Very few owners sit down, while everything is going fine, and think through the worst day.

But the worst day is exactly what a maintenance contract is for. How the fee itself should be calculated, and how annual, monthly, and per-incident pricing differ, I covered in what a reasonable system maintenance fee looks like. This post isn't about price. It's about the words in the contract, because at the same NT$20,000 a month, different wording can buy you very different things.

The 12 clauses of a system maintenance contract, in one table

In the table below, the left column is the wording I see most often in contracts. The right column is wording that protects you better. Lay your contract out and check it line by line.

Group 1: scope — what your money actually covers (items 1–3)

Scope is where most fights happen. The owner thinks, "I pay for maintenance, so when I ask for a change, you make it." The vendor thinks, "Maintenance means keeping the system running. What you want is a new feature." Neither is wrong. What's wrong is that there's no line both sides can see.

The best anchor for that line is a written feature list. If something is on the list and doesn't work, breaks, or needs tweaking, that's maintenance. If it's not on the list, it's a new requirement. That's how my own maintenance contracts are written: during the maintenance period, UI/UX, field, and report layout adjustments within the written feature list are not charged separately. New features outside the list go back to an implementation or development scope and are discussed separately.

If your system never had a feature list, items 1 to 3 are hard to write clearly. The practical move is to have the maintenance vendor inventory the system's current features into a list, have both sides confirm it, and attach it to the contract.

Group 2: time — when it breaks, how long until it's fixed (items 4–7)

This group is the easiest to wave away with "will handle as soon as possible." How soon is soon? The vendor thinks three days is fast. You're losing money after three hours.

The first thing to separate is "response" and "fix." Response means someone answers your message and starts looking. Fix means the system works again. Many contracts only state a response time, which looks fast, but say nothing about how long the fix takes after that. My own wording: critical issues patched within 24 hours of the report, high-risk issues within 72 hours. It says patched, not responded to.

The second is who decides the grade. On month-end closing day, if reports won't run, accounting calls it an outage. The vendor says you can still log in. So grading is best defined by operational impact. For example, "can't ship," "can't issue invoices," and "can't collect payment" go straight to the top grade.

The third is hours. If you ship on Saturdays but the contract only says weekday business hours, a Saturday failure waits until Monday. Whether anyone is available on holidays, how to reach them, and whether it costs extra all need to be settled before you sign.

Group 3: control — who holds what (items 8–10)

You don't feel this group at all day to day. When something goes wrong, it's the one that kills you. Where the source code lives and whether you can get the latest version any time. Whose name the server, domain, LINE, and payment gateway accounts are registered under. How often data is backed up and whether anyone has actually restored from it.

I worked with a medical aesthetics brand whose previous vendor spent years building a system that never went live. When we took over, the first thing we did wasn't writing code. It was getting their assets back and figuring out what they actually had. Only then did we decide to rebuild. If the original contract had items 8 and 9, at least getting things back wouldn't have been so hard. For how to agree on source code licensing, see who owns the code in a custom-built system.

One more word on backups: "regular backups" in a contract is useless. Write "how often a restore test is run, with results recorded and given to the client." A backup that has never been restored might or might not work on the day you need it. Nobody knows.

Group 4: exit — what happens if you split up (items 11–12)

Nobody signs a contract planning to split up. But maintenance contracts often run for years, and in that time the vendor's staff change, your company changes direction, or the two sides stop getting along. All of that is common.

Item 11 should state: how much notice before a fee change, how increases are agreed, and under what conditions either side can terminate. Item 12 should state: when the contract ends, which documents, accounts, and data the vendor hands over, in what format, and how long they support the handover. With these two written clearly, you actually have a choice, instead of renewing forever because you can't get out.

"Won't spelling it out this much damage the relationship?"

At this point a lot of owners have a concern: working with a vendor runs on trust. A contract written like it's guarding against a thief might make them uncomfortable. And if the clauses are too detailed, neither side will read them, and nobody will follow them anyway.

The concern is fair. Between small businesses and system vendors, it's often owner-to-owner goodwill, and a twenty-page contract does make things stiff. I don't recommend writing every scenario in either. That kind of contract only makes both sides' lawyers happy.

But the real issue is this: a vague contract doesn't mean fewer fights. It just postpones the fight to the worst possible moment. At signing, everyone's in a good mood and everything is easy to discuss. Arguing over "does this count as maintenance" when the system is down, you're angry, and the vendor feels wronged — that's what damages the relationship.

Writing it down protects the vendor too. They know what to do proactively and what they can quote separately. They don't have to worry about unlimited demands, so they don't push back on everything by default. In my experience, the vendor willing to work through these 12 items with you is usually the one that actually picks up the phone when something breaks. Which questions during contract negotiation best reveal a vendor's attitude, I listed in 12 questions to ask before signing an ERP contract. They apply to maintenance contracts too.

Test your contract against three scenarios

Once you've checked the clauses, there's a faster test: take three scenarios you will definitely face and ask whether the contract can answer them.

Scenario 1: 8 p.m. Friday, the system won't open, and you ship tomorrow morning. You need to know: who to call, what grade this is, how many hours until someone is on it, and whether weekends cost extra. This maps to items 4 to 7. If any answer is "it depends," you're just waiting on Friday night.

Scenario 2: the engineer responsible for your system quits. Who's the replacement, how long will they take to get up to speed, what happens if the system breaks in the meantime, and where are the original design documents. This maps to items 8, 10, and 12. This scenario is the most overlooked, because the contract is signed with a company, but the person who actually understands your system is one individual.

Scenario 3: you decide not to renew next year and switch vendors. How much notice you need to give, how the source code and accounts are transferred, what format the data comes out in, how many weeks the vendor supports the handover, and whether the handover costs extra. This maps to items 8, 9, 11, and 12.

After running these, every place where the answer is "we'll discuss it then" is a clause you need to add. You don't have to fix everything at once. Start with the ones that hurt most.

Already signed and the clauses fall short. How do you fix it?

Most owners reading this have already signed, and their contract is probably missing about half of this. Don't panic, and don't rush to terminate. Fix it in this order.

First, fix control. Items 8 to 10 are the hardest to recover after the fact. If you can't get the source code and the accounts are in someone else's name, by the time you really need them, there's usually no room to negotiate. Some of these don't even require changing the contract. For example, you can ask the vendor to transfer the domain and server registration to your company's name right now.

Second, confirm terms with a supplementary agreement or formal written correspondence. You don't have to re-sign the whole contract. If both sides confirm in writing the response and fix times, holiday handling, and restore test frequency, that's already far better than before.

Third, change it all at renewal. Many contracts are one-year terms that auto-renew. The month or two before renewal is the best time to put in every gap these scenarios turned up.

If your system was built by another vendor and they've stopped responding, it's no longer a question of adding clauses. First confirm whether you can get back the source code, accounts, and data. For the steps, see what to do when your system vendor disappears or stops responding.

FAQ

Does a system maintenance contract have to include an SLA?

It doesn't have to use the word SLA, but it has to have the content: how issues are graded, how fast each grade gets a response, how fast it gets fixed, and who decides. Plenty of contracts include the letters SLA but the content is just "will handle as soon as possible." That's the same as writing nothing.

What's the difference between response time and fix time in a maintenance contract?

Response time is how fast the vendor replies and starts working on it. Fix time is how fast the system is usable again. In a contract that only states response time, a "received" message within ten minutes counts as meeting the target. What actually affects your operations is fix time, or at minimum, a deadline for proposing a workaround.

The source code was never handed over. Can it be added to the maintenance contract?

Yes, and the sooner the better. Use a supplementary agreement to state where the source code is stored, that you can get the latest version at any time, and the scope of the license. Vendors are usually willing while things are going well. Bring it up only when you're splitting up, and it's very hard to negotiate.

Is a one-year maintenance contract better, or a longer one?

One-year terms are more common, and the benefit is a chance to review every year. More important than the term is the auto-renewal clause and the notice period for fee changes. Without those two, a one-year contract and a five-year contract are about the same. Either way, it's hard to call a stop at the right time.

A maintenance contract buys you answers for the worst day

In one sentence: a system maintenance contract isn't about the ordinary days. It's about who handles it on the day it breaks, how fast, at what cost, and whether you get your things back if you ever split up. Write these 12 items down clearly, and every month you pay actually buys something.

If your maintenance contract is one page, or renewal is coming up and you're not sure which clause to fix first, take a look at how we assess system maintenance and takeovers, then decide how to change this version of the contract.