By: Keith Jordan
Thinking about switching to a new content management system (CMS)?
There are times it makes sense to do so, and it can even be a necessity. But I think media companies can tweak their existing CMS to meet evolving needs, often much faster and cheaper than they can meet those needs by changing to a new CMS.
I worked for a major media company that changed its CMS three times in two years. I played a big role in implementing each change, so on the positive side, I developed a lot of expertise on CMS changes. But I was more and more aware over time that we could have had greater benefits if we had put our time into expanding the original CMS instead of replacing it (twice).
But let’s say you’ve looked into it, and you’re thoroughly convinced you need a new CMS. Maybe you bought it from a vendor that’s out of business. Maybe it was written years ago in a coding language that nobody on your current team knows.
What should you consider as you make the switch?
Real-world use. Developers may not be aware of the number of articles, revisions, photos, etc. that your team will deal with, particularly if they are not CMS experts. I’ve seen several cases where developers ignored warnings that the number of pieces of content could grow to enormous sizes. In one case, this led to a database that tracks each piece of content getting so large that it couldn’t load in the back end, resulting in extremely slow performance. Solution: Make sure your most experienced Web producers spend time with your developers, talking through how the system will work, and make sure the developers pay attention to what the producers say.
Workflow. With the growth of very solid open-source CMS systems such as WordPress and Drupal, this is less of an issue than it used to be. Developers today can easily look at examples of good systems. But you’ll still find some developers who would rather spend two weeks coding a system that has your producers taking 40 seconds to publish a story, as opposed to taking three weeks that has your producers taking only 20 seconds to publish. That extra week of development seems like a big deal to them. They have other projects to get to, and they want a reputation for getting things done fast. In that context, adding a little extra time to your editorial staff’s workflow doesn’t seem important to them. But in the long run, saving those 20 seconds per story will matter more than saving that week of development, plus it will boost morale for your editors.
Integration with other systems. If you have a photo repository, it should work with the CMS. If you have a print product, ideally, your Web CMS should be tightly integrated with it. Many newspaper frontend systems include a Web CMS built in. It’s often worth using, simply because it means the two systems will be tied together.
Porting old data. How do you revive a story from last year once you make the switch? Copy and paste? Preferably, your old data is ported to the new system, but that can lead to lots of glitches — such as publication dates being inadvertently updated or formatting errors showing up. I think it’s usually best to only port what you think you’ll need and retrieve the rest manually when you decide you want it.
Flipping the switch. You need a substantial testing period, with editors doing real-world publishing on the new system for long enough to run into snags and glitches. Not just a training session, but days of full publishing in the new system. When you’re satisfied that it’s ready, the best time to make the change is usually overnight if your developers can be available then to do it. If you can’t get your team to do the work overnight, try to do it as early in the morning as possible (say, 5 or 6 a.m. Eastern time), so if something goes wrong, the minimum number of readers will notice before they revert to the old system.
Keith Jordan is managing director of Upstream Digital Media (upstreamdigitalmedia. com), a consulting company focused on digital publishing.