APPLICATION MODERNIZATION

As applications age and newer technologies become available, companies often face an increasing pressure to modernize application portfolios.  The dilemma to go ahead with such projects is not always a simple one to solve.Reasons to keep an application on its current platform include:

  • It works, why break it
  • Resources busy on other business initiatives
  • Migration project cost

Reasons to re-platform include:

  • Opportunity to re-architect the system / aging technology
  • Opportunity to better include new functionality
  • Expected shortage of resources
  • Current platform costs

There are technologies that offer various levels of code parsing or generate, for example, Java code or transform databases onto new platforms. To take advantage of opportunities, these, otherwise focused products are often oversold as migration solutions.

Indeed, application source code can be transferred onto a new platform using these, or a combination of these products. Some companies even began to promote ‘fully automated’ solutions. However, the result is almost always a less than desired one. The new application is hard to maintain, lacks any features the new platform could offer or simply isn’t even providing the functionality of the old.

 

Many excuses can be found for the subpar quality of such migration efforts – for example blaming the quality of the old code. However, the real reason behind unpleasant results is simple: the applied solutions fail to recognize the vast difference between ‘blind’ code transformation and bringing a full application onto a new platform.

 

Mapador Inc. offers integrated answers to both components of an Application Modernization requirement:

  • Application Migration:  transfer applications from older technologies to newer / more cost-effective platforms (programs or programs and data)
  • Data Migration: automatically transform data from flat files / older databases to new environments.

 

432_Migration

While our Migration Process itself is completely automated, it contains customization points where skilled personnel can intervene as little or as much as desired and agreed upon.

 

The process takes the old application / data structure gradually apart into its logical components, thus producing a more and more abstract representation of the old source. Once in this format, even a complete redesign is feasible with relative ease or additional functionality may be added, if so desired. But of course, for straight conversions the process can directly proceed into the next phase where the components are reassembled onto the new platform, producing a more and more concrete representation of the application / data, now on its new platform. This high level migration philosophy is depicted in the diagram below.