Extend or Replace? How to Decide What to Do With an Aging Municipal System

Every public body has at least one system everyone quietly works around. It still does the job. The people who understood it best have moved on. Replacement keeps getting recommended and keeps not getting funded, so it stays on the list and off the budget.

The usual framing offers two choices: leave it alone and hope, or replace it. Replacement is a capital project, with a business case, a competitive process, a year of staff time and a six-figure number. Leaving it alone means the risk keeps getting absorbed by the two or three people who know where the problems are.

There is a third option that rarely gets named: extend it deliberately. Fix the specific things that threaten it, document what lives in people's heads, and plan for a known number of further years. The way to choose between extending and replacing is on evidence.

Age is not the question

"It is fifteen years old" is not a reason to replace anything. Plenty of fifteen-year-old systems run reliably on a stable database and a well-understood codebase. Plenty of four-year-old systems are in serious trouble because the vendor was acquired and the product was quietly abandoned.

The question is condition: what state is the system in, what is likely to fail, and what would it cost to stop that happening?

Signs a system can be extended

Extension is usually the right answer when most of these are true:

• The core still does its job. Staff complain about the interface or the workarounds, not about wrong results.
• The data is reachable. You can get your records out in a usable form, even if it takes effort.
• Someone can change it. The source code exists and can be built, or the vendor's product can still be configured and patched.
• The problems are specific. A slow report, a broken integration, an unsupported server, a missing backup test. A list, not a fog.
• The work it supports has not fundamentally changed. The permit types, the bylaw process, the booking rules are recognisably the ones it was built for.

In that situation, a set of targeted fixes can buy a few more years for a fraction of what replacement costs, and without the disruption of retraining staff and migrating data.

Signs a system should be replaced

Replacement is usually the right answer when one or more of these is true:

• The foundation cannot be secured. It depends on an operating system, database or runtime that is out of support, and there is no reasonable path to move it onto a supported one.
• Nobody can change it. The vendor is gone, there is no source code, and the system cannot be configured to meet a new legal or policy requirement you have to meet.
• The work has moved on. The process it was built for no longer exists in that form, and the workarounds now carry more of the load than the system does.
• Extension would cost nearly as much as replacement. At that point you are paying replacement prices for an older system.

Even then, knowing exactly why it needs replacing makes the replacement business case far stronger, because it rests on documented condition rather than on general unease.

Make the decision on paper

The most useful single step is to get the system's condition written down before anyone commits money to either path. That is what an application condition assessment is for: a short, fixed-price, read-only review of one system that ends in a report covering how much working life it has left, which problems are genuinely risky, and what each fix would cost.

It does three things for the decision:

1. It turns "we think it needs work" into evidence. A council, a board or a finance committee can act on a written condition report. They cannot act on a hunch.
2. It separates the dangerous from the ugly. That alone often shrinks the problem, because most of what makes an old system look bad is cosmetic.
3. It prices the path it recommends. If extension is the answer, you have a priced list to work from. If replacement is the honest answer, the report says so, and you go into the capital process with documented condition behind you.

Watch for conflicts of interest

Whoever tells you a system must be replaced should not be the only party who profits from replacing it. Ask any supplier, including us, to disclose what follow-on work they would hope to win, and make sure you own the assessment outright and can hand it to anyone.

We have an interest too: we would hope to do the extension work. That is why our assessment is fixed at $6,500, $9,750 or $14,500, you own the report outright, extension work is priced afterwards as a ceiling that can come in lower but never higher, and the report says "replace it" when that is the honest answer. The details are on the government page.

A simple rule of thumb

If you can describe your system's problems as a list, it can probably be extended. If you can only describe them as a feeling, you need an assessment before you can know. And if the list includes "the technology it runs on cannot be supported or secured," start planning the replacement, ideally with a few extra years bought on the old system while you do.

How you buy any of this is set by your own purchasing bylaw or policy, not by a vendor. Check your threshold with your procurement office. If you want a second opinion on a specific system, send us a note with a few sentences about it.