Twenty years of building on a music service's system.

2006: a system without a developer

The service's day-to-day work — which pupils are learning which instrument, in which school, with which teacher, and who has which instrument on loan — was managed by a bespoke web application: classic ASP on a SQL Server database, hosted on the council's own servers. It worked, staff knew it well, and the person who had built it was no longer available.

The service needed two things at once: someone to take responsibility for keeping the system running, and a set of enhancements it had been waiting for. We took on both immediately, in that order. Stabilise first, then change.

What we didn't do

We didn't propose a replacement. The application did the job, the database reflected years of real use, and the staff relied on both. Replacing all of that before anything else would have meant months of disruption and expense before the service saw any benefit, and the loss of the detail that made the system fit the work. That decision, taken in 2006, is the reason the system is still in service today.

2009: a modern front end on the same foundations

Three years in, classic ASP was limiting what could sensibly be added. We migrated the front end to ASP.NET and JavaScript, giving staff a more modern look and feel and giving us a platform that further development could be built on. The database, and the working practices around it, carried on unchanged. Users got a better system without having to learn a new one.

The years between: steady improvement

From there the system evolved at the service's pace. We added a communication module, so the service could circulate email and documents to schools, teachers and parents from within the system rather than alongside it. We provided ongoing support and minor adjustments, helped with reporting as the service's needs changed, and, when the council's IT department migrated its servers, we handled the application's side of each move.

None of this was a project with a launch date. It was a long relationship in which the system was never allowed to fall behind the job it was doing.

2026: out of the server room and into the cloud

Two decades on, the council's in-house hosting arrangements were coming to an end. Rather than treat that as the trigger for a rewrite, we reconfigured the hosting: the web application moved to Azure App Service and the database to Azure SQL Database, in our own Azure infrastructure. For the people using it, nothing changed except the address. The hosting problem was solved, backups and resilience came with the platform, and the service carried on without interruption.

Even a lift-and-shift turns up details that need care. One example: after the move, dates typed into forms were being read in US format, because the hosting platform's default regional settings differ from an on-premises Windows server's. Display was fine, which made it easy to miss. One configuration setting fixed it, but it is the kind of thing only experience with the platform finds before the users do.

Modern authentication

As part of the move, access to the system was brought under Microsoft Entra authentication, the same identity platform that underpins Microsoft 365. Entra is about as well-proven as authentication gets: it protects hundreds of millions of accounts worldwide, brings multi-factor authentication and conditional access as standard, and is maintained by a security team far larger than any individual application could ever justify. For a system like this one, it means security that keeps improving without the service having to do anything.

What comes next

With the system safely hosted, we are now looking with the service at further modernisation of the front end: a rebuild one area at a time, around the existing database, with the current application continuing to run until each replacement is in use. The same approach as 2009, on a newer platform.

What this illustrates

• A system that works is an asset. The first job, in 2006 as in 2026, was to protect it, not replace it.
• Modernisation can be done in stages, over years, without the business ever stopping: a new front end in 2009, new modules as needed, a move to the cloud in 2026.
• Moving to the cloud often needs configuration rather than code, and removes the most urgent risks straight away.
• Experience with the platform matters: the regional-settings problem, and the authentication arrangements that a move out of a private network requires, are not on any feature list, and both matter.
• Twenty years is a long time for a bespoke system to stay in service. It happens when someone stays close to it.