Migrating to WordPress as your University CMS

Presented at #PSEWEB 2015 – McGill University, Montreal, Quebec

In 2014, Brescia University College migrated our full range of web sites from a mix of static HTML and expensive proprietary systems to WordPress as a CMS. This session looked at the pros and cons of switching to WordPress, the nuts and ’bots of migration, and the technical and human impact WordPress has had on our operations. We covered many details of our experience – process tips, plug-in recommendations, pitfalls to avoid and the surprising outcomes we’ve experienced. The session was attended by both managerial and technical team members interested in WordPress as a full CMS option.

Here is the unpacked version of the presentation, with added notes and links, plus a few bonus slides and a good sprinkling of opinion and commentary to spice things up.


Feel free to follow-up with any migration tips, questions or comments on Twitter @danbashaw, by email at dan.bashaw@pathwisesolutions.com, or in the comment section below.




I think the issues we were encountering as shown on these first three slides are typical of institutions where new sites and services are created in response to high-level needs, but the time to maintain them is limited or non-existent.

The old sites, apps and features are left operational, and add to confusion on the part of the users, and frustration on the part of staff who see the digital edifice tottering, but can’t take action to shore it up due to time or mandate constraints.


The ‘master plan’ slide is intentionally shown as a bit of a random walk, as the process we undertook was very adaptive. We would try some things, assess the results, and try some more. The overall intention was to follow a path like the one shown, though there were many diversions along the way.

In the maintenance phase shown at the end of the diagram we moved from a waterfall-style migration process to an agile approach to maintenance after the rollout of the new site. WordPress is very well adapted to agile. Since site content is updated in real time, the user expectation is that site features and design tweaks will be more or less continuous as well.

In our case, while more complex changes are carried out on a staging server which is periodically refreshed with a backload of the production database, minor changes are done in off-peak times directly on the production site after a snapshot backup is made. (Larger institutions will most likely enforce a strict staging-first discipline, as the disruption of having to roll back a production server are much higher with a greater volume of users.)


I found the content audit tools helpful mainly to generate large stacks of hardcopy that I could wave around in meetings to focus attention on the need for action. Very McCarthyite… “I have here a list of 4000 web pages that are known to be subverting good order on our website…”

I would actually have liked to work more with CAT (www.content-insight.com), and utilize it for a structured content analysis process, but institutional budgets and project time constraints did not allow a content-focused approach this time around.

Choosing our CMS

Note: For brevity – and perhaps for fear of being torn apart by a Cascade of enraged Echidnas in a Terminal frenzy – I omitted these next couple of rather opinionated slides on the strengths and weaknesses of various CMS from the in-person presentation. 

Choosing a CMS technology can be complex if one is focused intently on feature comparison, but a bit of sanity filtering can simplify the process and reduce the field.

  1. Apply the “I should pay you for this, why?” filter.
  2. Apply the 1% filter.

Proprietary CMS (“I should pay you for this, why?”)

On the proprietary side, I think the obligation is on the vendor to make a case that can stand up to serious scrutiny as to why their product serves the institution better than the open source options. Since this case seems harder to make each year, it is very rare for me to recommend a proprietary CMS. I can think of only a few special situations – such as a fully Microsoft ASP.NET organization – where a solid argument can be made for going proprietary.

In PSE however, proprietary systems do have a strong following at some levels, so your institution may have them on the table as an option to assess. Two PSE CMS vendors were represented at PSEWEB:

For Brescia though, I could see no compelling case to be made for a proprietary solution. We were looking at open source options.

Open Source CMS for PSE (The 1% Filter)

In North American academic institutions, the two contending open source CMS are Drupal and WordPress.

But what about Typo3, MODX, and of course that long time Higher Ed favourite DIYJavaCrap, you ask? You see, I know this guy who does great things with Xoops…

Don’t go there. All of these have North American market shares topping out in the low single digits – sometimes preceded by zeros. That translates to a diminutive developer base, and therefore often lackluster development velocity. (Not to mention the look of pained incomprehension on the part of the vendors that you go to for support when you need help after the sole developer who knows the system gets hit by a bus.)

In my view, it really does not matter if any particular small CMS is the best, most OO, most elegant example of crystal pure code on the planet… it is not a good choice for your institutional website, due to its limited support ecosystem.

After applying the 1% filter, the two systems left standing are Drupal and WordPress. (Globally, Joomla also makes the cut, but in North America, it falls below my comfort threshold, particularly in the PSE sector.)

In functional terms, WordPress and Drupal are almost identical, as they are both LAMP-based content management systems that take very similar approaches to templating and extension with modular code. What you can build in one, you can build in the other.

In cultural and user experience terms though, they are very different:



  1. Drupal is very invested in the culture of free. It is rare to find a Drupal module that you will have to pay for. WordPress on the other hand has a much more mercantile culture, with most plugins costing some small amount of money up front, with a small optional support plan.
  2. Drupal out of the box offers content types, views (configurable displays of types), and custom fields. It biases towards ‘chunky’ semantic data. WordPress prefers ‘blobby’ data, with post and page content types defaulting to a single rich text field. You can chunk your data in WordPress just as you can in Drupal, but the in-your-face default is not to do so.
  3. Partly due to #2 above, Drupal is oriented towards building more complex relational sites, and WordPress skews towards building simpler less structured sites. Complexity cuts both ways though, since Drupal is by default more complex for writers, editors and admins to learn and use. WordPress tends to simplify, Drupal tends to complicate.
  4. The target market for Drupal is primarily coders, while for WordPress it is primarily writers and editors. One result of this is that a Drupal site will tend to require code and techie chops for maintenance and enhancement, whereas WordPress will rarely require admins and site builders to dive into code.

