From what the admin has posted, the problem centers around the MySQL database and the design of the SQL statements used by the vBulletin 3.8.3 app.
Client/server database applications are unique cases and susceptible to performance problems which only manifest years after the system is deployed. The most common cause is not accumulation of software patches.
A good analogy is when designing an airplane, each internal structural component must be meticulously analyzed and constructed for lightest possible weight. That is why you see parts with holes carefully drilled in them. The plane would still be test flown with heavier components, but later in its life when it had to carry heavier loads it could not.
In a client/server database, those components are the SQL queries. When the app is designed, each individual query must be carefully analyzed and made as “lightweight” as possible. IOW the execution plan must be studied and either query, tables or indexes must optimized. If not done, the system will still run, but later in life when heavier loads are demanded it will crash and burn.
In the airplane case by the time that is seen, it’s too late to redesign the myriad of structural components. The designers are long gone, plus the components are pervasively integrated throughout the airframe. You can try to bolt on bigger engines, and sometimes that works.
In the SQL database case the designers of those SQL queries are also long gone, and the many “heavy” queries are pervasively integrated throughout the app. You can try to bolt on bigger hardware - faster CPU, faster disks, more memory, etc. Sometimes this works but doesn’t address the root problem.
The original design and test team for the client/server app must be very diligent about query efficiency and do scalability testing with large numbers of concurrent users, at a high transactional rate with with large data sizes. If not they are essentially planting a performance time bomb which some poor souls years later will have to handle.