At a glance

2016 - 2018
Drupal, Wordpress
Discovery & strategy, Design & user research, Build & migration, Hosting & maintenance, Support & optimisation

The purpose

Helping a large university client consldolidate its disparate websites to deliver improved user experiences and cost reductions.

The players

Our university client is one of Australia’s largest universities, consistently ranked in the top one percent in the world. The university’s IT needs are met via a dedicated central IT department that manages the university’s many websites.

The problem

Over the years, the number of websites had grown organically. In fact, the university had over 25 websites on three different content management systems (CMSs), on different versions, on different infrastructures, and with different vendors. The sites had been built in Joomla, Drupal and WordPress, but different versions of these CMSs were running across the sites (e.g. there were sites on Drupal 6.x, Drupal 7.x and Drupal 8 and it was a similar story for Joomla 1.x, 2.x, 3.x and WordPress 2.x, 3.x, 4.x). This meant the sites were inconsistent, difficult to maintain, and it was becoming increasingly difficult to onboard new sites.

In addition, these different and out-of-date CMSs also meant that security patches weren’t up to date and site security was a serious risk. In fact, there had been several security compromises, which had obviously had a negative impact on the university’s brand and reputation.

As an additional incentive to take action, most of the sites were hosted on servers in the university’s data centre and they needed to free up this space and convert it into lecture theatres.

The university’s IT department went out to tender to find a service provider that could consolidate and rationalise all sites onto the latest, stable versions of each CMS, hosted on a common architecture and infrastructure platform that would be easy (predictable, consistent, etc.) to maintain moving forward.

The solution

This was a large project that required thorough planning and careful execution to deliver the new system.


The first part of our planning process was discovery, working with key stakeholders to make sure we understood the problems and the requirements to solve the problems. From here, we created an inventory of the existing sites and of course business owners. We needed to capture detailed information about each site, including the CMS used (name and version), the patch levels, level of customisation, number of templates, responsiveness, etc.

This inventory gave us a clear picture of site complexity and enabled us to design a migration strategy for each site. While we discovered some sites could be decommissioned, most sites required one of three migration strategies:

1. Upgrade “as-is”: Migrate the site to the latest stable version of the CMS with functionality remaining “as-is”.

2. Rebuild: Rebuild the site from scratch (in some cases this was more time-effective and cost-effective than trying to upgrade the site, particular those that were significantly more complex and/or end-of-life).

3. Content lift: Bring only the content across onto a new and standardised university-branded base template distribution.

The planning process also included working out what the new onboarding procedure would look like and planning the actual build, including the baseline functionality for the new system. To help with visualisation, we created a ‘blueprint’ to demonstrate the different layers in our service design. This blueprint is applied to all three CMSs (i.e. there’s effectively three blueprints, one for Drupal, one for Joomla and one for WordPress). This blueprint was inspired by our work and collaboration with the DoF GovCMS program.

CMS as service Blueprint

The build

Now it was time to build. This phase can be broken into five key elements:

  1. Build target infrastructure platform: AWS Lightsail was the infrastructure service of choice.

  2. Build base distribution per CMS: Build a custom distribution for each CMS. Salsa began with the Drupal 8 distribution using Acquia Lightning and leveraged DTA’s UIKit 2.0 where possible. We then moved on to Wordpress and Joomla.

  3. Build base templates

  4. Build all the tooling (such as automation, provision scripts, patching scripts, release scripts and risk-tracking scripts (e.g. tracking for bad code or security problems))

  5. Migrate sites, following the relevant strategy for each site.

Agile methodologies were used throughout the build to ensure the best delivery possible. It was also important that the university and its sites could continue business-as-usual, so the project took place in the background, ensuring no down-time for sites.

Ongoing maintenance

Salsa Digital is now managing the centralised service, with the university’s IT department referring their internal clients directly to us. They also know that someone is monitoring and maintaining the sites, ensuring the latest site patches and updates are applied when necessary.

The benefits

There are many benefits that are realised with the new managed service:

  • Security — the university’s biggest concern has been resolved with sites being consistently patched and maintained, mitigating the risk of reputation-damaging security compromises.

  • Maintenance — all the sites are now rolled into a new offering that’s being professionally managed by Salsa.

  • Standardisation — a centralised system also brings with it standardisation across sites.

  • Better user experience — the new design templates have been designed to maximise the user experience.

  • Easy for new sites to come on board — the new onboarding system means it’s easy for the university to service new requests for websites.

  • Easy to manage — the new system makes the university’s websites easy to manage, because all the heavy lifting is now done by Salsa.

  • Reduced costs — the centralised system brings cost savings, especially with efficiencies across the internal university websites.