Weill Cornell: Building a Dream Distribution on Pantheon

Weill Cornell: Building a Dream Distribution on Pantheon


At Weill Cornell Medical College, Dan Dickinson manages a 12-person Web Communications team that designs and develops organizational websites for medical education, research, and patient care. Read how his team is rescuing 100+ websites from design anarchy—by setting out to build the best Drupal distribution in higher education.

The Weill Cornell web team was looking to establish design and framework consistency across their growing portfolio of sites. They decided to create a custom distribution on Drupal and needed a management solution that would allow them to develop effectively on their chosen CMS. They chose Pantheon to build a dream distribution—improving their workflow and getting rid of approximately 100 virtual hosts along the way.

By partnering with Pantheon, we get to spend our time working in Drupal, rather than spending precious time procuring servers.

—Dan Dickinson, Associate Director, Web Communications

Founded in 1898, Weill Cornell Medical College is one of the top clinical and medical research centers in the country. The mission of the Medical College is to provide the finest education possible for medical students and students pursuing advanced degrees in the biomedical sciences, to conduct research at the cutting edge of knowledge, to improve the health care of the nation and the world, and to provide the highest quality of clinical care to the community. Dickinson and his team are responsible for maintaining the 100+ websites that fall under the school’s umbrella. Managing a portfolio of sites this large takes a big effort, and running on Pantheon helps the team do it with a custom Drupal distribution.

Diagnosis: An Advanced Case of Digital Sprawl

Problem #1: 100+ static websites running on various platforms.

Before migrating to Pantheon, Weill Cornell had approximately 100 virtual hosts on their production web cluster. They had an enterprise CMS that was too big, and some lighter-weight CMSs that were too small. The departments that wanted to rebuild their sites had limited options for maintaining sites that hadn’t been touched in years.

Problem #2: Needed consistent user experiences and designs, STAT.

The buttons should work the same. The calls to action should be in the same place. The most common actions should be easy to find. Cornell’s sites needed better user experiences, but because there weren’t any real boundaries for creating new sites, there was a wide array of look-and-feel, branding, and other functional issues. “Having a consistent user experience is as important to us as whether or not the official university colors get worked into the design,” Dickinson said.

Problem #3: A different site for every department.

Although one institution, every department at Weill Cornell has a unique focus. One site might focus exclusively on donors while another focuses on prospective students. Others focus on existing students, research fellows, or collaborators around the world. Each department needed its own, unique site.

Problem #4: No consistent base design or framework for others to work from.

Sometimes departments need to hire external web agencies. Other departments want to build sites themselves. Dickinson wanted them to be able to make progress, without his team having to be there for every minute of the project.

Seeking Immediate CMS Therapy

After some market research in early 2012, Dickinson’s team settled on Drupal and set a modest goal: to build the best Drupal distribution in higher education. Why build a custom distribution for higher education sites? A custom distribution is the optimal toolkit to build sites off of and boasts these great benefits:

  • It includes most of the boilerplate work needed on any given site (web analytics, search integration, content types, email forms, navigation elements, etc.)

  • It’s a toolkit full of parts that can be switched on and off for various sites and departments

  • It’s bundled up to avoid repetitive work

  • It accelerates production work significantly

Why Pantheon? Multisite vs Multi-install

Once they chose Drupal for a CMS, the Weill Cornell team had to decide whether to go with Multisite or multi-install.

Multisite would minimize the number of installations, but it would also require the team to build a lot of infrastructure and bureaucracy internally. They would spend as much time managing Multisite installs as they would making websites.

“We needed to start to standardize site form and function, while driving down our implementation times (and eventual cost to departments), but without train-wrecking our project lifecycle", Dickinson said. "Pantheon Upstreams would allow us to do all these things by keeping it to one site per codebase. That’s a big part of why we chose Pantheon.”

Prognosis: A Full Recovery with a Custom Drupal Distribution and Pantheon

