Red Flags to Consider When Moving From Mainframe to an Open System

When it comes to mainframe systems, the decision to remain competitive is easier said than done. For example, the proprietary nature of older Unisys and other mainframes is incompatible with current software applications that could increase productivity and profitability. This incompatibility leads to a dilemma: Do we continue to write applications for the existing mainframe or move to an open systems architecture? In this eWEEK slide show, Craig Marble, senior director of Legacy Modernization Services at Astadia, offers his own perspective. Astadia, based in San Francisco, provides cloud-solutions consulting and systems integration services. Editor’s note: For the record, Unisys has made major changes. The company has phased out its decades-old propietary mainframe processor and moved to Intel’s x86 chips to increase system openness and reduce costs.

Any decision to change the mainframe can run into several roadblocks. Here are three potential problems: 1) Staffing: The age and complexity of many mainframe systems often require time and expertise not available through current staffing. 2) Risk: Organizations cannot afford the loss of legacy data, the degradation of mission-critical applications or the interruption of profitable services. 3) Economy: The cost of writing new applications or purchasing licenses often exceeds the immediate cost of preserving current system architecture.

Nevertheless, internal and external changes continue to drive the urgency for change. Business partners implement systems that are incompatible with current mainframe architecture. Groups within the organization require business intelligence unavailable through the current database design. Customers switch to organizations that can provide enhanced services at lower cost. The time for change has arrived, but any solution must pass an acid test to meet the criteria for success and added value.

Any attempt to move from an old mainframe to a new system requires consensus building and buy-in. Financing is not the only challenge. Members at all levels of the organization will either reap the benefits or live with the consequences. In addition to ROI, a successful solution must satisfy requirements for stability, scalability, availability, flexibility and usability. Few organizations can meet these criteria in isolation. The intricacy of moving from Unisys to an open system requires a systematic approach that is well-equipped and informed by experience.

Open systems conform to well-documented standards and avoid the proprietary issues so prevalent with mainframes. Companies can evolve quickly through add-on technology, with the freedom to leave development time and costs to another party. In most cases, organizations need only purchase, install and periodically upgrade the add-on. Apart from a few configuration tasks, little or no programming is required. All of these factors can lead to significant savings and an agile response to paradigm shifts.

One of the main challenges with migrating Unisys applications is ensuring open-systems compatibility without sacrificing years of architectural and business logic development. For this reason, a rules-based transformation approach is necessary in order to leverage business logic while making only the changes necessary to accommodate the underlying architecture of the target platform. This approach is made possible through the use of proven runtime software products designed for translating and managing mainframe-specific operations with the target environment. Once the transformation rules have been established and verified, automation can and should be used as much as possible to increase ROI and reduce risk to a minimum.

Moving the application(s) from mainframes to open systems is just one piece of the puzzle. Legacy data must also be transformed and migrated to the target platform while ensuring integrity remains intact. This is complicated even more when the mainframe database product has no equivalent on the target platform or when data migration requires going from one type of database management system to another, such as moving from hierarchical to relational architectures. Again, a rules-based, automated approach to this process is essential for both speed and accuracy.

The final pieces of the puzzle are testing and project management. As with any project, testing is crucial and often underestimated in terms of effort and duration. This is especially true for mainframe migration projects as many legacy applications have very little documentation or test cases, which often results in developing new test cases and verifying their accuracy while simultaneously using them for testing the migrated application. Developing a test plan from the very start of the project is essential to preventing delays and ensuring test cases are ready for use when required. Testing and all other aspects of a mainframe migration project must be carefully planned by experienced professionals familiar with the pitfalls of mainframe migrations and then managed by highly-skilled project management resources.