Choosing the right Content Management System (CMS)

Tuesday, August 3, 2010 by Alex Mancevice
When choosing a new CMS a customer’s primary concern is almost certainly authoring-based. That is to say, a clear vision for the future of content is established well before the vendor is chosen. There are many CMSs to choose from and they vary greatly in scope, functionality and ease of use. You may be faced with a large influx of new content which is no longer manageable under the current CMS; or you may come to the realization that your current vendor no longer supports your vision for your website in the functionality it supports (it’s not uncommon to find content authors use tricks to get around the limitations of your CMS); or you may simply be tired of that clunky user interface and want something with a little more pizzazz.

What’s not always considered is backwards compatibility with existing content. Ideally, undertaking a CMS migration into a new platfom represents a translation of data, resulting in the achievement of value. Otherwise, a content migration can leave you with a truncation of content resulting in a functional, but 'lossy' migration. Metadata management is incredibly useful on both sides of a website, internal and external. Content with good metadata is good content ie.  findable! It’s a good idea to have a strategy in translating both content and metadata from your source CMS into the target. It’s all too easy to favor new functionality and componentry in a new CMS over the simple-yet-invaluable little things.

CQ5 is a particular favorite of mine to work with but it’s my belief that a crack team is required to take full advantage of all the features CQ5 has to offer. Not everyone requires a CMS as flashy as CQ5 and there are plenty of other utilitarian options. One thing is clear: regardless of which CMS you choose,  it is imperative you understand what you’re getting in your CMS and that you are prepared to spend the time necessary to get the most out of your investment. We at Vamosa were recently faced with a client coming back to us after a brief disengagement only to reveal that they had decided that their chosen target system did not adequately meet their needs - after months of work on both sides. It’s hard to imagine a more tragic outcome than that! So be sure to take your time deciding which system is right for you, and good luck!

http://www.vamosa.com/dmdocuments/Vamosa%20Consulting%20-%20CMS%20Vendor%20Selection.pdf








If you are unsure of what CMS is right for you, download the Vamosa Consulting Service CMS Vendor Selection Business Results Sheet and see how Vamosa may be able to help you.

Challenges using vendors’ APIs in unstructured data migration

Friday, June 4, 2010 by Alex Mancevice
As an experienced Consultant, I find it’s difficult to say when considering a data migration strategy which step in the process is most important. The success of a data migration methodology really depends on all the components of a solution working well from beginning to end. But it’s certainly true that a successful data migration project cannot take place without a robust means to push content into its new home, whatever that might be.

Since virtually every content management system (CMS) on the market is different, there is no silver bullet for loading content quickly and dependably. Each application programming interface (API) is different and can vary greatly in terms of quality style and completeness. Some may require a custom web service, deployed on the target environment and called remotely.

But this solution isn’t quite optimal. What if the client’s target environment is completely inaccessible for some reason? Perhaps the client’s security model forbids deploying foreign services. Microsoft’s SharePoint 2010 CMS circumvents the necessity to deploy remote services with its client object model. After getting your hands on the required libraries the SharePoint 2010 API is suddenly at your fingertips. Using this technique, a data migration can be accomplished using a locally deployed custom service after supplying the required credentials!

While I found SharePoint’s client object model to provide a promising new way to connect to a CMS, I thought the API was incomplete and sometimes poorly documented. Luckily, the out-of-the-box web services packaged with MOSS provided the methods I required. I am excited at the prospect that more CMSs will start packaging up libraries that provide the tools necessary to connect to an environment with a remote machine. It simply provides a safer solution for the data migration and one that doesn’t require deploying anything on the client’s machines! The big upshot of the client object model implies that projects are less likely to face resource bottlenecks because additional access to secure systems is not required. A smaller gap between the development and testing periods allows more time for refinements and a better quality data migration solution.

It seems that Microsoft is leading the way in this regard.

Data Migration White Paper Link  Download our Data Migration - Seven Steps to Success White Paper to gain a further understanding of the data migration best practices that should be considered when beginning a migration project.