Migrating From Legacy Applications?

Legacy applications are firms’ applications that are based on old and sometimes outdated programming languages. For most large companies, they are an everyday challenge. Usually found within critical applications, legacy systems continue to be used as they still deliver value performing daily tasks even though newer and more efficient methods exist.
A recent survey from Nexaweb Technologies revealed that, out of 750 IT professionals, 88% claimed to have a problematic legacy application burden, with 57% of which categorize their problem as “serious” or “very serious”.

Buy, Develop or Migrate?

To deal with legacy systems companies can take different paths:  buy or develop a new application, or migrate. They have to chose which approach should be followed according factors such as size of the project, the level of customizations, how critical the application is, and maintainability.

With buying a new system, companies have to keep in mind that each business has its own specifics and applications rarely meet the exact needs of firms. For that reason further developments at an extra cost are required for customization. Development of a new application allows more flexibility and results in a product that exactly fits the customer’s needs. Nevertheless the bigger and the more complex the application is the more difficult it will be to redevelop. By purchasing or developing, companies need to carefully test the replacement and the risk of errors, bugs, or misconceptions is high (unlike migration with Service Orientated Architecture (SOA).

Migration differs from the two previous methods in that it actually takes the old application and translates it into a modern version. It also reuses the original systems’ business logic which guarantees that the migrated application will be functionally identical to the original. The legacy applications have been operational for several years or even decades, they are tested and work 100%. With the right migration code and cross platform technology, the migrated application will be correct, plus with the Build to Order technology the modern version will exactly fit company's expectations.

Types of Migration

Companies can perform three types of migration from 0% to 100% automatic. Manual migration is about re-writing all the lines of codes by hand. Imagine here one developer sitting on a desk with two screens, in the first he reads Cobol and in the second he writes Java. That solution makes sense for very small applications, probably less than 10 000 lines of code. In contrast, with automated migration a program reads Cobol and writes Java. What is interesting with this method is that automation makes the process both faster and safer (see previous post for more details about automated migration, cross platform technology and SOA).

Legacy applications are generally huge (typically millions of lines of codes) and often complicated (given that they are critical), a program will translate faster and make less mistakes than a developer. Next to the “line-per-line”-approach, automatic migration can also use smart patterns to detect and change programmatic concepts. In doing so, architectural changes according to the program structure can be made and the converted program becomes much more flexible and maintainable. Somewhere in between, there is semi automated migration. A program will automatically migrate parts of the code and developers will manually migrate what’s left. For example if some concepts in the original system can not be translated with a feasible effort, the migration tool will leave it to the developers. The more complex and critical the application is, the more automated the migration should be.

IT migration as a strategic move

Even though IT execs acknowledge the need of moving away from legacy applications, and that relevant technology exists, it is what business executives think that matters. They are those who decide on the funding of migration projects but they are also those who don’t particularly see the challenges of IT. IT is often seen as a technical function hence the connection between IT modernization and operational concern isn’t clearly established.

Besides, in these times of economic insecurity, investments are reduced. The problem with doing so is that it is likely to offer market share to competitors who look at out of the box solutions. In 2008 Diamond Management and Technology Consultants analyzed the performances of 400 companies during the 2001 recession. According to their results companies that made the strategic decisions by being "smart about their cuts" and "successfully improving the design of their business", increased their margins by 20%. The question in then: Is migration a strategic decision?

Let’s illustrate the need of modernization with an example in the mobile phone industry: Around a decade before Apple, Nokia spend millions of dollars on research to develop touch-screen devices very similar to smartphones. Although the technology was in their hands they redirected efforts from smartphones to basic phones. In 2007 Apple came up with the iPhone and the success we all know. By sticking to old technologies Nokia progressively lost its position of world's largest maker of mobile phones. Its share price went from US$40 in 2007 to less than US$3 in 2012. In Contrast, in 2007, when Apple released the iPhone its stock was selling at about $85. By the time Job resigned in 2011, it had risen more than 350 percent. In June 2012 Nokia’s CEO even had to admit that the problems the company was facing were mainly due to the failure to anticipate the changes in the industry.

In the same way, IT modernization and the risk of aging platforms is an urge that execs should be aware of: Migration is a must; the question is not if but when!