Open Source as a bridge between commercial products

I’ve come across this scenario multiple times. A company C1 merges with another company C2. C1’s corporate standard is CMS1 and C2’s is CMS2. Because of the merger, C1 has to eventually move its systems to CMS2. However, during the transition phase, which could be as long as 18 to 24 months, it is very expensive for them to maintain CMS1.

Apart from mergers and acquisitions, there could be other reasons as well for companies to change from one product to another. Open Source products are increasingly being used in such scenarios as a bridge during the transition phase. So, instead of directly moving from CMS1 to CMS2, customers use a quick and dirty implementation of an Open Source product. The idea is to migrate only the most essential features that are necessary to run the site for next 18-24 months and use this time to plan the implementation of CMS2. However, it does not usually happen that way. Users who’ve been used to CMS1 want all those features in the Open Source solution. So, something that should be a simple solution ends up being another complicated one that takes its own time to implement. So whatever benefits that the customers could have gained are lost because by the time this implementation is over, it’s time to start the implementation of CMS2. Another round of testing, another round of user training and the nightmare continues…
If you are one of those trying this path, here are some pointers (in no particular order) that might be helpful:
1. Most Open Source products do not provide high end features that commercial products provide. At least, the free versions of these Open Source products don’t. For example, commercial products like Vignette and Interwoven typically run in a dev-staging-live environment where content management (workflows etc) happen on staging. The content is then physically published to multiple delivery servers. These products can be run in cluster model and scaled up. These kinds of features are *usually* not present in Open Source products. Alfresco and OpenCMS provide some of these high end features but then you have to buy enterprise version (in case of Alfresco) or buy separate modules from Alkacon (for OpenCMS). So, do not expect to have all those features. Prioritize and keep things simple.
2. Do not use all your time in implementing the stop gap solution. Instead, use it to plan for the final implementation based on lessons learnt earlier and user feedback. Remember, this solution is going to last for only a few days and the less time you spend on it, the better it is.
3. Choose the Open Source product in such a way that is is easier for you to migrate later. A product that let’s you export content in open formats (XML, database) should be chosen. Also, it does not make sense to use a JAVA based Open Source product if eventually you are going to be using a Microsoft based product.
4. If you still haven’t chosen the new product, add “standards support” to your list of features. This situation could arise again and if your product supports standards like JST-170, it will be easier for you to migrate later.
5. Open Source does not mean that everything has to be free. Be ready to spend some money on support and other things.