Clichés and the cost of content contributors

We recently kicked off the first phase of a project to migrate a massive web property from one CMS platform to another. The site, a publishing platform for a widely recognized codes and standards organization, houses dozens of unique content types and tens of thousands of individual content items. An important client stakeholder recently indicated a desire to explore integrating twenty external blogs which are currently, successfully managed outside the web CMS.

On the surface this seems like a relatively innocuous and sensible requirement. For a wide variety of reasons it makes good sense to centralize management of blog content. From a data migration perspective it is only incrementally more complex to move content from their blog platform (Typepad) than the rest of their existing CMS content.

However, there is an important cliché in consulting: “leave no stone un-turned”. A couple of quick questions revealed each of the twenty blogs has dozens of individual content contributors. Although not necessarily a technical challenge, this many content contributors certainly adds complexity.

Piggy BankThe client’s new CMS platform and licensing arrangement stipulates pay to play by the number of users, often referred to as ‘seats’. In other words, more contributors means more cost. Some quick math indicates this blog integration will completely contradict an often much more divisive business requirement: budget limitations.

In this situation a CMS purist might argue the benefit of completely centralized management of content far outweighs the cost of additional content contributors. Further, it might be possible to negotiate a reduced cost for the additional, limited use seats…Or build a custom back-end interface which accommodates the specific requirements of blog contributors without forcing them to log into the licensed CMS Admin tools.

However, a smart consultant has many more clichéd principles which are germane to this discussion and worth sharing:

  • If it ain’t broke don’t fix it.
  • First, do no harm.

Earlier we noted the client’s sentiment is the blogs are currently being managed successfully. So why the desire to integrate? Some more digging revealed their underlying goal is to leverage the blog content for SEO purposes on the .ORG. Further discussion crystallized this as the only business objective satisfied by integration.

This leads to what is possibly my favorite consulting cliché : “No sense reinventing the wheel”. There are plenty of other ways to integrate the blog content without abandoning the blogging platform. In this case we’ll use the obvious choice and go with aggregating with RSS.

This approach circumvents the  increased cost of licensing and more. By keeping things the way they are there will be no need to migrate the incredibly rich depth of blog content or retrain hundreds of bloggers. This additional effort would have easily doubled the cost of the migration project.

About the Author
Jake DiMare

Jake has spent the last 15 years helping organizations plan, design, develop, and implement effective online experiences with a strong focus on large scale web content management systems and integrated online marketing suites. Jake wrote for the CMS Myth during his time working at Connective DX (formerly ISITE Design). Google Plus Profile

More articles from Jake DiMare


One response… read them below or add one.

  1. John Eckman says:

    Not to hijack the thread into an open source vs. proprietary discussion, but this also points out the issue with “per-seat” or “per-author” licensing: it creates a specific financial incentive to reduce the number of authors.

    Whatever your strategy is with respect to distributed authorship (in most cases I’m inclined to argue broader distribution of authorship is better), you don’t want to have to make that decision based on how many “seats” you’ll have to buy in your tool.

    Similar issues arise when it comes to the number of servers (in production, in staging, in QA, in dev) and what portions of the tool stack runs on each of those servers. You want to make the decision based on most effective use of resources and ease of use for content contributors and developers – not based on the licensing scheme of the CMS.

Leave a Reply
  1. Fields marked with * are required.
  2. We will not publish your email.