Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

What you need to know about code conversion before your next application transformation


By: Francisco Fernandes, Solutions Architect, Hewlett Packard Company (Brazil)


It is difficult for CIOs to find the time to look for ways to reduce risk and keep their systems up-to-date. With technology rapidly evolving and its life span shrinking, IT lacks  cost-effective and risk-averse ways to keep pace with these changing technology trends.  It’s hard enough just to keep up.  This situation has led IT to search for ways to automate transformation efforts to support new business needs in a timely manner.  If this sounds familiar, don´t worry - you are not alone.




The challenge

When we talk about legacy applications (not technology), we are usually dealing with old source code that is often very complex, mission critical, poorly documented and lacks adequate resources to maintain. Applications reach  “legacy status” not just because their technology is old; it is a combination of factors. One example is Java.  Today, it is a target language for transformations along with the languages of other legacy apps which were written in the first releases of Java.


Transformations become even more complex when they move to completely different technologies. This blog will focus specifically on moving from Cobol to Java.  A common transformation path for legacy systems (mainly from mainframes to open source platforms) is moving from procedural programming to object oriented programming. The tools available to help in this transformation work used to follow a straight approach when converting Cobol to Java, but the level of automation available for this kind of project was not really making this job any easier.


A solution

Programming languages have evolved from assembler to 4GL, reducing the effort to write and some of the behind-the-scenes work. The same is happening now in a different dimension. Since OMG started to talk about MDA (Model Driven Architecture), some companies have started incorporating MDA in their development process and later in their tooling to accelerate applications development.  MDA is now being used in transformation projects, implemented by tools that are used to translate source code in two steps:

  1. Translate the current application into a model.
  2. Translate the model into source code for the target environment.


Why would this be advantageous to straight conversions?  With MDA, the transformation can generate a result that is the best fit for the target platform, rather than carry on the implementation characteristcs from the source platform. In other words, in a conversion from Cobol to Java, the result is an object oriented Java, not a procedural Java. This method represents a better alternative that accelerates the overall transformation process while reducing risk and effort.


But don’t forget: this is still an automated method, which has some disadvantages. For example, the source code generated can sometimes carry vendors libraries and are dependent on IDEs which must be maintained. (Note: You could maintain the source code using the models or directly on the source code.)


Some factors to consider when selecting your transformation partner:

  • Look for market references – good work is always propagated.
  • Avoid any dependence on vendors after the conversion – this is often an issue with IDEs, frameworks and libraries implemented by the vendor (together with the generated source code).
  • Run a POC before making a final decision – it is always good to have a sense of what you are going to receive. Have your SMEs look at the results and assess the pros and cons.
  • There is no one solution that fits all. Look for flexibility when planning your transformation. You may want to combine automated tools with manual rewriting.
  • Understand the true scope of your application metrics like complexity, size, maintainability and frequence of change. This will help you better plan your transformation strategy. If a vendor ignores these things, run away from them!



The result when using MDA is code conversion that is more reliable - it  should be considered for Application transformation proejcts. New approaches continue to emerge on the market and one of them may be a good fit for your legacy applications. But remember: one size doesn´t fit all. Be prepared to combine automated tools with manual rewriting to accomplish your transformation objectives on time and within budget.


Have questions or comments?  Please use the comments section below!


Previous blogs by Francisco Fernandes:


Related information: 


About the author


foto 3x4 francisco.jpgFrancisco Fernandes, Solution Architect, Hewlett Packard Company (Brazil)

Francisco is a Solutions Architect and an Applications Modernization Expert with more than 20 years of experience working on Applications in different industries including banking, financial services, telecom and healthcare. He joined HP in 2002 and is located in Rio de Janeiro, Brazil.


steve rubin | ‎03-30-2014 07:26 PM

Hello Francisco,


Have you concluded on (what you consider to be) best-breed vendors for MDA-based COBOL2Java conversion (SLA, NA, EMEA)?


Thank you for the article, timely ...



Fran_Fernandes | ‎03-30-2014 07:32 PM



We have tested couple of MDA tool providers and most of them have generated reasonable results. Please, contact me directly so I can provide mora information on that. Reach me at



Showing results for 
Search instead for 
Do you mean 
About the Author
Solutions Architect working at HP since 2002 with focus on Applications Modernization, located at Rio de Janeiro, Brazil

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.