Mainframe applications have been criticized for spiraling maintenance costs, the result of a vicious circle of lack of documentation and lack of ability to upgrade, leading to higher costs of maintenance or upgrade right now. At the same time, most enterprises recognize that their existing mainframe applications are business-critical but old, and therefore cannot be leveraged as much as the business would like. Thus, these applications need to be modernized.
Where possible, these applications should be upgraded in place — modified on the mainframe rather than migrating them to a new platform.
Choosing the right approach
Today’s enterprises typically consider four strategies for integrating new technologies with their existing mainframe application suites:
Upgrade in place. The program and its data are kept on the mainframe, and the developer applies mainframe tools that integrate the new technologies with the mainframe application.
Migrate. The program’s source or binary code is moved to another platform with little or no change, and the developer applies tools on the new platform to add the new technologies. Note that the application’s data may be moved to the new platform as well, or may remain on the mainframe.
Regenerate. The program is first reverse engineered, a process that creates an abstracted design model of the application. The application is then regenerated from the design model on the new platform. The new technologies are either embedded as a result of the regeneration process or added once the application is up and running on the new platform (again, the data may remain on the mainframe or can be moved to the new platform).
Replace. IT discards the existing application and writes an entirely new one, on the mainframe or a new platform. The new technologies are “designed in” to the new application. The new application supposedly incorporates at least the same functionality as the old.
In the past, enterprises tended to choose a replacement strategy if a new technology had to be added; otherwise, they simply left the application as is — the risks of changing a business-critical application in any way were seen as so great, and the difficulties of changing it so daunting, that anything was preferable to touching it at all.



Hi
A true legacy migration would mean not a single line drop of the precious business logic that exists on mainframe as well as (equally important) re-engineering into object oriented form being deployed on Java or .Net.
There are other bits and pieces as well that are related to transactions, security and processing speeds on the new platform…
Please see my article regarding this subject.
http://hubpages.com/hub/Application-Rationalization–Modernization-Strategies-for-Investment-Bank-IT-Division
Thanks