Eight Steps to Easing the Transformation From Legacy to Open Systems

Bob Dylan famously said: “If you’re not busy being born, you’re busy dying.” The same thing can be said for businesses, which come and go at a fast rate, including in IT. New equipment is bought, it runs for a period of time (sometimes longer or shorter than expected), it eventually wears out, and it is replaced. Software doesn’t wear out like hardware, but it does go out of date as systems get faster and more complicated. By necessity, IT managers are always looking ahead to what they will need two to three years ahead. In this eWEEK slide show, using industry information from Craig Marble, senior director of Legacy Modernization Services at Astadia, we offer suggestions for legacy modernization.

When it comes to mainframe systems, the decision to remain competitive is easier said than done. For example, the proprietary nature of Unisys mainframes is incompatible with current software applications that could increase productivity and profitability. This incompatibility leads to a dilemma: Do you continue to write applications for the existing mainframe or move to an open-systems architecture?

Any decision to change the mainframe can run into several roadblocks: 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 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 prevent delays and ensure 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.

Following these best practices will ensure a transition that is smooth and seamless to the end users and embraced by IT staff—and will launch your legacy applications into the digital world.