Top 10 Things to Find Out Before Selecting a CMS Vendor

1. How long will it take to create, start, and complete a simple content creation job with the system under a heavy user load?
   There can be a great deal of behind the scenes indexing and database churning when users are creating and editing content. A system that responds immediately with only one user may grind to a halt when there are twenty content developers loading content.
   
   
2. Is there an automated solution for migrating existing content into the new CMS?
   Often the answer is a solid “no.” But vendors will try to make you think it might be possible during the sales process. Usually existing content has to be re-created using the new CMS. This is why you might need the twenty content developers mentioned above.
   
   
3. How many users can effectively use the system at the same time?
   Between content developers, editors, translators, and reviewers the number can get big in a hurry.
   
   
4. What parts of the system code can be modified and what parts are proprietary black boxes?
   Often it is easy to change the user interface for parts of the system, but changing the way that the content is indexed and stored is not possible.
   
   
5. Exactly how does the translation process work when using an external translation vendor?
   This usually entails developing a specific workflow to be used for external translations. The system will allow you to bundle a bunch of records to out to a vendor and then re-insert them back into the system when complete. This re-insertion of content puts a huge load on the system and must be taken into account when planning. You may only be able to load a few hundred records a day without adversely affecting system performance.
   
   
6. How do you delete records from the CMS?
   Having the ability to remove content records sounds obvious, but once a record gets created in theses complicated, indexed systems, actually removing it can cause serious data integrity issues. Make sure you understand the process and if that process works with how you plan to use the system.
   
   
7. Make sure you understand how structural changes to a master source content record propagate through to versions of this record (language versions for example).
   If the system being discussed automatically creates language versions based on a master source content record, structural changes to the master source record (such as adding a new link) may not get automatically passed down to all the versions. You may have to add the changes manually to each version, or create a new workflow that propagates the changes.
   
   
8. Will the IT group let content developers migrate Web content directly to the production servers without their involvement?
   You may own the content, but the IT folks own the servers and may be very reluctant to letting your team publish directly to their servers. They will want to be involved to make sure nothing bad happens. So if you are forced to FTP files to the IT team and have them load them onto the servers there is no need to pay your CMS vendor for expensive real-time publishing tools.
   
   
9. What is the structure of the URLs generated by the system for each Web page?
   Quite a few WCMS systems still generate query-based URLs that look like : www.companyname.com/val=345234057$^%$*^(7876**&(*&97659%8650
   You really need to be able to look at a URL and know exactly what page on the site it represents. Real, readable URLs that look like:
   
   www.companyname.com/Sitearea/subarea/subarea/filename.html
   
   give you a way to talk about site areas and particular pages with a common taxonomy that everyone understands. When someone tells me, “We have a problem with the ‘hammer’ product page in the ‘tools’ section,” I know what they are saying and what page they are talking about.
   Besides the fact the search engines can’t do anything with a long, query-based URL, the site owners usually can’t either. I love that I can look at a URL for a page on my site and instantly know where it fits in the site structure and what the content and navigation should be.
   Keep the query string out of the URL.
   
   
10. Completely understand the complexity of the content creation process before assuming that you can use a distributed content creation process.
    Unless you have a very simple site and do not plan to design for a lot of content reuse, expecting your content to be developed by random people all over your company is a fantasy that CMS vendors will always try and sell you. Most companies find that once the system is built and delivered, that the system is very efficient, but very complex. A module of content may be used on several different pages and in different contexts. Changes must be planned carefully. Users who only make content changes a few times a year will not be able to use the system effectively and will usually do more harm than good. If your site and CMS implementation is complex, plan or hiring enough dedicated content developers and content strategist’s to handle most of the workload.

Understand How the CMS System will be Used, Not just how it will be Built

Not having a content developer or managing editor involved in the design and implementation of a new CMS is the single biggest mistake I see companies make. This is treated like it is an IT project when it is really a creative content development project. IT developers rarely understand exactly how a CMS is to be used by content developers and usually make bad decisions if these people are not involved.

Get it In Writing

The cool thing about asking these questions before you sign a contract with a CMS vendor is that you can then use their answers to these questions as acceptance criteria when they say they are done and want to disengage. Point them back to their promises and don’t let them leave until all these criteria are met or they give you an appropriate reduction in cost.