Chris Contakes, CTO of the Atlantic Media Company, led the technology migration of National Journal Group from a variety of platforms to Nstein in less than a year from concept to launch October last year. National Journal Group is an online and print publisher of in-depth non-partisan news and analysis covering politics, policy, and issues in Washington. National Journal Group’s flagship publications include National Journal Magazine, National Journal Daily, and The Hotline. The business embarked on an aggressive new digital strategy in 2010 to increase reach on the free side of the site and increase utility behind the paywall for subscribers. Executing the new strategy called for a complete overhaul of the technology infrastructure delivering National Journal content. Chris and I first met at a DC Web Content Mavens event and stayed loosely in touch throughout the migration. Before the National Journal Group Chris played the role of Manager of Content Management Systems for WashingtonPost.com. Below is an edited version of a conversation we had at one of my favorite Capitol Hill restaurants, The White Tiger.
Why did you migrate to a new platform? And how deep of a redesign from the end user’s perspective was needed to meet that vision?
Our in-house platform wasn't scalable and flexible enough to meet our needs as we transformed to a digital first publication. Our aggressive plan called for a launch in the fall which gave my team less than 5 months to migrate and build the new site. We decided to execute with a solution that did a lot of great things out of the box and would flex to serve our strategy.
We needed a system that could scale for growth, be flexible to integrate with a sophisticated paywall system, be able to support multichannel publishing (web, mobile, native iPhone / iPad (download) etc.). We also designed a sophisticated reader experience for visitors on the site. For example, one of the goals of the strategy called for no "dead ends". In other words, visitors should be able to access anything they can see and not see anything they are not entitled to (do not subscribe to) on web and mobile devices. Building this type of functionality into a native iPhone app required APIs for us to surface access control rules for content requests.
Going into the migration, one of your biggest challenges was adding more refined metadata to allow advanced browsing by your subscribers. How did you approach that issue?
During the demos, we were impressed by Nstein's text mining capabilities and were planning on using it for dynamic tagging. That said, since the editorial process already included tagging to publications (for instance, four editions of Hotline per day) and major topics (like National Security), the editorial team still tags manually to these primary channels. Nstein is automatically tagging to IPTC topics and surfacing these topics via the Solr search experience. During the migration, the old taxonomy values were mapped to the new ones. We used these rules to build migration scripts for the content.
How much of the migration was automated and how much was manual?
We have 30 years of editorial content including videos, articles, and podcasts. The 600,000 articles were automatically migrated using custom scripts. There were also data-driven portions of the site such as the Almanac of American Politics. In these cases the content stayed where it was with the new templates pulling in the existing data.
How much was dropped from the old site?
Most of the content was migrated, although some editorial features didn't migrate based on strategic decisions such as were the features were performing well and staffing decisions.
What was your biggest surprise?
The complexity of the 30 year archive was a surprise, with the content developed on changing systems with different writers and web producers over time. This meant that over time content having non-standard features (like iframes). We carefully babysat the scripts, analyzing exceptions that the scripts reported. We knew there would be holes in some pages, but our objective was to move 98% without exceptions in time for launch. We then had a spreadsheet of the exceptions that the editorial team worked through in the weeks after the launch.
How did you deal with the aggressive timeline? We first met six months before your relaunch, and at that point you were still selecting the CMS. Since the president gave an interview mentioning the aggressive schedule, you were on the hook to deliver to it.
From the top down, our organization was focused on executing the strategy that we laid out earlier in the spring. The technical, editorial, and business teams were almost completely focused on the new website, with long workdays and weekends the norm leading up to the launch. The developers knew they were working on something impressive and remained focused on a successful launch. We also used some professional services from the Nstein team to assist where we could silo off development projects for extra bandwidth. We also did have to do some things that were not ideal. For example, the aggressive schedule meant we couldn’t spend a great deal of time on workflow design in the backend with the actual users that would be using the system for publishing. We relied on a lot of quick thinking and using workflows out of the box where we could with an understanding that we would refine in the future.
