What Is an Application Condition Assessment?

Public bodies already know how to look after things they cannot afford to replace. A bridge gets a condition assessment. So does a roof, a pump station, a fleet. Someone qualified looks at the asset as it stands, rates it, names what is likely to fail, and prices the repairs that buy the most remaining life. Nobody treats that as the first step of a replacement project. It is ordinary asset management, and it comes out of an ordinary budget.

Software is rarely treated that way. The permitting system, the bylaw tracker, the recreation booking system, the finance add-on that three people understand: these tend to sit in one of two states. Either nobody looks at them at all, or the only conversation on offer is replacement, which arrives as a capital project with a business case, a competition and a six-figure number. An application condition assessment is the missing middle step.

The short definition

An application condition assessment is a fixed-price, read-only review of one software system. It ends in a written report that answers three questions:

1. How much working life does this system have left? Not forever, and not "it is old so it must go." An honest view of how long it can stay safely in service, and what would shorten that.
2. Which problems actually matter? Most older systems are full of things that look alarming and do not matter, and contain one or two things that look fine and will take a service down. Separating those is the core of the work.
3. What would it cost to add more years? A priced list of discrete fixes, each weighed against the working life it is likely to buy, including "leave this alone" where that is the right answer.

If the honest answer is that a system should be replaced rather than repaired, a good assessment says so, and prices that path too.

What an assessment looks at

The scope varies with the system, but a useful assessment covers at least:

• What the system is. Its purpose, who relies on it, what it connects to, and what would stop if it stopped. Written in plain language, because the report has to make sense to someone who has never logged in.
• Its technical footing. The language and framework it was written in, the database, the operating system and server it runs on, and whether each of those is still supported by whoever makes it.
• Its integrations. GIS, payments, document management, identity, email, the nightly file that some other system expects. Integrations are where older systems most often fail quietly.
• Who can still change it. Whether the source code exists and can be built, whether there is documentation, and how much of the system's behaviour lives only in the heads of the two or three people who keep it running.
• Operational risk. Backups and whether a restore has ever been tested, access control, logging, and the single points of failure.
• Security exposure. Unsupported components with known vulnerabilities, and any handling of personal information your privacy office should review.

What it does not do

The value of an assessment comes as much from its limits as from its scope.

• It does not change the system. Read-only access, or a copy in an environment you control. Nothing about how the system runs changes while the work is underway.
• It does not migrate data, retrain staff or require a project team. A small amount of time from one knowledgeable person is usually enough.
• It is not a technology strategy. It answers whether this system makes it to the next budget cycle without taking a service down, not what your technology should look like in 2035.
• It is not a sales document for its own follow-on work. You should own the report outright and be free to hand it to any supplier, or to your own staff, to act on.

What the report should contain

The report is the product, so it is worth being specific about it before you buy. A good one is a document someone can forward upward without editing, and it survives being read by a councillor who was not in the room. That usually means:

• A one-page plain-language description of the system.
• A small set of condition ratings across defined dimensions, skimmable in thirty seconds.
• Failure modes, named and ranked: what breaks, under what conditions, with what consequence for service delivery.
• A clear separation between what is genuinely risky and what is merely untidy.
• A prioritized, individually priced list of fixes, so the next decision is already made simple.
• The assumptions and uncertainties behind any judgment about remaining life, stated rather than buried.

How long it takes and what it costs

For one system, expect one to four weeks depending on its size, with two to three typical, and the price should be fixed before work starts. Bluestone's own assessment is fixed at $6,500, $9,750 or $14,500 depending on how tangled the system is, with any remediation quoted afterwards as a ceiling that cannot move upward. The full breakdown is on the assessment page.

Whatever supplier you use, the size of the purchase matters for a public body: an assessment like this is usually small enough to fit an operating budget a director already controls. How it has to be bought is set by your own purchasing bylaw or policy, not by any vendor, so check your threshold with your procurement office and buy it whichever way that policy requires.

When an assessment makes sense

An assessment is worth commissioning when at least one of these is true:

• The vendor has been acquired, has stopped supporting your version, or no longer exists.
• The licence renewal now costs more than the system is worth to you.
• The people who understood the system best have retired or moved on.
• Staff have built workarounds around it that nobody has written down.
• Replacement keeps being recommended but has never been funded.

In each case the question is the same one you would ask of a bridge: how long can we keep this safely in service, and what is the cheapest way to get the most years out of it? The cheapest system you will ever operate is usually the one you already own, maintained properly.

If you want to see what this looks like for a specific system, send us a note describing it in a few sentences. The buyer's checklist covers the questions procurement will ask, and our supplier facts cover the registrations and insurance behind them.