Checkpoints for Maintenance Agreements and System Maintenance Agreements: Scope of Services, SLAs, and Additional Fees

Hello, I'm Noriaki Asato, Representative Attorney at LegalAgent.

Compared with software development agreements, system maintenance agreements tend not to attract much attention. However, if their content is not worked out carefully, the consequences surface the moment a failure occurs. This is because, if the maintenance scope, response hours, and the boundary for additional fees remain vague, the user tends to think "of course this is covered by the monthly fee," while the vendor takes the view that "this is outside the scope of maintenance."

For systems whose development has been completed, day-to-day upkeep continues, such as handling minor defects, applying security patches, and providing first-line response to failures. In reviewing the contract, we look one by one at how far these tasks are included in the maintenance agreement, while imagining scenarios in which failures occur.

Companies that want lawyers to review contracts on the scope of system maintenance and the treatment of additional fees can use our legal outsourcing, which lets them engage lawyers on a continuing basis even without a legal department.

Distinguishing Maintenance from Operation and Determining the Contract Type

A system maintenance agreement is a contract that entrusts the continuous upkeep of a system in operation, response to failures, minor modifications, and the like. Its subject is not limited to business systems and web services, and often extends to SaaS integrations and cloud environments. Many such agreements are close to quasi-mandate contracts in type, but this cannot be determined immediately from the name of the contract or the services alone. It is determined substantively from the content of the agreed services and whether there is an obligation to complete work.

In the case of a quasi-mandate contract, the vendor does not undertake to complete a deliverable; instead, it performs the services of responding to inquiries and failures with the care of a prudent manager based on its expertise and keeping the system in a usable state. By contrast, for parts that include individual functional modifications or additional development, there are situations where treating them as closer to a contract for work, which carries an obligation to complete the work, better fits practice.

The difference between maintenance and operation is another issue worth sorting out. Maintenance often refers to work that keeps and restores the system, such as investigating and fixing defects and applying patches, while operation may refer to the day-to-day work of keeping the system running, such as daily batch processing, account management, uptime monitoring, and checking backups. Whether these two are defined separately in the contract or entrusted together changes the fee estimate and where responsibility lies.

Designing the Boundaries of Scope, SLAs, and Fees

When reviewing a maintenance agreement, check three boundaries against one another: the scope of services, the SLA (service level agreement), and additional fees. The table below is one concrete design example used in practice. It is not a standard that applies to every contract, but it serves as a guide for organizing the division of roles.

Issue	Examples included in the monthly maintenance fee	Examples that may be charged separately	Matters to decide in the contract
Scope of services	Responding to inquiries, investigating defects in existing functions, minor fixes, regular reports	New feature development, specification changes, data migration, investigation of other companies' products	Covered systems, covered services, excluded services, cap on monthly person-hours
SLA	Reception hours, failure categories, initial response time, recovery targets, scheduled maintenance	Emergency response at night and on holidays, round-the-clock monitoring, on-site support	Starting point for measuring time, excluded time, communication channels, treatment when targets are not met
Additional fees	Work performed within contracted person-hours, routine work agreed in advance	Exceeding the cap, emergency response, additional modifications, on-site work	Estimates, unit rates, prior approval, start of work, timing of invoicing

Even if these three elements are set out in separate provisions, in actual practice they operate in tandem. For example, even if investigating failures at night falls within the scope of services, if the start time under the SLA and the approval procedure for additional fees have not been decided, the more urgently recovery is pursued, the more the agreement on fees gets postponed.

In designing the SLA, confirm practical procedures such as whether response is limited to weekday business hours or includes nights and holidays, and whether email or chat takes priority as the emergency contact channel. Not every maintenance agreement needs a detailed SLA, but the more directly a system is tied to the business, the less likely expectations are to diverge during a failure if the minimum service level is set in numbers.

When setting availability or recovery targets, make clear whether they are merely efforts targets or obligations to achieve them, and pin down the starting point for measuring time and excluded time such as scheduled maintenance. Failures of external cloud services, too, are not always automatically exempt or excluded from the SLA, so it is essential to define the line between each party's scope of control and responsibility. Also check the relationship between service credits for unmet targets and damages.

As for the boundary between the monthly fee and separate fees, check whether additional modifications, specification changes, night and holiday response, and on-site support are included in the package. If a cap on person-hours is set, stating in the contract the unit rate for overages and the prior approval flow makes it easier to prevent disputes at the time of invoicing.

