Don't know about Bromcom in particular but I find that almost all school MIS "online" versions are basically cobbled-together things run on Windows servers because they still just work like a layer over the original program, which is usually a nightmare of .NET Framework etc. that's actively maintained.
When they take them into the cloud, rather than actually making a full redesign in a web-based language, they just run the same program on the same servers and slap a web interface over it, often served not by any sensible web language but by the original program itself, just hidden away from you, or a mess of DLLs in IIS.
Almost all of them are just proprietary software running on a SQL database (almost exclusively Microsoft, because their developers never know anything else).
All that happens when they "cloud" them is they run a bunch of Windows servers set up in the same say as their prior on-prem servers used to have to be deployed, and often lump a few dozen client's data onto each machine.
If it was a true "web" MIS, you would be able to just deploy a clean server, fold it into a web cluster, it would connect to the clustered database with all their clients data, and it would just work again. The reason they have problems is that that's not how any school MIS I've ever encountered is actually developed on the back end.
The one I used previously to my current school actually had everything reliant on a "report server" (not school reports, but SQL reports) and what happened when you requested certain pages on the web interface was it ran off to the report server (which could be hosted in-house!) and had that run SQL queries, convert the information, and pass it back to the interface (local executable or web). The report server was NOTORIOUSLY unreliable and would jam up all the time because what it was doing was creating an Office document, filling it out with the information from SQL, and then returning a PDF etc. automatically. If there were Office updates, or any new things in Office that caused dialogs to pop up, or an error in the document... it would just hang the service with half-a-dozen instances of Word, etc. running in the background waiting for a response (as a user that you could not log-in interactively as). Changing the default printer to anything other than a Print-to-PDF printer would cause the report server to stop working. Because that's how it made PDFs... automating print to a virtual printer on the same server from Word.
The solution was kill the report server, kill all the Office apps on the server, restart the report server.
It was that common that I made a script to do it for myself, called it "Fix <company name's> mess of a report server AGAIN" and put it on the server desktop. At a technical user group meeting, a dozen people asked me for that script. They all had the same problem. Users would just go to, say, print a register and the whole MIS would grind to a halt for most operations because the Report Server had popped up a Word dialog that nobody could access.
They "went cloud" and forced everyone off on-prem instances eventually. And I discovered, through experimentation and talking to their tech support, that they basically just had the same report servers running in their datacentre and watchdog scripts to kill and restart them if they fell over or failed. Everything was just written in C# still. And that was after YEARS of redesign and upheaval in the migration to cloud.