As for whether an insitu redevelopment was realistic, I don't have the info from the discussions or the tech details.
But theres only so much you can do on the same stack, I've heard "PHP has totally changed give it another shot" but it sounds like that means a new website with little portability of existing code, and if there's no separation of concerns or seams in the existing code (which given the code bases age I expect is the case) in the code you're starting from scratch anyway.
And if the data concepts are messy as we keep being told they are, we'll a new dB schema is almost a certainty... And oracle have all but killed MySql. (im assuming lamp here), postgres or Maria? Why did postgres copy oracle's sql/pl-sql mess?
Oh and the A appears to be out dated too, nGinX seems to be the rage
That's pretty much it, a simplification (as I understand it) would be something like:-
1) The DB schema can't be unmessied easily as there's no abstraction between it and the front end code
2) The version of php is old and can't be upgraded without reasonable grunt work (nothing hugely technical, just endless stuff like
https://www.php.net/manual/en/migration70.incompatible.php)
3) There's nothing inherently bad about mysql, changing it for the sake of changing it isn't required and the support path looks good regardless of what Oracle do, mysql isn't going to suddenly disappear
4) Apache/nginx is just a detail. Apache is perfectly serviceable in this regard, we're not worried about serving 10k requests/second here.
5) The OS version is ancient, but can't be upgraded because of the version of php (or something else)
So, how could you fix it?
I disagree that you need to start from scratch, indeed it's far better in situations like this to go for iterative refactoring and abstraction than for a big bang replacement project.
a) Do the grunt work to upgrade php to a modern supported version, which also makes ongoing updates simple
b) This allows you to upgrade mysql and the underlying OS to latest versions, that gets rid of the support/security hangover
c) Design a new DB schema and use this to put in a decent abstraction layer between the front end code and the existing DB. The front end code shouldn't have any references to specific DB columns, ideally do something like making the abstraction layer return JSON and make the front end code parse this JSON to present it to the user - implementing the abstraction against the existing DB will generally lead you to see where the obvious flaws in the schema are
d) This allows you to make easier modifications to the DB schema to move towards your ideal goal, as long as the JSON returned stays in the same format - this is your abstraction
e) This JSON interface can now be handed to a third party developer who can use whatever JS toolkit they want to make the end user website look pretty
Tasks (a) to (d) lend themselves perfectly to a team of volunteers who can slowly chip away at it piece by piece, and there are a whole bunch on here who would have helped out on it had they not gone with handing the whole thing to a third party who started, pretty much, with the front end first and promises to deal with the rest eventually.
More importantly tasks (a) and (b) can be done in isolation (with an anonymised/dummy DB) which makes testing much easier. When there's confidence that the changes are good then this can be swapped in. Irrespective of the grand plans by AUK this work (a+b) needed/needs to be done anyway.
To the point of "well, experts here should step in" - many tried. As I said I had a conversation with the AUK Chair about it in 2018 and offered to help out on the equivalent of a-d above in order to prioritise the parts that really matter and then make (e) much easier, and to move that decision point further on down the line, but the board made a different decision.
Anyway, we'll see what lands in April and what decision the board make between now and then. As others have said I hope they take this as an opportunity to reassess the position. The "cash positive" bit of the comment really pissed me off, as if it is in anyway good that they might only be spending £50 on a £10 meal instead of £100.
I'll continue my AUK membership even though it makes little sense for me (I don't ride many if any Audaxes at the moment, I don't really care about my results being online, I don't really read Arrivee and I'd much rather receive it electronically anyway, and however much I think I may I'm unlikely to ride LEL or PBP again in the near future.) I don't think AUK is at risk at all, as I said before, organisers will still put on rides and riders will still want to ride them - politics about a website doesn't really change any of that.