"We chose our vendor by comparing only initial cost estimates, but once the system went live, a substantial maintenance fee was added every month. On top of that, whenever we want to make adjustments, we can only contact the company that built it, and their replies are slow." This was a consultation we received from a general affairs staff member at a company with about 40 employees who had introduced an order management system. Looking at the contract, while the development scope was detailed meticulously, maintenance was summarized in a single line: "Separate monthly fee: X yen." Even the person in charge did not understand what they were paying for or how much each component cost.
From the very moment a business system is built and delivered, costs to keep using it begin to accrue. However, when placing orders, attention tends to concentrate heavily on initial development costs, leaving the specifics of maintenance and operations for later. In this article, we break down the reality of monthly maintenance costs incurred post-delivery and present contractual approaches to prevent systems from being frozen in place, all from the client's perspective. Because initial costs and the distinction between contract-for-work and quasi-delegation agreements were covered in our guide to ordering system development, this article focuses strictly on the post-launch phase.
What goes into monthly maintenance fees
First, let us unpack what is lumped together under the single term "maintenance costs." The contents can be broadly divided into the following categories.
- Incident response and bug fixes: Initial response, root cause investigation, and remediation when the system stops or exhibits unexpected behavior.
- Inquiries and operational support: Answering questions about how to use the system. Workload fluctuates significantly depending on the volume of tickets and supported operating hours.
- Preventive maintenance: Actions taken before failures occur, such as monitoring servers and applications, running backups, and applying security patches.
- Adaptive maintenance: Keeping the system aligned with external environmental changes, such as legal amendments or version upgrades of operating systems, middleware, and libraries.
- Improvements and feature additions: Adding functionality based on new requirements. This is typically quoted separately from monthly base maintenance.
Adaptive maintenance is particularly easy to overlook. Even when nothing appears to change from the outside, underlying components age day by day, and the moment updates cease, security and operational warranties begin to expire. We explored what happens when this invisible upkeep is halted in the risks of build-and-abandon neglect using websites as an example. The same dynamic applies to business systems.
Why standard rates can only be discussed in ranges
As a benchmark for maintenance costs, the industry frequently cites a figure of around 10% to 15% of initial development costs annually. For instance, for a system costing 10 million yen to develop, roughly 1 to 1.5 million yen per year serves as one general baseline (portals like System Kanji indicate similar market perceptions).
However, this 15% figure is merely the midpoint of a broad range, and actual costs vary significantly depending on what maintenance entails. Listing cost expectations by category clarifies the reason for this variance.
| Maintenance category | Main tasks | Estimated cost (annual, relative to development cost) |
|---|---|---|
| Preventive maintenance | Monitoring, backups, patch application | Roughly around 5% |
| Adaptive maintenance | Legal compliance, OS/library updates | Varies widely by project, from 20% to 50% |
| Improvement maintenance | Feature additions, performance enhancements | Roughly 10% to 30%, fundamentally quoted per request |
(Source: compiled based on breakdown explanations by GeNEE Inc. and other sources)
Pricing models also differ in nature between fixed-fee models (paying a fixed monthly fee to look after a defined scope) and pay-as-you-go models (billing based on actual hours worked). It is rational to allocate ongoing, predictable needs like 24/7 monitoring to fixed fees, while reserving ad-hoc feature additions for pay-as-you-go billing. That is why, rather than taking a uniform formula like "maintenance is X% of development costs" at face value, you must first estimate how much effort each category requires for your specific system.
Clauses you must always check in the contract
Maintenance agreements are generally executed under quasi-delegation contracts. The single most crucial point here comes down to whether the contract explicitly defines what will be done and to what extent. Signing an agreement while terms remain ambiguous creates a gap between expectations and actual service quality.
Key areas to verify include the following.
- Scope of work and exclusions: Whether boundaries are explicitly stated, such as including incident response while excluding feature additions for separate billing.
- SLAs (Service Level Agreements): How quickly incidents are detected, notified, and emergency triage is initiated. Without agreed-upon timelines, unrealistic expectations of immediate turnaround take on a life of their own.
- Support hours: Whether coverage is limited to weekday business hours or extends to nights and weekends. This drastically impacts monthly fees.
- Deliverables and source code rights: Who holds copyrights and usage rights for source code and design documentation, and whether disclosure or modification by third-party vendors is permitted.
Rights surrounding deliverables, in particular, serve as the lifeline for avoiding system neglect and lock-in, as discussed below. Spot support without an active contract imposes no obligation on the vendor to respond immediately, carrying the risk of hefty emergency response surcharges when crises occur.
Architecting to avoid abandoned systems and vendor lock-in
The opening scenario of "only being able to contact the company that built it" is a textbook example of vendor lock-in. Vendor lock-in is said to arise from a combination of three dimensions: technical, operational, and contractual. Dependence on proprietary technology or undisclosed specifications (technical), lack of documentation leading to single-person dependency (operational), and absence of clear source code ownership or handover terms in the contract (contractual) each make transitions difficult (an analysis by EC-CUBE outlines these root causes and risks).
Once caught in this state, even if you feel maintenance costs are exorbitant, you cannot consult other vendors and are forced to accept price hikes and delayed responses. What clients can do to prevent this is surprisingly straightforward: ensure design specifications and runbooks are formally delivered as deliverables, clarify source code ownership and rights in the contract, and maintain an organizational posture that avoids placing total reliance on a single vendor. While deciding how much to delegate between in-house resources and external vendors was also discussed in our piece on delineating in-house development versus outsourcing, maintaining a handover-ready state is especially critical during the maintenance phase.
Even when we take over maintenance of existing systems in our custom development practice, our first step is not reading code, but auditing documentation and legal rights. Systems devoid of recorded design intent require research costs every single time a fix is attempted, which directly inflates maintenance expenses. Conversely, a system organized with future handovers in mind will not suffer from spiking fees even if you switch vendors.
How to choose the right maintenance model for your company
In practice, maintenance structures should be chosen based on system criticality. For a mission-critical core system whose stoppage paralyzes operations, it is worth executing a fixed-fee maintenance contract covering monitoring and rapid response, with triage response times guaranteed via an SLA. On the other hand, for auxiliary systems that can tolerate being down for a few days, keeping fixed fees minimal and pairing them with spot requests is a valid option to keep costs down. The decision axes are "how damaging downtime is" and "the frequency of incoming changes."
If you feel your current maintenance contract has become a black box, take this next step: check just two things in your existing maintenance agreement. First, are the scope of support and SLAs defined? Second, does your company own the rights to the source code and design documents? If these two points are ambiguous, that is where your future risk of system neglect lies. If you need a second opinion on taking over an existing system or evaluating whether maintenance fees are fair, we can assist you through our custom development services, starting with a baseline audit of your current status.