So far, Dickinson’s team has launched five sites on the distribution, with more on the way. They’ve also had some outside vendors working on it. Here are some of the results they’ve seen:

1. First project comes in under budget and on time.

Even though the first project to switch to the Drupal distribution was mid-cycle in development, Dickinson and the team saw savings in billable hours for the department. The typical rush of last-minute change requests didn’t happen this time.

2. Freedom from design anarchy.

“When our team is asked to create a new site, now there’s a consistent start state to work from and build customizations on top of,” Dickinson said. “We can have tons of Drupal sites with different shapes that still function in the same manner. So we’re starting to get both consistency and flexibility. If one department wants a vanilla site while another needs a bunch of contrib modules installed, we can handle that.”

3. Departments love it.

“Most of the departments who have seen the Pantheon Upstream love it,” Dickinson said. “They like knowing the base legwork is already done, so they don’t have to sweat it. In site builds, we always spent a lot of time going from design concepts to workable betas people could click around on. The sooner we get there, the better. It’s much easier to speak a common language with a client.”

4. Departments say "YES" to the pricing model, too.

“With Pantheon, I don’t need a Powerpoint presentation to explain how the pricing works,” Dickinson said. “It’s simple and very straightforward. This is your website. We expect this much traffic. It costs you x. We’re not subdividing shared servers or trying to pair departments together into multi-site installs.”

5. Lets the right ones in.

“The Upstream model helps with the provisioning and permissioning for outside agencies and others,” Dickinson said. “When outside vendors finish a project, we’re not doing anything different to have the site go live: our platform becomes their platform. When they leave at the end of the project, we’re not left with foreign infrastructure that takes a lot of effort to debug and maintain. And anyone at Weill Cornell can sign up for a Pantheon account and spin up a site using our distribution. Our team—and more importantly, our internal clients—are happy with our push to use Drupal and a custom distribution at the heart of our future web strategy. We’re already seeing a good return on the time invested, and expect to see more over the coming years as we keep moving Weill Cornell onto Drupal.”

Thinking of Building Your Own Custom Distribution?

Here are some tips and best practices to anyone else who’s considering multi-install to manage their educational websites:

1. Budget, compliance, speed? What’s at the top of your list?

Schools are understandably budget-conscious, and often have very strict security and compliance requirements. Dickinson suggests asking yourself what matters to you—do you have one mammoth site, or a lot of smaller sites?  Do you have compliance concerns? Is your web development cost-recovery or centrally funded? All of these factors are important requirements that will drive your development. Set these priorities for yourself, before you start touching any lines of code.

2. How can you give departments what they already want, and what they want in the future?

A vision for the future is great, but as Weill Cornell found out, you also need an honest look at how the web at your institution operates in the present. "Often, techy people get hung up about what we want an idealized future to look like,” Dickinson said. “But getting to that future point isn’t about working off of a giant technical list and a work-effort list. It’s also a political and cultural shift. Business units can react badly if you suddenly change the rules on them. We needed something that fit our current model as to how our web ecosystem operated, so that we did not add unnecessary stress as we build towards the future".

3. Insist on kicking the tires.

"It’s nice to have directors and C-level executives in meetings with vendors, seeing best-case WebEx demos," Dickinson says. "But if you’re only seeing a tool when a vendor shows it to you, you can’t really get a sense for it. The key for any technology evaluation is being able to kick the tires. Signing our team up for free accounts with Pantheon helped tremendously in our decision process."

4. Take an honest look at your team’s capacity.

It’s hard to do it all, and it’s better to focus your energy on the things that make your institution unique, rather than conquering problems that others have tackled before. By focusing on what was most important for Weill Cornell—consistency and ease of use—Dickinson and his team were able to set up a system that gave its departments the tools they needed to maintain clean, up-to-date websites.


  • Design & framework consistency across departments

  • Decreased implementation times

  • One site per codebase

  • Got rid of approx. 100 virtual hosts on their production web cluster

Let’s get in touch