University of Missouri manages web operations at scale

The first school of journalism. The first public US university west of the Mississippi River. The architect of homecoming, the long-standing, annual fall tradition of welcoming back the higher education community and its alumni to campus. The University of Missouri (Mizzou)—founded in 1839—takes pride not only in these firsts, but in its students’ (currently 31,121, representing all 50 states and more than 100 countries) and faculty’s contributions, achievements, and innovation.

With stepping up to tackle complex challenges in their DNA, the groundbreaking research university’s MU Marketing and Communications team embarked on an amazing, six-year journey to eliminate technical debt; centralize and standardize its decades-old, organically grown web environments; and ultimately turn its attention to the business of expert-level client consultancy and brand stewardship.

The original case for moving to centralized web operations

Let’s start Mizzou’s story with a history lesson. The university’s websites had been completely decentralized. Any school, any division, any department with funding or a purchasing card could hire their own developer. Or set up their own server. Or purchase third-party hosting, then set up a website.

All this—and 13 content management systems, hosting platforms, lack of standards, inconsistent processes, and interdepartmental dependencies—prompted Mizzou Director of Digital Service, Kevin Bailey, MU Marketing and Communications and the university’s Central IT Group to formulate a strategy that would move away from local infrastructure to a cloud-based approach. An approach that would enable them to implement standards. Enforce security and compliance policies (including the mandate to protect student and university data). And align brand and user experience across their web properties.

When diversity creates barriers

The university’s Central IT Group tasked Bailey and his web development team with moving 25 percent of its 1,600 on-premises WordPress, Drupal, and static HTML websites to the cloud. This proliferation of diverse websites required support. The web team wasn’t notified if a site had an issue nor did they have any permission to access it. When asked to step in and offer support, it could take days or weeks to parse through how an individual site worked. And if a site had been compromised, there was no way to shut it down, potentially tarnishing the university’s brand and putting its security posture at risk.

From an institutional standpoint, the team recognized it couldn’t support this depth and breadth of web environment diversity. After carefully considering the challenges, the university set a path to invest in systems that would tightly integrate operations and development. Facilitate agile development. Deliver high levels of performance. And allow a more standardized stack—from the codebase down to the hosting layer.

How to cost-effectively and efficiently migrate the sites—some of them smaller with only dozens of hits per month to those with millions of hits per month—to a single platform, where updates and changes could be deployed to all sites quickly, securely, and consistently while minimizing downtime, became a large part of the team’s hosting-provider search criteria.

The search for—and discovery of—developer flexibility

Bailey’s staff recognized they needed to establish standards for far fewer content management systems (ultimately choosing Drupal and WordPress), DevOps practices, authentication, and backups—and to manage the two, designated CMSs with approximately 90% of the same processes. The team wanted to update different components in the stack, set up new sites, and roll out new features quickly. Improve performance and uptime. And gain the ability to push updates with confidence without anything breaking. Beyond developer flexibility, they needed the efficiency to manage more sites with fewer developers.

With their technical requirements set, the team sent out their RFP, then weighed their options, selecting Platform.sh to host its ~400 Drupal and WordPress on-prem websites.

Getting the developer community onboard

With a decentralized campus came a diversity of developer skill sets. And educating the broader development team was more involved than the Digital Service team had anticipated.

To the extended team, containerized hosting felt foreign: a complete shift in how they thought about their websites. And not all developers on campus had used Git. Boyer created a workflow to help them get up to speed and “feeling good about tools that open up a new world of flexibility.”

“From a business standpoint, when you think about business process workflow control, Platform.sh is just a natural,” says Bailey. “Platform.sh uses tools that we're already familiar with and allows us to control parts of the process we could never control before. We can provide a much more certain, predictable experience to the departments that need websites than we ever were able to do in the past.”

Managing Drupal and WordPress sites at scale

For the Mizzou team, getting a single site up and running on Platform.sh was easy. But how to do the same at scale for the hundreds of Drupal and WordPress sites that weren’t identical, were set up differently, and that they didn’t have staff authority over? That needed to be tackled.

“We no longer worry about spinning up environments and those other things Platform.sh enables,” Boyer explains. “Instead, we’ve learned how to leverage Platform.sh API command-line utilities to automate processes that lower our cost of maintenance per site across our entire website fleet.

Mizzou developers speak out

MU Marketing and Communications web developers had a lot to say about their experiences with Platform.sh. Some of their thoughts are captured here.

