National Review Cuts Dev Costs & Improves Performance After Zero-Downtime Migration to Pantheon

WebOps Team, Pantheon Reading estimate: 6 minutes

Chris McEvoy is Executive Editor at National Review, a bi-monthly magazine with significant daily digital content. In this guest blog post, he discusses National Review's migration to Pantheon. 

Image

National Review homepage

A Print Business Goes Digital

With more than 300 million pageviews a year, uptime is everything for NationalReview.com. As our business model has turned more to the digital side over the years, I have found myself increasingly involved with our web-development efforts. I’m not a developer myself, but I’m versed in the basics of git, dev, Drupal, and modules. I work with outside companies to oversee development and keep us on track.   

How Hosting Failed Us

  1. Downtime, too much of the time. Uptime was the main issue with our former host. Traffic spikes kept crashing the site, and there was a sense that we were never properly configured in terms of varnish, apache, memcache, etc. Our former host was very good at performance e-mail alerts. There were times when I’d wake up at 3 a.m. to a hundred or more service alert e-mails, only to find the site was down and no action was being taken on the hosting side. In other words, although we had the “enterprise,” “gold-star” plan, we too often had to actively chase up alert tickets: “Hey, are you seeing this on your end?”
  2. Scalable in theory, not practice. Scalability is very important to us. In theory, our former hosting provider offered the ability to spin up extra web heads on demand. In practice, this proved extremely difficult. It took several smart techs on our end to guide their hosting techs to spin up the new web heads. There also was the time our ticket request for additional (ASAP) web heads was forwarded to the sales department. Good grief.
  3. Drupal 7 nightmare. Our upgrade from Drupal 6 to Drupal 7 was delayed by months. The testing environment simply wasn’t there. Our configuration presented too many roadblocks. It was “cross your fingers, go live, and see what happens.” When traffic hit, additional problems had to be worked out. We spent months scrambling and fine tuning after the platform upgrade. I heard repeatedly from our developers, who were killing themselves, “Had you been with Pantheon, this would have been so much smoother.”
  4. Hosting raised our total costs of ownership. It was difficult to convince our publishing and financial departments why a Drupal website needs a platform that’s configured for Drupal. Despite all our hosting problems, it took two years to choose Pantheon. I was a big advocate, but there was hesitation from the financial side, and understandably so. Price is important. Yet, it turned out that going another year with the more price-competitive hosting provider resulted in our worst year ever, in terms of performance, headaches, and dev-cost overages. Simply, the unexpected costs added up to much more than what we saved in going with the cheaper host.

 

Our “Come-To-Pantheon” Moment

We needed to take the hard road before we could take the right road. At this point, everyone was ready for Pantheon. I remember thinking, here’s a very hands-on company of like-minded people who are going to fight for our uptime, respect us as Drupal users, and offer us all the tools necessary to better our performance.  

The Migration Process

  1. Launch team raises the bar. Pre-migration, we were showing multiple site errors in test. Pantheon didn’t touch our code or make fixes, but they steered us toward the resolution of issues. The Launch Team gave us exhaustive checklists. It wasn’t just a couple of guys asking, “Did you do this?” off the top of their heads. They kept us in line. The launch took longer than we originally intended because we had to work out a few things on our end. We discovered we weren’t doing things to Pantheon’s standard. For instance, our ad tags were an old form of Google tags that required us to switch between secure and non-secure pages. We had to work out a fix for this (we have since moved to GPT tags, which allow for an all-secure-page site). Overall, the pre-launch process had us cleaning up our codebase, which is a good thing. We became a better site in the process of preparing for Pantheon. I see that every day now.
  2. Zero downtime. We started the migration at 3 a.m. on a Saturday morning. After doing the final pull from the host, we were up by 4 a.m., looking for problems. There were a couple of broken images and redirects and other simple stuff to fix. Our lead guy managing this migration said it was the smoothest he has ever experienced. And it was the first time we didn’t see downtime after going live through a new host. We braced ourselves for the expected 5 or 10 minutes down, but we didn’t even have that.
  3. Cached content served to the far reaches. CloudFlare, our CDN, needed some fine-tuning, and Pantheon was right there to support us. We had a CDN with our last host, but now we’re fully leveraging what CloudFlare can do for a website.

 

4 Reasons Our Website Is Better Off Now

  1. Simple, unified maintenance. Doing regular maintenance through Pantheon is a git push. You can see your update right there in “dev” on the Pantheon dashboard. Then you pull to test and make sure your changes don’t crash the site. I can peek at what our dev team is up to. Everyone sees each other’s actions. It’s transparent, simple, and effective.
  2. Expert support gives us a better website. Over the past couple of years, we did not have the sense that we were in good, experienced hosting hands, at least not 24/7. Pantheon’s support is like having an extra team of developers on our side. Even our tickets are different. Instead of hard downs, our tickets relate to more normal, course-of-business actions. And when Pantheon responds to a ticket, they give substantive advice. “I feel your pain on this, and here are three things we want you to look at.” Developers get useful documentation to steer them toward a fix.
  3. Snap, scale. No more performance dips. In the past, three-quarters of the Drudge links to our site would result in an e-mail to hosting support. “Guys, we’re really sucking wind over here. Can you help us out?” I have yet to ticket a traffic problem now that we’re on Pantheon, and our Drudge links have been plentiful. When election season starts and our traffic more than doubles, I feel extremely confident in our ability to ramp up with Pantheon. It’s a snap.
  4. Expect to cut our dev costs significantly. We lost more money in downtime, pain, and extra development work than we saved by not going with Pantheon at a much earlier date. We did tons of extra development work. The process is so much smoother now. The developers are developing—not gnashing their teeth. We expect to cut our dev costs significantly. We’re now experiencing a kind of peace and quiet that equals money in our pockets—as opposed to the noise of unhappy developers and site users, which equals money being taken out. Our CFO will be happy to hear it. We just contracted with a new design/development firm to redesign the website. Our new partners are really looking forward to the Pantheon setup.
     

Advice for Other Publishers

Have a web host configured for your content management system. If you have a Drupal site, make sure it’s sitting on a Drupal host. Now that our web host is configured to our platform, we’re in the best position to develop, improve, and perform. Our publishing and editorial departments are happy. Yours will be too.

Discover More

Safely Publish to Web from Google Docs with Pantheon Content Publisher

Roland Benedetti (Senior Director, Product) and Zack Rosen (Co-Founder)
Reading estimate: 7 minutes

Unifying Content and Code: Inside Pantheon’s Vision for Content Operations

Chris Yates
Reading estimate: 5 minutes

Where Did All the Drupal 7 Sites Go? They Moved to WordPress

Josh Koenig
Reading estimate: 6 minutes

Try Pantheon for Free

Join thousands of developers, marketers, and agencies creating magical digital experiences with Pantheon.