You do not give enough detail in your original post to help us judge whether the (radically different) approach that you propose to use here, really makes business sense. Which is not a point-of-view anything like programming.
Mere repetition ... even 50 or 100 times over ... is not necessarily a bad thing, especially if some of the PHP and/or some of the stored procedure code is not exactly the same. (Did you, yourself, write 100% of this stuff?) Nor does it matter that PHP was used ... it is a programming-language, as is a stored procedure. What you get for your repetition in this case is a complete lack of coupling between all 50 instances of a system that, right now, is known to meet the needs of 50-100 users. If either of these two programming-driven components, within any of these “repeated” food-chains, does something that is not exactly like every single one of the others, then your present approach can do that without disruption. And-d-d-d-dd... it runs on Windows.
You might say that it sucks. But you’re the only one who has to see that. 50-100 other people see that it runs. No matter what the Marketing Department introduces to us as its next must-have requirement, all we have to do now is to set up the 51st set of files, initially based on the 50th. There is a lot to be said for being able to do such a thing, and in about an hour.
Okay, so you want to learn Mojolicious (did you do a selective comparison or – just asking a fair and very-relevant question – did you pick that one out of a hat?), and Linux. Grok that. But if this be the case, then I’d suggest that you start by building the Mojolicious example-app on a virtual-machine that runs Linux, and to reconsider your options for any future work only after doing all that. Don’t shack-up a future business requirement to it. Not yet, anyway. (Try running Perl and Mojolicious in the Windows environment, too. It works.)