In March, Astadia announced the availability of our Migration Factory™, which automates the process of moving IBM and Unisys mainframe applications and databases to distributed and cloud computing platforms. Through Astadia's acquisition of Anubex, we have combined our company’s industry leading expertise in mainframe modernization with a world-class toolset that industrializes the refactoring of legacy workloads, simplifies the migration of databases, and enables a holistic and automated approach to testing the end-to-end migration process. In this article, we’ll take a deeper dive into the Migration Factory to offer a more complete picture of what it does and the tremendous value it provides.
To begin, let’s step back and look at the big picture. Over two decades ago, Anubex began the development of its refactoring toolset, which today encompasses a broad set of technologies to help customers migrate from COBOL, Assembler, IDMS and Natural ADABAS to Java, C#, or other modern languages alongside virtually any of the leading SQL databases.
By industrializing this process, Astadia’s Migration Factory helps our customers accomplish their goals much faster than they otherwise might, reducing the duration of a typical migration project by as much as 90%. Automation also reduces risk because it enables repeated testing based upon real-world scenarios derived from actual user input to your production system, recorded and replayed in a refactored test environment to ensure functional equivalence to existing legacy systems.
Let’s explore the Migration Factory in further detail; it consists of four main building blocks, which we call CodeTurn, DataTurn, TestMatch and DataMatch.
CodeTurn automates the refactoring of legacy code into modern programming languages such as Java, C#, or others. In doing so, we can achieve automation levels of approximately 99.99%. The other 0.01% of the time, when human intervention is required, it is triggered as part of the broader automated workflow process. In other words, even the need for human involvement is part of a larger set of well-orchestrated procedures.
DataTurn automates the migration of data from legacy databases such as IDMS and Natural ADABAS to virtually any modern relational database, – including SQL Server, Oracle, IBM DB2, PostgreSQL, and others. DataTurn does more than simply map existing data schemas to a relational data structure, though. The toolset allows customers to modify data structures to better suit their needs following the data migration.
For example, in a legacy application that allows each customer record to be associated with 10 different phone numbers, the original schema might have been designed as a flat record, with each customer record containing 10 separate phone number fields (Phone_01, Phone_02, etc.). In the target relational database, it might be preferable to store customers’ phone number information in a separate table that links on the customer ID. In this way, database designers can transition from a flat (and less flexible) data structure to a relational one-to-many model.
Of course making those kinds of changes has an impact on code refactoring, though. If data structures change, then queries must be modified to follow suit. That’s why DataTurn works together in conjunction with CodeTurn to ensure that refactored code is generated in such a way that it can continue to access the right data, even when the underlying data structures have changed. As code is refactored and database tables and fields are mapped from the old system to the new one, the Astadia Migration Factory automatically generates an I/O module that handles SQL queries in the new system on the fly.
In this way, CodeTurn and DataTurn come together to form a powerful combination that enables refactoring and database migration to operate as a seamless whole. As we noted earlier, however, the Migration Factory incorporates two more components, – TestMatch and DataMatch.
TestMatch uses tracing capabilities within source IBM or Unisys platforms to record user activity in the live production system. In this way, the Migration Factory’s test automation processes have access to real-world test cases at any time, based on actual usage of the legacy system. TestMatch “replays” that user activity in the target system as an automated test scenario. Next, TestMatch will compare the activity traced on mainframe with that of what's being replayed on the target platform and flag any errors.
DataMatch then performs a comparison of the source and target databases, – adjusting for any modifications that might have been made to the target data schema as part of the migration process, – and reports any discrepancies, providing fully automated support for testing batch code this way.
Because the tools in the Migration Factory are so highly automated, the processes of re-running data transfers, recording test scenarios, replaying those tests in the target system, and validating the results can be performed quickly and efficiently. That means tests can be performed as many times as is necessary to build confidence that the resulting target system will behave in a functionally equivalent manner relative to the legacy system.
In terms of risk mitigation, this is a game-changer. With the Migration Factory, we spend most of our effort working with clients to design and map the migration process. Once that is complete, we can run test after test, as many times as we want, using the latest data and new test scenarios based on actual user activity. By the time we’re ready to go live, we know exactly what to expect. We know how much data needs to be moved and how long the process will take. We will have run as many test scenarios as necessary to establish complete confidence in the migrated system.
Whereas many traditional migration projects are executed in stages in order to mitigate risk, the Migration Factory enables a clean cutover of both code and data to a new target system, because the migrated system has been so thoroughly tested. While some of our clients will still opt to perform their migrations in stages, – the Migration Factory provides a considerably greater range of options, in large part because the risk involved with performing a clean cutover is so dramatically reduced.
Everybody agrees that automation is key to mainframe modernization regardless of the selected transformation approach, particularly in replatforming or refactoring projects. Not everybody, however, has the vision to automate the journey all the way.
COBOL talent shortage is a major mainframe modernization driver and that’s when every IT leader must make a decision about what will happen to the COBOL programmers in this scenario.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now