Motivations for migration

The primary motivation for migration is, as in most other cases, the bottom line.  Over time it becomes progressively more expensive to maintain and enhance legacy software developed in house due to some of the following reasons:

  • Limited vendor support – vendors move resources away from legacy platform support, reducing service pack release frequencies, which in turn:
    • Leaves thus discovered platform bugs and security gaps unattended for longer periods, requiring additional in-house development effort
    • Chokes the flow of more contemporary features, raising the opportunity cost, when compared to advances in RAD, for example
  • Higher integration cost – as systems are in ever increasing need of more integration to raise productive capacity, legacy platforms may be at a noticeable disadvantage in terms of additional development effort required to integrate with contemporary platforms and that gap only widens over time
  • Talent shortage – skilled and willing legacy developers become harder to find and retain, potentially raising turnover and training costs

Despite these and other reasons about 80% of production IT systems, according to developer.com, are running on legacy platforms.  At the heart of the issue again is the bottom line, mainly because identifying the actual cost of maintaining legacy code has challenges and disagreements, some of which are discussed in a 2009 article published by ITBusinessEdge.  Compare that to the highly visible and easily identifiable initial investment to migration projects and the management reluctance becomes obvious, until at least some TCO analysis is performed.

Pre-migration preparations

Once a decision has been made in favor of migration the first consideration should be the build versus buy analysis, each of which has many context specific pros and cons.  Should a full or partial build approach be taken, the following preparatory steps must be considered to minimize the total cost of the Endeavour and maximize the probability of success:

  • Identify concrete objectives and measurement units – list of business functionality, performance parameters, scalability ranges, and security measures, etc., in comparison to existing legacy application(s).  This list will be used for various aspects of project management, not the least of which is quantifying success
  • Select target platform – there are two heavy weights in the world of enterprise software development, .Net and Java as illustrated by Gartner.  Select one that minimizes TCO and is in sync with long term corporate objectives and directions

  • Select deployment strategy – full migration versus partial and incremental migration.  Depending on you specific scenario, one option may be more cost effective than the other.  Generally, however, an incremental approach provides more flexibility, transparency, and adjustment opportunities
  • Train your team – devise a schedule for training to prepare your existing resources on the target platform.  It’s crucial to train your development team well on the target platform.  This single factor, if not properly managed, has the potential to substantially raise operational expenses, e.g., cost of support, maintenance, and enhancements over the life of the product while raising the necessity for rewrite

Developers coding on a platform they are not trained on codes for the platform they were trained on

  • Acquire expert review – subscribe to services whereby development artifacts produced by your team may be objectively and iteratively rated and guided, because higher quality translates to lower TCO

The old quote, “An ounce of prevention is worth a pound of cure”, is as applicable to migration projects as it is to any other aspect of software development.  Prepare well and you’ll pay less, both in monetary and political terms.  In the next article I’ll analyze some of the key considerations for migrating legacy codebase to the .Net platform.