The real cost of keeping business software running: maintenance, security updates, monitoring and ownership

The proposal had a number for building the software. It rarely has one for keeping it. A year after launch the costs arrive anyway, one at a time: a notice from the app store about an outdated version, a certificate that expired on a Sunday, a payment provider retiring an old API, and the discovery that the only person who knew how to deploy has moved on.

None of these is bad luck. They are the normal cost of running software, and they can be planned. This guide sets out what a business should budget for after launch, which deadlines are set by other people, how to tell whether a system is being looked after, and what you need to hold so that you are never locked in. It ends with a worksheet you can fill in with your own figures.

Build once, run every year

A useful way to read any software proposal is to split it into two columns. One is paid once. The other comes back every year for as long as the system is in use.

Software changes even when you change nothing

A business application sits on top of a programming language, a framework, a database, an operating system, a cloud platform and, for a mobile app, two app stores. It talks to payment gateways, messaging providers and browsers. Every one of those is maintained by someone else, on their timetable. When they move, your application has to move with them or stop being supported.

Hosting in the cloud does not change this. Cloud providers describe the split as shared responsibility: the provider secures the infrastructure, and the customer is responsible for what runs on it, including operating system patches on servers they manage and the application itself. Nobody is updating your code on your behalf unless you have arranged it.

The deadlines you do not control

These dates are published by the platforms themselves. They are the most predictable part of a maintenance budget, because you can see them coming a year or more ahead.

The last row is worth a moment, because it puts a price on delay. AWS's published example for MySQL 5.7 in a US region is $0.10 per vCPU-hour for the first two years of Extended Support and $0.20 in the third. For a database with four vCPUs running all month, that is about $290 a month at the first rate, on top of the normal database charge. A standby copy is charged as well. The rate for your engine, version and region will differ, so check AWS's pricing page.

Security and dependency updates

Most of the code in a modern application was not written by your supplier. It comes from open-source packages: the framework, a PDF library, a payment SDK, hundreds of smaller pieces. That is normal and efficient. It also means a vulnerability in any of them is a vulnerability in your system. The 2025 edition of the OWASP Top 10 lists software supply chain failures as its third-ranked risk.

• Someone reviews dependency updates on a schedule. Monthly is a reasonable default for a business system.
• Automated alerts report known vulnerabilities in the packages you use.
• There is an agreed response time for serious ones. Vulnerabilities known to be exploited in the wild, such as those in CISA's Known Exploited Vulnerabilities catalogue, go first.
• Updates are applied in a staging environment and tested before production.
• Each month has a short written record: what was updated, what was deferred and why.

NIST's Secure Software Development Framework names this work "Respond to Vulnerabilities" and treats it as a continuing practice, not a project. The cost is a predictable number of hours a month. It rises sharply when updates have been skipped for a year or two, because several major versions then have to be crossed at once.

Bug fixes, small changes and compatibility

Real use finds problems that testing did not. A report that is wrong when the month has five Fridays. A form that fails on one phone model. Agree in advance how these are handled.

• A defect is the software not doing what was agreed. A change request is the business wanting something different. Contracts that do not separate the two produce arguments.
• A warranty period after launch, during which defects are fixed at no charge, is common. Know how long yours is.
• Third-party services retire old versions of their APIs. Payment gateways, messaging providers and mapping services all do this, with notice. Someone has to read the notices.
• New browser and phone releases occasionally break layouts or features. A short check after each major release is enough for most systems.

Hosting, monitoring and the things that renew

Hosting is the cost most people do budget for, and usually the smallest surprise. The lines that get missed are around it.

• Domains, certificates, app store developer accounts and software licences, each with its own renewal date and its own card on file.
• Usage-based services: payment gateway fees, SMS and WhatsApp messages, email delivery, maps. These grow with the business.
• Monitoring: whether the system is up, whether it is throwing errors, and whether it is slowing down. Without it, your customers are the monitoring.
• Incident response: who is told when something breaks, and during which hours. If nobody is on call at night, that is a legitimate choice for many businesses. Make it deliberately and write it down.

Backups and recovery you have actually tested

Two questions settle a backup policy, and both are business decisions. How much recent data can you afford to lose? How long can the system be down? Engineers call these the recovery point objective and the recovery time objective. If the answers are "an hour" and "half a day", the backup design and its cost follow from that.

• Keep three copies of important data, on two different kinds of storage, with one copy off-site. This is the 3-2-1 rule that CISA recommends to small businesses.
• Back up the database, uploaded files and configuration. A database without the documents it refers to is half a recovery.
• Restore a backup to a test environment on a schedule, at least quarterly, and time it. A backup that has never been restored is an assumption.
• Make sure the backups are in an account you control, not only your supplier's.

Support and response times

Users will have questions and things will go wrong at inconvenient times. What you pay for support depends mostly on three choices: the hours covered, how quickly someone must respond, and how much work is included before extra charges apply.

• Separate response time, which is when someone acknowledges and starts, from resolution time, which is when it is fixed. Suppliers can commit to the first far more reliably than the second.
• Define severity levels with examples from your own business. "Nobody can log in" and "a label is misspelt" should not share a queue.
• A monthly retainer gives predictable cost and a team that knows your system. Pay-as-you-go is cheaper in quiet months and slower in a crisis.

Technical debt and documentation

Technical debt is the accumulated cost of shortcuts: a quick fix that was never tidied, a module without tests, a library three versions behind. Some debt is reasonable. Unmanaged, it makes every later change slower and riskier, and the bill is paid in the price of new features.

Protect a small, regular allowance for it: adding tests around the parts that break, removing dead code, updating the documentation. The documents worth having are short. One page on how the system is put together, the steps to deploy it, what to do when it goes down, and a list of every integration with where its credentials are kept.

Ownership and exit readiness

The most expensive maintenance problem is not technical. It is discovering, when you want to change supplier or your developer becomes unavailable, that you do not hold what you need to carry on. Check this while the relationship is good.

A sample annual planning worksheet

Use the table below as a starting structure. Put your own figures in the estimate column, from last year's invoices and your supplier's time records where they exist.

We have deliberately not given a percentage of the build cost. Rules of thumb exist, they vary widely, and none of them holds across a five-screen catalogue app and an ERP that takes payments. A budget built line by line from the table above will be closer to the truth, and it shows you where the money goes.

Signs that software is not being looked after

• Nobody can say which version of the language or framework it runs on.
• The last deployment was more than a year ago.
• A certificate or domain has expired by surprise at least once.
• Only one person can deploy, and there are no written steps.
• No one has ever restored a backup.
• The app stores or the cloud provider have sent warnings that nobody has acted on.
• Every small change takes longer and costs more than the last.

Two or three of these together mean the running costs have been deferred, not avoided. They will arrive as a single larger bill, usually at a bad moment.

Where to start

Begin with an inventory. Write down what the system runs on, with version numbers. List the deadlines from the table above that apply to you, every renewal with its date, and who holds each account. That takes a day and it turns a vague worry into a plan.

Techimpace maintains business software it built and software it has taken over from other teams. For PHP and Laravel applications there is a monthly Care Plan covering PHP, Laravel and package updates. For other systems, a software health review produces the inventory above, the deadlines that apply, the ownership gaps and a costed plan for the year. You can use it with us or with any other supplier.