For the last fifteen years, some commentators have predicted the demise of the mainframe, as customers move away from mainframes to Wintel or Linux/Unix platforms; and for fifteen years, for very good reasons, mainframe users have failed to do so.
Nevertheless, over the same fifteen years, non-mainframe platforms have steadily eroded the mainframe's advantages in performance, scalability, and robustness, while maintaining their strengths in open flexibility that leads to easier incorporation of new technology, and claiming advantages in TCO. Do these facts make migration a better idea today? Or does the question not arise, because migration is too difficult to perform?
Quantitative and qualitative research by Infostructure Associates personnel shows that migration is doable in many more cases that before. However, mainframe users by and large continue to resist migration. In some cases, resistance is due to an overestimate of risks and underestimate of benefits. In most cases, however, refusal to migrate is based on the time and expense -- not just the risk -- of migration, as well as the countervailing attractions of new mainframe software features that dramatically increase the mainframe's flexibility. These, we find, are strong reasons not to migrate.
Past studies by Infostructure Associates personnel have shown that:
- Mainframe users as well as non-mainframe users perceive mainframe hardware and software licensing costs as greater than those of Wintel and Linux/Unix platforms.
- Real-world users report successful migration of moderately important mainframe software to Wintel platforms.
- User experience and available Micro Focus products suggest that migrating COBOL,
applications from the mainframe is usually straightforward -- and these applications make up the
majority of those running on many mainframes.
However, the size and number of these applications on a typical mainframe can make migration of one machine a matter of a year or more. Most of the rest of mainframe applications involve DL/1, CICS, and IBM assembler code, and migrating this code requires much more effort, although some users report that migrating these applications is also doable.
Alternate strategies to migration include surround and sunset, in which mainframes continue to run applications developed before a certain date, while non-mainframe platforms run all newer applications; offload, in which a new non-mainframe application shares the workload of a mainframe; and replacement, in which the user writes a new non-mainframe application to completely replace the mainframe. All of these are viewed as less desirable than migration, usually because they make the enterprise's architecture more complex than either upgrading mainframe applications in place or migration.
CPU-intensive, rather than I/O-intensive, applications appear to deliver the largest immediate payback for migration. These applications include technical/scientific, batch, and medium-sized database (data marts) applications.
The majority of mainframe users continue to report that it is unlikely that they will move to a non-mainframe platform in the near future.
Mainframe applications today are primarily written in COBOL. Many of these also depend strongly on the CICS TP monitor, and on various data management tools (primarily VSAM, IMS, DL/1, and DB2). Recently, IBM has reported a steady increase in Web-servicization of these applications.
A closer look: The vendors
HP offers an extensive set of planning services, migration services, and support services for mainframe users considering moving to HP Wintel-based platforms. HP has noted four strategies for moving from mainframe to Wintel:
- Surround and sunset, or deploying a new application on HP/Intel instead of choosing a mainframe.
- Offload, or deploying a new application on HP/Intel and then integrating it with an existing mainframe.
- Rehost, or rehosting a mainframe application on HP/Intel.
- Replace, or deploying web-based versions of existing mainframe applications and then discarding
Past Microsoft benchmarking has suggested that Wintel performs better on some mainframe workloads than mainframe Linux, at a fraction of the license costs and TCO.
A closer look: The migraters
The experience of migraters has been surprisingly positive, given the difficulties that migration always imposes. One user was able to migrate all 2,900 programs -- and all end users -- over the course of only a year and a quarter. By contrast, another found that migrating CICS applications and moving from DB2 to SQL Server were "hard ports." Web-servicizing mainframe applications before porting apparently did not make migration easier.
The main barriers to changeover cited have been cultural resistance and difficulty of migrating some applications. Cultural concerns about the new platform have centered on concerns over its reliability and security — so far, in most cases, concerns about reliability have proven unfounded. Other cultural barriers have included a shift to a new programming environment, which could be counteracted with training.
Migraters have claimed the following benefits:
- Throughput. Migraters have noted that batch-job performance was especially good on the new platform compared to the mainframe.
- Scalability. Some users believe they have greater "headroom" than with their mainframes.
- Cost of ownership. This includes not only lower hardware acquisition costs, but also related software license costs — migraters have reported that many software licenses are tied to the number of processors on a machine, hence fewer processors for the same workload have meant lower software license costs.
- Open standards support/flexibility.
A key remaining concern of these migraters was security.
A closer look: Non-migrating mainframe users
Most mainframe users continue to plan not to migrate. A majority continue to be satisfied with their mainframes, although a significant minority are not. Mainframe users have been most satisfied with the mainframe's robustness, and most concerned about its cost of ownership and flexibility.
The primary reason for not migrating, for those not satisfied with the mainframe, continues to be migration risk. A significant percentage of non-migraters are concerned about the technology risks of the target platform. There is some indication that many non-migraters are not fully aware of all of the migration services available.
Technical concerns of migration
Studies of migration from the mainframe show that the risks and costs of moving key mainframe applications to Unix or Windows can in many cases be quite large. Mainframe applications are often so customized for the mainframe that they cannot simply be copied from one machine to another. This is particularly true for in-house-developed mission-critical and business-critical applications that have been around for a while.
For example, those migrating the application must have a deep understanding of the application's code and purpose — and often the application's documentation, or IT's knowledge of the application, has been lost or is inadequate. In some cases, migraters must rewrite much of the code in the application to run and deliver optimum performance on a very different type of computer — which could take months or even years. As a result, performance-critical applications may not perform adequately even after tuning; and new errors may creep in during the process, making the resultant application unusable.
For mainframe applications sharing a common data store, migration is even harder, if not impossible. If the data for one application is moved to a new platform and database — perhaps to integrate with applications on the new platform — then the applications remaining on the mainframe will need modifications in order to access their data from the new database, or application code must be written to keep the two databases in sync.
Scaling the migrated application likewise is often difficult. Today's application servers, although superficially similar to traditional mainframe TP (transaction processing) monitors, aim at load balancing across application code, not transactions. As a result, mainframe applications that scale well using mainframe TP monitors, such as IBM's CICS and Unisys' COMS, will usually require extensive adaptation to scale on Linux/Unix using Apache or JBoss, or in Windows using Microsoft's application server.
The most attractive alternative: Upgrade in place
As also noted in a previous article, tools for upgrading in place, and especially for Web-servicization of existing mainframe applications, are now field-proven and extensive. Middleware such as Unisys' ClearPath MCP solution and IBM's application modernization or enterprise transformation offerings, and Web-servicization tools such as those provided by IBM, allow connectivity from the Web to the mainframe and permit users to create application veneers that add e-business functionality, such as Web services provider code and/or composite-application business-process support for supply chain and customer relationship management.
The results of Web-servicization of a mainframe application typically are addition of new features, and extension of availability to a much larger class of users. This, in turn, leads to better ROI for the mainframe application and greater flexibility to add additional new technology — and thus, alleviation of many of the concerns that have led mainframe users to consider migration in the first place.
Migration from the mainframe is indeed, superficially, more attractive than it has ever been:
- More mainframe applications can be migrated.
- Target platforms have better scalability, price/performance, robustness, and in some cases TCO than ever before.
- Vendors offer more extensive support for migration than ever before.
However, reasons for not migrating are actually stronger than ever before:
- Migration continues to involve time frames greater than a year.
- Most mainframe-heavy data centers have many applications, a significant percentage of which are difficult or risky to migrate.
- The alternative of "upgrading in place", especially by Web-servicizing mainframe applications,
is easier than ever to do, and brings greater benefits in ROI and new-technology flexibility.
Most mainframe users continue to be better off not trying to migrate; however, mainframe users should also note that simply leaving mainframe applications as is, without doing anything at all to them, is in the long term a less desirable solution than either migration or upgrade in place. Staying with the mainframe may be smart; inaction is not.
About the author:Kernochan is president of Infostructure Associates.