Primary web server, old web server, Moodle server, Mahara server, VoIP servers, print server, file server, Wordpress server, student web server, two database servers and two SharePoint servers. If the latency increase in moving VoIP servers to the cloud isn't acceptable, it would also need to be on-site and be considered "critical" infrastructure. Otherwise, it'd ideally just be yet another thing that "just works" as long as we maintain that Internet connection.
Consider the following as points of further discussion; there's no concrete answers here, just things off the top of my head that you should be thinking about and hashing out with your peers:
You can probably rule out VoIP, along with print server and file server from the cloud. I would suspect that the latency for the VoIP wouldn't be acceptable without alot of work. However, your telco/SIP provider may offer a hosted service of their own that may be worth looking into to. File and print are probably tied into legacy software (image management for example) that rely on LAN speed/latency to work properly. I'm sure you'll hit a number of stumble points the further you look into this.
Databases might be ok, but again the latency may not be acceptable for the applications that use them.
The Web-based servers would likely work fine in a cloud-based environment out-of-the-box (Wordpress, Moodle, etc.) but if they're dependent on core services that at this point only reside within the campus network, you'll need to look at replication or securely accessing these services remotely (which you'll have to do anyways in the form of a private cloud and VPN tunnelling).
And a big cloud misnomer is that people expect their software and services to behave differently just because they're "in the cloud" when unless your services stack has been optimized to take advantage of the distributed architecture that the cloud offers, you will experience single points of failure when an instance goes down.
Of course there's always software licensing that may or may not pose an additional hurdle.
And obviously there's the privacy of information and the safeguarding of said information that may or may not exist on these non-critical services that might get your legal counsel in a tizzy.
And you still have to improve your recovery/continuity of your core services: that's the real root issue here, isn't it? And add to the fact that your core services will now include redundant, prioritized, high-quality Internet connectivity because without that, your cloud services are effectively useless.
The amount of work just determining whether or not any of these "non-critical" services (and it may be non-critical to you, but to another department, may be their most important; service-level agreements might be a good thing here if you don't have any in place already) will be a successful cloud candidate is non-trivial.
The good thing is that you'll be doing a healthy inventory/discovery of your IT infrastructure (which is always beneficial) to determine what you can or cannot do (or at least pilot). And since you're only spending money on cloud run-time fees, your pilot does not require a big outlaying of cash.