There are lots of sites/advisory papers which talk about how to choose a right WCM for your needs. And I am not going to re-invent the wheel here. But there is one aspect which is always given less importance and usually neglected during CMS selection and that is the upgrade process.
Usually upgrades shouldn’t be too tricky as most of the upgrade does is change some schema definition and update existing product code base. So why it needs to be considered at CMS selection process? Read on !
Most of the big WCM Implementations need customisation of some sort and so upgrade projects become more tricky when product overwrite these customisations. A lot of it depends on the under lying architecture of the product. Lets consider two well known products: Oracle WebCentre (previously Fatwire) and Adobe Day CQ. Adobe Day CQ provides facility to overwrite the default components and configurations by simply extending them within your own project. Customisations are achieved without modifying any of the system files, provided its implemented based on CQ recommendations. So, upgrade path for CQ is pretty straight forward and shouldn’t cause sleepless nights.
On the other hand, consider Oracle webcentre where customisation could be achieved only by modifying the underlying system elements. Even your implementation follows the Fatwire recommended approach for customisations, it will lead to changes to system elements. What that means is that upgrade is not straight forward and upgrade itself becomes a project in its own where time lines vary with the number of such customisations.
In a short period product A might satisfy your requirements more than product B, but its important to look at the longer picture because something which looks cool and easy to implement and run might not get you the expected returns in future. And considering the way technology is changing, no one can move away from not upgrading their products for long.