What do you do with estimating software the business depends on?

Get it off the ageing machine in the cupboard without changing the software itself. Old estimating systems usually encode pricing knowledge that exists nowhere else, so the goal is to preserve the application while removing the hardware dependency, the single point of failure and the impossibility of using it from anywhere else.

This situation is close to universal in construction and joinery, and it is not a sign of neglect. A business builds or buys an estimating system, refines it over a decade until it reflects exactly how that business prices work, and then finds itself dependent on software nobody has updated in years, running on a computer nobody dares reboot. Top Stairs was running a legacy Fortran estimating system, which sounds extreme and is simply the same story with a longer history.

Take the risk seriously before deciding what to do, because it is usually larger than it feels. If that machine dies, can the business quote? Do you have installation media and a licence key for software that shipped before anyone thought about that? Is there anyone alive who knows how to reinstall it? For many businesses the honest answers are no, no and no, which means the estimating capability of the company depends on one ageing hard drive continuing to spin.

The instinct is either to leave it alone or to replace it entirely, and both are usually wrong. Leaving it alone accepts an unmanaged risk to the business's ability to price work. Replacing it wholesale sounds modern and underestimates the real project, which is not buying software but rebuilding the accumulated pricing logic, rates, assemblies and rules that live inside the old system and mostly in one person's head. That project is worth doing eventually and should be entered deliberately rather than in a panic.

The middle path is modernising around the application. Move it onto hosted infrastructure so it runs on a maintained platform rather than a specific old computer, and deliver it to users through something like Azure RemoteApp so it appears in a window on their own machine exactly as before. The software does not change, the people using it see almost no difference, and three things improve immediately: hardware failure stops being existential, the system becomes reachable from anywhere, and it can be backed up and imaged like anything else. That is what we did with Top Stairs.

Whatever route you choose, do the preservation work first because it is cheap and urgent. Take a full image of the current machine so it can be rebuilt if the hardware fails tonight. Find and store the installation media, licence keys and any documentation. Write down what the system depends on, what it connects to and who understands it. That page and that image are the difference between an inconvenience and a company that cannot quote for a fortnight.

Then document the knowledge, which is the part that outlasts any technical decision. The rates, the assemblies, the rules of thumb and the reasons behind them are the actual asset, and they are usually undocumented because the person who built the system has always been there. Extracting that into something readable is valuable whether you modernise, replace or do nothing, and it is the only version of this work that survives a resignation.

Plan the eventual replacement even if it is years away. Put a date on the capital plan and revisit it annually. The point is not to force a premature purchase; it is to stop the decision being made by a hardware failure, which is how these situations usually end, at the worst time and with the least choice. A business that plans replaces on its own terms and can negotiate; a business that does not buys whatever can be implemented fastest.

One further benefit worth mentioning, because it often justifies the work on its own: hosting the application makes it reachable from a site, a client's kitchen table or home. Estimators who can price work without driving back to the office gain real hours, and in a sector where quoting speed frequently decides who wins the job, that is a commercial benefit rather than a convenience.

The honest caveats. Not every legacy application can be hosted, and some behave badly when separated from local hardware, so it needs testing rather than assuming. Hosting does not make unsupported software supported; it contains the risk rather than removing it. And if the software is genuinely holding the business back functionally, modernising the infrastructure around it postpones a decision rather than answering it. If you want yours assessed and preserved properly, call 1800 456 567.