: I'd like to chime in for Drupal, which is currently running (for example), the University of Texas at Austin web site. I worked with it for three years at UT before moving to my current

I'd like to chime in for Drupal, which is currently running (for example), the University of Texas at Austin web site. I worked with it for three years at UT before moving to my current university, which is using the half-baked "OmniUpdate".

Drupal is well suited to a higher ed environment. There is a definite learning curve involved (particularly for your tech staff), but it's quite definitely worth it for its supreme flexibility.

Some advantages:

It can interface with your university LDAP via LDAP for Drupal 7
There are a huge variety of modules available to make it do essentially anything you need. The Wysiwyg module is especially important for making it friendlier to content editors. See also Image Assist.
There is a LARGE community of developers working on it, and some highly active forums for support (free, at that).
It's open source. If there's a bug, fix it and submit a patch back.

Some caveats:

New Drupal administrators often go crazy with modules. Resist the urge to install eight bazillion modules. Doing so will degrade your performance. Pick the ones that you really need.
It's written in PHP, so if you have legacy apps written in other languages, they may need to be either ported to PHP, or left to run as they are. Of course, you probably can't achieve 100% platform integration regardless of which CMS you choose; higher ed IT environments are just too heterogeneous for that.
The last time I checked, the permissions model was not as fine-grained as one might hope. However, I haven't played with it much in Drupal 7, so it may have been improved. (See multi-site notes, below).

Some suggestions:

The book Pro Drupal Development is the best book-length treatment for techy types; Chapter 8 on theming is invaluable.

Use Multisite. I cannot stress this enough. A multi-site installation will vastly decrease both your administrative and your technical headaches. Essentially, using a multi-site install lets you have multiple drupal sites, each of which has its own database, permissions, themes, and such, but which share a single set of core files. When a security patch comes out, you can patch the core files ONCE, and it will affect every site you've got. As for administration -- if you have a multisite install, and some small group (such as a student group or an academic program other than a department) needs a web site, you can issue them their own Drupal site, which would have access to a pool of pre-made, approved themes, and also have the option of letting them develop a theme of their own. Lastly, multi-site helps alleviate the problem of the permissions model. Since the permissions are specific to a given site, you can segment your web presence into several related sites that share a single theme, so that you could give full admin privileges to a one user for a specific site (e.g., a department, or such).

At the very least, set up a test site and play with it. There's no software fee, so there's nothing to keep you from trying it out.