Failure Response Procedures and Security Management of the Production Environment

The failure response provisions set out the definition of a failure, severity categories, the reporting method, and the flow from root cause investigation through recovery reporting and measures to prevent recurrence. It is not uncommon to be unable to tell immediately whether the cause is an application defect, an infrastructure problem, or a failure of an external integrated service. If the scope of investigation and the point of contact with third-party services are not organized, it may lead to the parties shifting responsibility onto each other. Also decide which party is responsible for investigating the impact of published vulnerability information and applying patches, and whether emergency response costs fall within the monthly allowance.

For maintenance work that involves access to the production environment, concrete security management arrangements are required according to the information accessed and the operating permissions. It is useful to set out, as separate security management provisions, criteria for granting and revoking access permissions, the collection and retention of access logs, management of subcontractors, reporting deadlines when incidents occur, and so on.

Transition Support upon Termination and Risks for Both Parties

Because a maintenance agreement is a continuing contract, check not only contract renewal and the notice period for termination but also rights to terminate in the event of serious failures and rights to suspend services in the event of late payment. Furthermore, it is necessary to look ahead to the return of data, the return of accounts, and support for handover to another company at the time of termination. If the source code, configuration information, and infrastructure diagrams needed for maintenance are kept only on the vendor's side, it may become difficult to transition to another company when the contract ends. Providing materials and transition support upon termination is not a free obligation that arises automatically by law, so stating the scope of provision and the allocation of costs in the contract is the practical safeguard.

A major risk on the user's side is a situation where, despite the sense of security that comes from having a maintenance agreement, the user cannot receive the necessary support when it counts because defect fixes turn out to be charged separately or night and holiday response is not included. Provisions on transition support and the provision of materials upon termination should also be checked.

The risk on the vendor's side is that the maintenance scope expands while remaining unclear, and the vendor is asked, within the fixed monthly allowance, to add new features, change specifications, and even deal with defects in other companies' services, putting pressure on person-hours. Defining excluded work, the conditions for separate estimates, the cap on person-hours, and the treatment of emergency response costs serves as the line of defense. A damages provision under which the vendor bears without limit the user's lost profits and reputational damage caused by system downtime may be out of proportion to the consideration of the maintenance fee, so reviewing the limitation of liability provision is also important.

In a serious failure, not only on-site technical response but also customer handling and management decisions begin immediately. I think the contract serves as the foundation for clarifying the communication structure and priorities and preventing delays in the initial response.

Generative AI is helpful for identifying general issues such as the maintenance scope, response hours, and SLAs. However, the background, such as whether the system in question is a small internal tool used by part of the company or the core system of a customer-facing service, cannot be read from the text of the contract alone. Only when a person supplies the importance of the system, the number of users, and the scale of damage expected in the event of a failure does a review grounded in practice become possible.

Frequently asked questions

What is a system maintenance agreement?

It is an agreement to outsource the ongoing upkeep of a system in operation, incident response, minor modifications and similar work. In terms of contract type, many such agreements are close to a quasi-mandate, under which the services are performed with the due care of a prudent manager without an obligation to complete a deliverable. However, parts involving individual functional modifications or additional development may be better treated as close to a contract for work, and the classification is likely determined substantively by the content of the services and whether there is an obligation to complete, rather than by the title of the agreement.

What boundaries should be checked when reviewing a maintenance agreement?

The three boundaries of scope of services, SLA and additional fees should be checked against one another. This is because they interact simultaneously on site: even if overnight incident investigation is within scope, if the start time and the procedure for prior approval of additional fees are not settled, the more urgent the recovery, the more the fee agreement gets put off. It is understood to be important to state clearly in the agreement the line between work within the monthly allowance and work charged separately, the unit rate when the cap on hours is exceeded, and the prior approval flow.

Is there an obligation to hand over the system to another company when the maintenance agreement ends?

It is not imposed by law as an automatic, free-of-charge obligation. Providing materials and transition support at the end of the agreement is not an automatic free obligation, so if the agreement does not provide for it, obtaining that support may become difficult. To prepare for a situation in which source code, configuration information and infrastructure diagrams are held only by the vendor, it is likely necessary to state clearly in the agreement in advance the scope of handover support and who bears the cost.