Well, it's been over a month since we deployed our new Drupal-backed site, so I decided to share it and general experiences & problems we've had with a migration to Drupal for a higher education website. We deployed two separate websites; first, the BYU Computer Science Alumni Association website, which we deployed several months ago as a 'test' website, and then the main BYU Computer Science Department website. The department website had previously been running an old conglomeration of scripts that had been accumulating from the various webmasters over the years (some stuff was created back in the days of PHP 3!) There was no concept of CMS whatsoever, but there were a TON of legacy custom utilities (mostly private for faculty and staff) that needed to also survive the migration.

We chose drupal after evaluating various alternatives (including Joomla). The main influences on our decision were A) The module and theme system appeared to be the easiest to customize to our needs. B) The sheer amount of documentation. Drupal is definitely one of the best documented open-source projects we've seen.

It took us about 6 months from the time we started development to deployment (including learning time of being new to drupal). We actually had the majority of the work done within 4 months, but various committees dragged their heals on approval. :)

The department website now runs Drupal 4.7, with a ton of custom modules for integration into legacy code (as well as a bunch of completely rewritten stuff). Some of the modules we currently run are: actions, advanced_menu, atom, autotimezone, calendar, cck, email, event, fieldgroup, fileshare, image, image_attach, image_exact, image_gallery, imagefield, imce, jscalendar, link, node_privacy_byrole, nodeimageblock, nodequeue, path_redirect, pathauto, sched_act, securepages, tinymce, views, and workflow. Some of these have some custom patches (some of which have been submitted to the modules). We wrote a custom authentication module to tie accounts into our local LDAP and the university-wide LDAP servers. We make a lot of use of the Views and CCK modules, although we also have created a number of node types manually. Our front page is powered by no less than 3 views and 6 blocks.

The theme we use is the university-designed theme that our old site also used. It was quite easy to update it to the various drupal-isms. We found the theme system extremely flexible to our needs, even we were doing things that drupal did not expect us to be doing (such as the fact that our front page is not controlled by the normal Front Page publish option, but by a range of published dates from the event module).

Our biggest challenge was our custom authentication. The majority of it we were able to accomplish using a patch that is now in 5.0 and an authentication module. We did have to put in an additional snippet into the drupal session management in order to use our cross-site session management that we use within the department. Otherwise, the authentication module was fairly easy to create.

Our other big challenge, and one that we still haven't solved, is the menu. Our department wishes to have multiple menu links in various submenus to the same page...And drupal gets very confused with this. We are currently trying to work out a solution for this.

We do have some complaints about some of the administration UI, but 5.0 seems like it fixes at least some of that. (Of course, it's going to take us quite a while of testing 5.0 with all our custom modules and such before we deploy a 5.0 version.)

We've been very happy so far with our new Drupal-based website, and so has our faculty and staff, who are now learning that being able to edit website content themselves, rather than coming to the webmasters for every little change, is very convenient and easy. We do wish that something could be done about the sheer amount of stuff on the node add/edit forms, as it can be somewhat overwhelming to less technical users such as our secretaries (and, believe it or not, some CS faculty even get confused). Some of this problem is module bloat, and the collapsible fieldsets do help a lot, which is why we really don't have any idea of what to do about it. It's just our observation.

As webmasters, some of our favorite features include: the error log (invaluable), the awesomeness that is the Views module, and the great customization of the access control/roles. Future development will continue with internal modules for various department tasks, some possible patches to add some features we'd like to the Views module, fixing our menu, and hopefully moving our course listing system into drupal nodes (currently a legacy system).

Hopefully, this post will provide someone considering a drupal migration with some valuable insight. Thanks Drupal, for a great platform for website development.

Drupal version: Drupal 4.7.x