Running line-of-business software that still needs a server

Why some software still needs a server

Plenty of software that runs NZ businesses was written before the cloud became normal. Job costing systems for builders, practice management for accountants and lawyers, dental and medical software, stock and manufacturing systems, and some payroll packages use a database on a central Windows machine, with a program installed on every PC that talks to it. That design assumes the PCs and the server are on the same fast office network.

These systems are often deeply embedded. They hold years of history, staff know them well, and switching would mean retraining and data conversion. So even when everything else has moved to Microsoft 365 or Google Workspace, this one application keeps a server alive in the cupboard, along with its backups, patching and replacement cycle.

Option one: keep a small onsite server

If nearly everyone works in the office and the application performs well locally, a modest onsite server can still be the most practical answer. It no longer needs to be a big multi-purpose machine, because files and email live elsewhere. A compact server with mirrored drives, a UPS, proper backups to an off-site location and monthly patching can be enough. The weakness is remote access. Staff working from home will need a VPN or remote desktop connection to the office, and some database applications behave badly over a VPN, with slow screens or corrupted records if the connection drops mid-save. Test that properly before relying on it.

Option two: rent a hosted server

The server, database and application can run on a virtual machine in Azure or another data centre. Users then connect through a hosted desktop or remote app, so the program runs right beside its database and only the screen travels over the internet. That usually performs well from home, a client site or a second branch, and it removes the physical hardware from your office. Check two things first. Ask the vendor in writing whether they support this setup, because some refuse to help with problems on hosting they did not approve. And price the full monthly cost, including the server, storage, backup, remote desktop licensing and management, against keeping a box onsite.

Option three: the vendor's cloud edition

Many vendors now offer a hosted or web version of their product, where they run the servers and you pay a subscription. This is often the simplest long-term path, because upgrades, backups and database maintenance become the vendor's job. The trade-off is that cloud editions sometimes lack features of the desktop version, cost more per user, or store data overseas.

Ask for a feature comparison, a trial with your own data, a clear explanation of where data is stored, and the process for exporting everything if you leave. Talk to another business of similar size using the cloud edition before you commit, if the vendor can put you in touch.

Option four: replace the software

Sometimes the server question reveals that the application itself is past its best. If the vendor has stopped developing it, struggles with current Windows versions or will not support any form of remote use, it may be time to look at alternatives built for the cloud. That is a bigger project, involving data conversion and retraining, but it removes the server issue permanently. Do not decide this in a hurry. Run the shortlisted products side by side with real scenarios from your business, check that historical data can be converted, and plan the changeover around a quiet period rather than end of financial year.

How to choose

Start with three questions. Where do your users work from, and how often? What does the vendor support today and plan to support in two years? What is the total five-year cost of each option, including the work to run it? If most people are office-based and the vendor is desktop-only, an onsite server is sensible. If staff are spread out, hosting or a cloud edition usually wins.

Whichever path you choose, back up the application's database separately, using a method the vendor approves, and test a restore at least once a year. A copy of the server is not the same as a working copy of the database, and the difference only becomes obvious when you need it.

Finally, write the decision down: which option you chose, why, what the vendor said, and when you will look at it again. Software roadmaps change, and a vendor that is desktop-only today may launch a cloud edition next year. A short note in your IT documentation means the next review starts from facts rather than memory, and nobody repeats the same research in three years.