A decade for the switch
I don't remember exactly, but the idea to deploy a decent content management system for the entire web presence of the University of Helsinki is probably 10 years old. I had reserved the domain jeltsch.org in May 2003 (after I had completed my PhD) to host my private web site. The oldest snapshot of my web site on the internet archive dates back to December of the same year. Like the Helsinki University IT staff, I realized that updating a web site by updating individual html pages is very time-consuming. In 2006, I was - exactly like the University of Helsinki IT services - looking for a content management system (CMS). At the university, they used Dreamweaver to generate the html pages; I used whatever text editor I had available. After comparing different options, both Helsinki University IT and myself came to the same conclusion to chose Drupal as the content management system for our web sites.
Moving to Drupal
Moving to Drupal (version 4.6) took me a few weeks, but in the end of 2006, my first Drupal site went online. Starting from that time, adding content to my web site became very easy. I avoided upgrading Drupal and skipped version 6. As I had anticipated, the upgrade to version 7 caused me a major headache (upgrading is supposedly much easier nowadays). Moving to drupal took the University of Helsinki many years, but finally in 2016/2017, the move was/is happening. Barack Obama was much faster: in the autumn of 2009, hardly half a year after he had become president, the switch of whitehouse.gov from a proprietary solution to Drupal was complete.
Is Drupal 7 old?
Here at our university, dead lines must have been moved multiple times and similar to the Western Metro Extension to Espoo, the move likely became much more expensive than planned. The university is using at the moment Drupal version 7, which was relased more than 6 years ago in January 2011. While Drupal 8 is already out since November 2015, the good new is that Drupal 7 remains officially the Long Term Support (LTS) version and thus will receive security updates for many years to come (I would guess for at least five years or so). About 85% of all Drupal sites are still running Drupal 7 and apparently, this number has not shown any signs of decline yet.
The move is not complete yet
I moved my lab's web pages in the beginning of this year when the possibility was made available. However, our B3P core facility still runs on "handwritten" html code as we have not gotten permission to move these sites to Drupal (IT is waiting for the HiLIFE research infrastructure funding decisions).
Meanwhile, 2.3% of all web sites worldwide use Drupal.
However, the system is not free of bugs. Owing to security concerns (PHP security is considered to be porous like a sponge), most of the flexibility that Drupal offers is not available to the content providers: e.g. full HTML or PHP code within node bodies is disabled, which makes the implementation of dynamic content challenging. Luckily, the system has an achilles heel and that is its use of RSS feeds.
RSS fees to the rescue
RSS feeds with user-provided URLs can be integrated into most pages and surprisingly they allow unfiltered display of html content (including images and css styles). This is the way how I implemented our dynamically updated list of enzymes (https://www.helsinki.fi/en/researchgroups/lymphangiogenesis-research-and...) and our list of publications (which displays separate feeds from zotero.org, e.g. a list of featured publications or a list of review articles. Unfortuantely, the feed module doesn't accept standard atom feeds, but only "old-fashioned" RSS feeeds, which required me to pipe the Atom feed from Zotero through a python script before it can be fetched by the site visitor's browser.
The other problem is that the site loads fairly slow. If visitors look for content the site must load with 3 seconds or the visitor is lost. Hopefully the site will scale well since many research groups have not made the switch yet. And it loads slowly despite it using a Varnish Cache. Unfortuantely, the Varnish Cache delays updates from becoming public sometimes for many hours (sometimes even over night). In the 21st century, that is not acceptable. I have set the maximal cache life time to 1 hours for my private Drupal site. The 3 second loading time is likely the best compromise they could find...