Based on this legacy, a significant portion of today’s transactions is still processed by mainframes. Yet, unlike in the beginning of the computer era, big businesses no longer require mainframes to handle large volumes of data quickly and accurately. Today, the largest transactional systems in the world don’t run on mainframes.
Leaders such as Apple and its iTunes and Apps stores, Facebook, Amazon, Google and most leading Telecommunications companies and retailers no longer operate mainframes.
Most importantly, new competitors across all sectors of the economy are challenging incumbents without the handicaps of old mainframe technologies, and therefore benefitting from radically lower costs and far faster response times in launching new service offerings. Refer here detailed migration analysis.
The New York Stock Exchange (NYSE) is migrated to a 1,600 millions of instructions per second (MIPS) mainframe to IBM System p servers running AIX and x86 Hewlett-Packard Co.
Strategies of Migration:
Integration: Moving Part of an Application
Integration involves moving one or more components of an application to the Windows platform. For example, one scenario may be to move executable components, but leave a database shared with other applications on the mainframe. Application components such as reporting job streams, high volume printing, or read-only queries may be separated from the rest of the application and migrated on an individual basis.
Integration will often be the first step an organization takes in migrating an application, because it mitigates costs and risks. However, this strategy may not deliver a sufficient degree of benefit commensurate with the required investment when compared to other available strategies that potentially eliminate the mainframe.
Code Migration: Moving an Entire Application
Code migration involves recompiling or converting the application source code to the new platform. Many third-party tools are available to ease this process, especially for applications written in COBOL. When using this technique, it is important to decide whether to migrate existing bugs associated with the code or fix them as the code is recompiled.
This strategy is an extended and complex process that can easily be underestimated because a large number of different technical components must be migrated. Recompiling code may not adequately address the needs of changed business processes, which may be the real benefit of the new application.
Replacement: Adopting a New Windows Application
The replacement strategy takes advantage of the availability of relatively inexpensive Windows versions of many “off the shelf” software packages. The old application is withdrawn from service and its functionality is replaced by the newly adopted Windows application. The issues in this strategy center on the adaptation of the business processes to the capabilities of the new applications, which are unlikely to exactly duplicate those of the old application.
Evolution: Begin to Develop Applications in the Windows Environment
The evolution strategy advocates using the existing application as a starting functional specification, and then rebuilding the application using modern programming languages and tools. The challenge here is to maintain existing applications and infrastructure as required while creating new applications and infrastructure. This may be an effective strategy to employ when you need a major new application without eliminating the older application.
Gartner Research Mainframe Modernization
More information I will publish in my next post.