I will certainly agree with anyone who says that the four generalizations above are  incorrect – remember that both technically and practically, what you can build in Drupal you can also build in WordPress, and vice versa – but they are very true to the actual experience of users building a site with a default install of either CMS.

  1. The final number in the slide is the overall market penetration of each system. WordPress has a 67% CMS market share, and Drupal has a 5% share. Or, according to other sources, WordPress has 48% and Drupal has 3%. What is interesting in both automated surveys is that the ratio remains the same – There are about 12 times as many sites running WordPress as Drupal.

This statistical point has real-world implications: WordPress vendors are ubiquitous and inexpensive as compared to their Drupal equivalents, leading to lower build and maintenance costs. Likewise, future vendor and hosting support for WordPress is assured, as a result of sheer market mass and momentum. Market dominance at this level creates its own reality.

Note: I highly recommend consulting with Digital Echidna if you want to explore using Drupal as your CMS. If you want to discuss adopting WordPress, feel free to contact me at PathWise Solutions Inc. for a chat.

Here are the factors we considered as we looks at the pros and cons:


For Brescia, WordPress was the clear winner in ease of training and ease of use by our writers and editors, technical simplicity for the in-house web maintainer, and future support and enhancement by vendors.


Pilot Projects

We then carried out some pilot projects using WordPress to enhance the existing Brescia web presence, and feel out whether it was as good a fit as we thought.




We used Mandrill to solve form notification deliverability problems we ran into when dealing with form recipients within the Western University network. Since we were not running these sites on Western IT servers, we were finding ourselves periodically blocked by either SPF rules or Western’s hyperactive spam filters, who would throw a heuristic fit and start treating our forms as spam. Using Mandrill, a transactional email service from MailChimp, easily resolved both issues.


We worked with Joe Murray Associates on this project. JMA were the consultants installing, configuring and customizing CiviCRM on WordPress. Joe literally wrote the book on CiviCRM, so they are a solid source of expertise.




Converge, a well-known Higher Ed communications and branding consultancy,  were already involved in a brand refresh for Brescia, and extended this to include a redesign of the Brescia home page.




We are using multisite installs of WordPress for the main site, and another for ancillary sites.

On the main site we are using a subdirectory multisite, so each main section of the site is technically a separate subsite: brescia.uwo.ca (Home page), brescia.uwo.ca/academics, brescia.uwo.ca/admissions, and so on. This allows individual admin, editor and writer roles for each section, as well as enabling each to use a distinct set of plugins and themes while still centralizing maintenance and updates.

In terms of content structure, we decided to simplify the migration by using the default Post and Page content types, rather than rationalizing our unstructured content into more semantic custom content types.

In retrospect, I could have created custom content types for a couple of our more structured page types, in particular faculty bios and program descriptions. These relatively structured pages would be excellent candidates for custom post types utilizing custom fields for the content.


Starting out with CPT UI and ACF offers a good free introduction to creating custom content types in WordPress. Among the more advanced tools, I’m particularly interested in experimenting with Pods.




  • eCreative Studios (We used eCreative as our theme developer for the Brescia migration project, and I was very impressed with their efficiency, skill, and ability to handle the more unique elements of theming PSE web sites.)


Note: Here is a zipped code sample of the menu-from-page-hierarchy trick, kindly supplied by Karen Laansoo at eCreative, in case you are interested in exactly how that was accomplished: Inner Navigation Sample.

While we are on the topic of code, even non-coding WordPress site admins and side builders would do well to pick up a copy of the most recent edition of Professional WordPress: Design and Development. I personally consider it the best overview available in book form on the basics and best practices for WordPress. (Of course the Codex is the ultimate source on all things WordPress.)


The last bullet, on preferring a commercial orientation in a plugin developer, is all about sustainability. A WordPress vendor who is deriving income from their plugin will often be more sustainable and engaged than one who is not. (This is very different than the situation in the Drupal world, where the strongest modules tend to be those with the strongest volunteer developer community behind them, and overtly commercial modules are very, very rare.)








If you decide to join WPMU, you will probably want to make them your first stop when seeking out new plugins, so that you get the best value possible from your membership.

I am a bit leery of the lock-in effect that can occur when you have several mission-critical eggs in the WPMU basket though… this is one WordPress vendor that can easily become part of your infrastructure, so if you decide to drop your membership at some point, there can be a switching cost as you replace several key plugins at once. At Brescia we do use WPMU, especially their Appointments+ Booking System.

Content Processes

Note This topic was also largely dropped from the in-person presentation, due to time constraints, and as being a bit lateral to the main focus of the talk..




If you are interested in more obsessive Trello love, I also wax enthusiastic about the use of Trello for Work/Study student coordination in a blog post here: Trello for Self-managing Teams.



  • WPCloud.ca (My preferred Canadian WordPress managed hosting service. Brilliant support.)
  • Pantheon.io  (You may also want to check out this popular alternative, with strong Dev > Staging > Test workflow support, if Canadian hosting is not an institutional preference.)


Oh, and you never got to see the mandatory Classic Cat Meme, so here is the concluding slide!


Please connect with any migration tips, questions or comments on Twitter @danbashaw, by email at dan.bashaw@pathwisesolutions.com, or right now, below.