There are several ways to solve your problems, once you know what your problems are. You mention DHCP exhaustion, but you could fix that with a bigger subnet mask and adding a few hundred allocatable addresses to your DHCP server config. I doubt that is the only issue. I believe you've seen the need to partition a large and growing network. There are several methods, each with advantages and disadvantages. Simplicity is one that comes to mind. Performance. Security. Fault Isolation. Application isolation. It seems that in your case simplicity has been pushed to it's limits. You are going to have to partition your network one way or another. That means you will have different subnets, and to get between subnets you need a router.
VLANs are very useful, but they are effectively extension cords for router ports. Get the routing right first, then the VLANs will come somewhat naturally. FIgure out who your user communities are: Your auditorium WiFi users probably need Internet but not access to your main server, and from a security standpoint should probably be treated as "outside the firewall". Your Admin users are probably closely tied to your server and are mostly trusted. Other user groups in the building probably fall in between those two. Since much of your network is WiFi based and at least the Aerohive AP's don't seem to support multiple SSID's with different VLANs you can't really separate those users into groups - all WiFi is going to end up in one "security bucket", although you can partition for performance. In your case, the simplest partition may be physical first, each building on it's own, then split WiFI from LAN for security and performance reasons if needed, then split key user groups, like admin, into a protected area of their own.
Building splits are easy. Just get a router with enough ports, assign each building an IP address range, and plug the feed to the building into it's own router port. You can do at least some of the partitioning within the building housing the router the same way - physically patch your admin users to one switch and give it's uplink a port on the router. Your AP's go to another switch, and another port. Router ACL's provide a lot of control and security, and you will need them regardless of whether you have VLANs in play or not. If, on the other hand, you have groups that span multiple buildings, or multiple comm closets, VLANs are your friends. You still need the router (or a routing switch) doing the same things. VLANs just allow you to choose the members of each group wherever they may be on your campus. Decide which switch-to-switch connections need to be "trunks" passing multiple VLANs and make sure all of the switches involved use the same VLAN trunking protocols. 802.1Q is pretty standard on most modern switches, but don't take it for granted. Most of your client device connections will be "Port" VLANs where a physical switch port is defined as belonging to a specific VLAN and adds and deletes tags as traffic enters and leaves the switch. This way the device itself needs no knowledge of the VLAN structure, or even that it is a member of one. A special case may be your server. It may well "Live" on multiple VLANs and be connected using it's own 802.1Q "trunk", a single physical link with multiple logical subnets. If you use older, port limited routers they are usually connected the same way, one physical port with multiple subnets represented in VLANs. I would avoid using your server to serve DHCP to any subnets other than those that need to access the server itself for business purposes, though. Use your router or even an old PC dedicated to the task for the "riskier" subnets (or the Aerohive for it's WiFi clients).
Only you can tell how many segments are needed, but the low hanging fruit would be to separate the 3 buildings, then Admin, then WiFi, then possibly other groups. Get a router with at least 6 Gigabit ports (I like Mikrotik bang for the buck, but they are "different" to configure, not hard, but different.) Start out by physically isolating your groups, one group per port on the router, and assign a subnet of appropriate size to each group. DHCP can be handled by the router, a device on each subnet, or forwarded and scoped on another device. The big gotcha here will be printers. Figure out where you are going to (logically) connect them before you start. Most devices can't "find" printers across subnet bounds without help, so if you expect wifi users to hit a printer it's best to put it on the "wifi" set of connections. Desktop users, or those in the buildings all the time, can easily be configured to access printers across subnets, it's the "transient" users that will be effected.
One more thing, if you haven't already, decrease your DHCP lease time, particularly on your WiFI, to 2 hours or less. That should help keep leases for folks that have gone home from blocking newly arrived users.