Mainframe Migration

Mainframe migration is still being attempted today nearly six years after the Y2K craze. The technology gap that existed in Y2K has widened even further, but the emergence of SOA is fueling new initiatives to move critical data off the mainframe. It is estimated that 80 to 90 percent of Strategic Business Data is still located on hierarchical databases like CICS and IMS running on mainframe computers. Mainframe Migration has become even more prevalent now because mainframe and COBOL programmers are harder to find when a company loses one to retirement or attrition. Almost every mainframe migration has started with some screen scraping or off-loading of the data to Unix servers. This has been marginally successful in most cases because an assessment of the application and the data structure was never done. Instead, engineers just moved the data structure as it was on a hierarchical database down to a relational database. Most times this was a disaster. Other approaches were to move the applications off the mainframe and access the data via gateways or wrappered solutions. See NXTware Data Access Engine for more on this approach.

Mainframe migration never seems to finish however. Whether the data is moved or the application the mainframe always seems to remain because of requirements of other departments. That is why mainframe migration projects fail: the cost savings that were projected when the mainframe is eliminated (hardware lease, software licenses, software support, mainframe programmers, electrical power reductions, etc.) are never realized. The IT manager is replaced and the next cycle begins. 

The most effective way to migrate applications off the mainframe is with the eCube ARM process. Using this approach (Assess, Remediate and Modernize) to analyze a potential mainframe migration would solve the dilemma on migrating mainframe applications. The Assessment phase of ARM would analyze the existing system and evaluate business drivers that are prompting the mainframe migration project. The existing system would include not only the hardware and software applications involved, but the existing business processes, manual procedures, business requirements, skills assessment and knowledge assessment as well. These factors are compiled into a repository that will determine the risk level for this mainframe migration project. The product of the Assessment is the Assessment report which will cover in detail the areas analyzed and make recommendations and proposed solutions. A feasibility statement will take into account all of the variables analyzed and make recommendations whether or not to proceed to the remediation phase. The advantage of this phased approach is that there is a tangible benefit delivered at the end of each phase. The client can decide whether to proceed, or wait for the computer industry to change its direction once again. For more information on eCube's ARM process, see the ARM section of our site. 

Modern mainframe computers have abilities not so much defined by their performance capabilities as by their high-quality internal engineering and resulting proven reliability, high-quality technical support, top-notch security to protect mainframes, and strict backward compatibility for older software. These machines can and do run successfully for years without interruption, with repairs taking place while they continue to run. mainframe computer vendors offer such services as off-site redundancy — if a machine does break down, the vendor offers the option to run customers' applications on their own machines (often without users even noticing the change) while repairs go on.

The robustness and dependability of these systems has been one of the main reasons for the lack of success with mainframe migration projects, as they are used in applications where downtime would be catastrophic. The term Reliability, Availability and Serviceability, or RAS has become a marketing term used to denote this robustness. This robustness is often the argument used against mainframe migration or replacement with other types of computers.

Mainframe computers often support thousands of simultaneous users who gain access through "dumb" terminals or terminal emulation. Early mainframe data access computers either supported this timesharing mode or operated in batch mode where users had no direct access to the computing service; it solely provided back office functions. At this time mainframe data access computers were so called because of their very substantial size and requirements for specialized HVAC and electrical power. Nowadays mainframe computers support access via any user interface, including the Web, making complete mainframe migration unnecessary.