Taking the pain out of managing multiple websites

Dan McNamara's picture
Feb 25th 2016Managing Director

We speak to a lot of companies that manage more than one website, often up to a dozen or more. Sometimes it's worth consolidating a messy digital footprint and bringing the focus back to an all-encompassing central site, but sometimes there are very good reasons to have multiple sites: perhaps a company has diversified into different audience verticals, or maybe they have different divisions or departments that need an independent presence.

In these cases we often find that an organisation's time and budget is stretched as they try to support and maintain a fragmented digital presence. If they are lucky enough to have sites on the same platform, then bug fixes and security updates may be similar, but will still need to be applied multiple times on a per-site basis. If sites have been built on different platforms over the years, then the situation becomes even more complex and a raft of suppliers with different specialisms may be needed to hold it all together. 

So, what can be done in these cases? There’s often sound business logic behind having multiple sites, but if they can’t be sustainably managed, what’s the solution? 

We were presented with a similar challenge when we started working with Bath and North East Somerset Council’s world-renowned Heritage Services division. They had a portfolio of five websites promoting their key heritage attractions, with the Roman Baths website as the flagship. The Roman Baths site was by far the most popular and most complex of the five, unsurprisingly since it showcases one of the most popular tourist attractions in the UK. The other sites were smaller and contained less functionality, but each served a similar purpose: to promote a heritage attraction in Bath. 

The key to developing a sustainable digital footprint was to shift the way we thought about the problem. Rather than thinking about five websites, we began to think about a single website with five different ‘facades’. Since the sites shared a lot of key functionality, we wanted to create a central code-base that would power all five sites, but still allow each to have their own individual ‘look and feel’, web address, content and functional variations. The Drupal ‘multi-site’ approach allowed us to do just that. 

We launched the five sites in quick succession, starting with the ‘master’ Roman Baths site. The subsequent sites were developed at a fraction of the cost of the first, as the functional elements were already in place and thoroughly tested. Each of the smaller sites just needed a new theme and some configuration and they were ready to launch.

Maintaining the sites has been a breeze, since module upgrades and security patches need only be done once to apply to all five sites. The client has also taken advantage of the built-in flexibility of the system to launch a sixth site. Building it into the Drupal multi-site system means it's been incredibly cost-effective to launch and even more-so to maintain. 

The six sites are hosted on Acquia’s market-leading enterprise cloud platform, where the costs are calculated ‘per codebase’ rather than ‘per site’, So again it's a win-win, with the client enjoying Acquia’s unrivalled SLA and support across all six sites for a single fee. 

The multi-site approach worked nicely for Bath and North East Somerset Council, but it has plenty more potential applications. Online publishers that deliver numerous news sites in different niches would perhaps benefit most, but it could equally apply in the Higher Eduction, Public Sector or NGO spaces. Sure, there are situations where the multi-site approach wouldn’t work so well, like where the sites have significant functional differences, or where the requirements are likely to diversify in future, but in the right circumstances a single code-base to power multiple sites can save a lot of time, budget and frustration.

Darren Whittington's picture

You may also like...

Caching beyond the norm in Drupal 7

Darren Whittington, Feb 9th 2016
When developing in a drupal centric environment there are two general methods used to cache information on the system in modules, these can be used...


Kevin Reynen - Lead Software Engineer

Feb 25th 2016 - 4:02pmreply
Kevin Reynen - Lead Software Engineer's picture

Multisite works well for ~10 sites. Beyond that you run into issues when updating. A single code base means all sites change the code at the same time, but it can take several minutes to run all of the update hooks included in an update. During this window, a site with updated code that hasn't made database schema changes may return fatal errors for requests. When you are running 600+ sites like we do at the University of Colorado, even if we can process all updates in < 1 minute per site, that's still a long time from updating the code until the last site processes the last update hook. That is why we developed and maintain https://www.drupal.org/project/dslm. All of the benefits of multisite with the added bonus of rolling updates.

Dan McNamara

Apr 20th 2016 - 9:04amreply
Dan McNamara's picture

Thanks for your comment Kevin. Wow, running 600+ sites is an impressive feat in itself! dslm looks like a really interesting solution - we'll check it out and will certainly bear it in mind if we need to scale up from the Multisite approach. 

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Related Blogs

Sophie Shanahan-Kluth's picture
Mark Pavlitski's picture
Rick Donohoe's picture