Development environments that speed and smooth workflows

Development environments are inexpensive and easy to build up and tear down. With our Central IT-managed infrastructure, if we wanted a test environment, we had to write scripts to sync everything, and make sure code was synced to the dev environment before it went live. Platform.sh enables us to put people in a workflow that’s pretty much built into our Git integration, seeing that whole process through syncing the code, database, and files between development environments. It just makes our lives easier.

Customer support

One thing we found really refreshing is the Platform.sh team’s honesty about the strengths and limitations of the service. When we’ve experienced issues, Platform.sh staff have told us exactly what’s going on and owned up without any runaround. In those instances, Platform.sh specialists in those areas have actually jumped in to help make our stuff work.

Establish standards, automate

Platform.sh gives us the ability to create standards and move all these extremely variable sites into a standard workflow, a standard build process, a standard setup, so that we can manage things at scale.

Performance: faster sites, faster provisioning

With Platform.sh, we're way faster. We can have a new site up, completely synced, ready to go—between GitLab and Platform.sh and all the pieces—in literally two minutes. We can also keep the stack components up to date much faster.

Our performance and uptime are much better, too. A 300% increase in WordPress performance is mirrored in our Drupal projects (based on Google website audit tools). We also have consistent backups across every site, regardless of technology. In the past, we had no idea whether or not a backup existed. And because our departments were siloed, the backups were in multiple different locations. Now, we have a single location. We know that if something happens, we can easily grab that snapshot, redeploy it, and have a site back up in literally minutes.

From the end-user standpoint, we’ve seen a lot more speedy access as we look at Google Analytics; people are spending less time just clicking around. They're actually getting what they need quickly just because Platform.sh makes things so much faster.

Future-proof support for multiple languages

We have flexibility to change components in the stack on a site-by-site basis, and we have flexibility for the future. If we need to build a PHP or Node.js, or Ruby application, now we can.

Efficiency: more sites per developer, with faster onboarding

We're far more efficient. We're now able to manage many more sites with fewer developers. With the help of Platform.sh, we've standardized on all these things related to local development, so we can give a developer who's never touched a site access to the repository, they clone it down, start up Lando, run through the script, and have a working, exact clone of the Platform.sh site on their local machine. They’re able to support other sites, too, even if they haven't seen them before.

Lower cost, more value

The main thing it boils down to is this: when we purchase an account from Platform.sh, we're able to have the hosting environment and the database environment together on a single bill. With local servers through our IT department, we had a LAMP stack: Linux, Apache, MySQL, PHP. The MySQL support charges for our internal service were quite expensive because it's a one-off from what they normally support, so it costs them more. A lot of our reduction in cost revolves around the fact that we're bundling database hosting with Platform.sh, and we can get the database services at a significantly lower cost than we can internally.

It's been helpful to show our user community that they're getting a lot of value from a cloud-based hosting vendor like Platform.sh. We can honestly say to them, ‘These are the benefits that you're getting.’ And most of our websites cost less than they did on our local hardware.

Digital transformation that meets stringent higher-ed requirements

After 25-plus years of the university’s organic website growth, Bailey takes great pride in his team’s accomplishments. The hundreds of websites: completely standardized on the backend and close to that (as close as Drupal and WordPress can be) on the frontend.

Today, the MU Marketing and Communications has grown from a two-person dev shop to a 16-member group that includes Drupal and WordPress developers, a backend team, designers, and UX/UI specialists. Working in an agency model, they’re no longer herding websites, but are analyzing how the sites are meeting audience and departmental needs and what improvements should be made moving forward. From a technology perspective, team conversations are getting started to develop a headless or hybrid strategy.

Reinforcing the university’s brand has become a core component of the team’s mission, supporting the larger goals of Mizzou’s value in the higher-ed community and increasing student recruitment and retention. In just a few months, the team will completely oversee all the websites for Mizzou’s 13 main Colleges and Schools, implementing theme and brand standards on every site.

“Our goal was always to get to the point where we could help our content managers take a website and easily manage their own content without us having to be involved,” explains Bailey. To that end, Mizzou content managers can now take self-paced training—created by Bailey’s web developers—to better understand how the university’s Drupal and WordPress environments work. How to more quickly and efficiently set up new websites. And how to grow their technology skills and knowledge to be part of the extended team’s continuous improvement process.