Migrating existing product to new platform

Some time there are need to provide existing product on different platform. It could be because of many reasons e.g. capturing of new segment of market, leverage capability missing in exiting platform etc. In all cases building product on new platform comes with its own risk along with intended benefits. If the exercise is not managed properly it can lead to delay in completion or even failure which can eat some of the intended benefit. This seems little odd in the sense you already have product and you just need to replicate it on new platform. In order to minimize the risk, following needs to be kept in mind in addition of usual best practice of project management.

1. Feature Document – This just like any project where you need requirement document before you start. So check if you have a good reference document which describes the features and its relationship with other features in the existing product. Many times, it’s not available. Remember, help document of product can be useful but not sufficient for the purpose. If it’s not available then it’s very important that you have it first before start of the development. Don’t assume product itself as reference because if you fall prey to it and ask developer to use it as reference, then it completely depends on individual developer ability and desire to find all the facet of a feature and accordingly new implementation can be incomplete or faulty. While capturing the feature behavior, special attention should be given to inter-relationship among features. This is place where chances are high to miss the certain behavior. Another important in my opinion, is to keep the document more bullet point than story telling. This stage is already gone while building the feature first time. Here requirement is to create replica. So it’s should less open to interpretation. Also, temptation to fix bugs while creating feature should be guarded because otherwise you would soon be on path where there is goal post.
2. Platform readiness - This is very important. Be sure your team is ready to work on platform. I am talking about the people who will actually code. Unless, people who are going to code has good understanding, chances are there that technology will be used in a way that would result in may issue like performance, scalability etc. A standard dilemma in such scenario is to know when people are ready. In my opinion there is no trick, but manager can use his judgment in this regard. One good way to deal with this would to build small prototype using all the capability intended to be leveraged. Here important thing to remember is that prototype should be built by people who will actually code rather than someone outside team. In fact if possible, prototype should be split into small-small prototype and distribute among all the team members to give then opportunity to gain experience on the new platform.
3. Buffer - If technology is rarely used outside your company then it might be good idea to have buffer. Attrition is reality in IT industry. If you are embarking on project involving technology for which it’s difficult to hire people from outside, it make sense to have buffer. Otherwise if unfortunately few people who got trained on the technology leaves, your project will be delayed because most likely you have to train new people from start than quickly hiring from outside to fill in the gap.
4. Milestone - It is very important that we have clear-cut milestone in such project. If possible have feature wise milestone. Because we already have product to compare with and document to build the feature using new technology, it should be possible to set clear-cut milestone. In absence of it, it would be very tough to gauge the progress and direction.
5. Validation - This as important as for any project. Having good test case is must. Random testing will not do the job. Because it’s very easy to miss some scenario and if failed to catch bugs before releasing to customer, it will be more embarrassing than bug found in new features. Because customer has been using those features and they don’t expect bugs in existing features (I don’t mean that they expect in new feature) but I have observed that outrage is higher in such cases. It will be even more if some features are added based on some customer feedback and he find it not working or missing or same bugs reappearing in the new version which got fixed after being reported by the customer.