Software doesn’t age by being used
“How much will it cost us to keep this system alive for another ten years?”
A car ages even in the garage. Not through mileage, but because the seals dry out and parts stop being made for a twenty-year-old model. Software is similar, just without the garage: a program doesn’t wear out from being run — you can start it a million times and it will keep doing the same thing. It ages because the world around it moves on while it stands still.
Still the same application
I’ve been looking after one application since 2019. In that time it has moved through three generations of .NET, most recently in 2025, and nobody has rewritten it. It’s the same application, just a bit newer under the hood each time.
Once there was a job nobody had wanted. The driver the application uses to talk to its database changed its behavior, and without an adjustment the application would have stopped working. No new feature came of it, no improvement — just work so that everything kept doing what it had been doing.
That’s exactly why, in the sentence “we’re changing nothing, just keep it running,” the word that interests me is nothing. It isn’t only what you touch that changes. The surroundings change regardless, and if you don’t keep an eye on them, those changes pile up and wait for you.
A small invoice, or a big one
Moving to new versions as you go is dull work. Every so often the version moves up, someone checks that everything still runs, and on it goes. You pay in small pieces that fit in between everyday tasks. It’s called maintenance, and it never makes the papers. Right now I’m moving several projects up like this at once, along with the shared template new ones are created from, so that nothing starts out on the old version.
Whoever puts it off pays too — just once, and more. Every year without an update adds one step, and when someone finally decides to jump, they’re not jumping a step but a whole floor. Often it ends in a rewrite, and while that’s going on, development stops for a few months, because you can’t rebuild and add new things at the same time. How to do a rewrite like that so that users don’t notice is something I describe in the article Rewriting a system so that nobody notices. Better never to get that far.
What the client gets out of it
There are two things you can ask for before anyone starts talking about maintenance as a cost. First, that it’s a line of its own in the quote, not something tucked away somewhere — a dull line in the budget can be planned, a rewrite can’t. Second, that you know what your system runs on and how much longer that version will keep getting fixes. It’s one question, and the answer is a date.
Something will break either way. The difference is that one small thing breaks and you know when and why it happened. And in ten years you still have the same application — just younger than it is today.