The market of mainframe modernization and cloud migration, where a complete (mainframe) application is automatically migrated to a fully equivalent modern application has long been the exclusive field of highly technical and specialized companies. Today, many of them provide automated refactoring solutions, with varying degrees of automation. At Astadia, we provide truly automated refactoring, meaning both code and data conversion are 100% automated – with automated testing as an extra bonus.
This means that complex migration processes can be almost entirely automated, which results in minimal turnaround time for workflows, no errors or delays, and reduced costs of the overall project. Moreover, it gives IT teams confidence and control over the transformation project.
At Astadia, mainframe migration projects are highly iterative processes. From day one until the go-live we perform the same steps:
1. Convert the entire application
2. Run the entire test set
3. Analyze differences between desired and actual behavior
4. Correct any potential issues
By using our tools to do the bulk of the work, these iterations can happen very quickly – it takes only a few hours to convert and test an application with millions of lines of code. This allows us to focus on correcting any potential issues. We get near instant feedback on whether the issue is fixed, and whether any new issues were introduced.
Apart from this “daily cycle” of convert/test/tune, there is also a bigger cycle that repeats roughly every three to four months. At the start of each such “big cycle", we take a snapshot of the application at that moment in time. During the following months the migration project will operate on that static copy, while the real application continues to evolve in parallel. As we enter the next project phase, we again synchronize the migration project with the then current production state of the application.
This allows us to have a relatively stable migration environment, while daily maintenance on the production environment can continue unhindered, and in parallel to the migration project. This means we have zero code freeze during the entirety of the migration project.
At the start of each big cycle, a snapshot of the application is taken. That snapshot contains all application source code and configuration. It also contains test data and test scenarios provided by the client.
These tests will serve as the acceptance criteria for that phase. During the remainder of that phase, we are going to run the daily cycles on this snapshot: convert the code and the data, run the tests, see if it works, and fix where needed. If all tests succeed, we know we have achieved the goals for that phase and can advance to the next major cycle.
Let’s zoom in on the processes behind the tests. Here too, everything is automated to the max. There are three distinct actions:
The recording happens on the reference environment - the original application. We offer several ways to record test scenarios, but the easiest is the so-called Proxy Recording. Our TestMatch tool sits between the terminal and the mainframe. The testers simply use the application to perform several actions. Their interactions are captured in TestMatch while they pass to and from the mainframe, and they instantly become the test scenario.
Once the scenario has been recorded, we can replay it over and over again onto the migrated application. No human interaction is needed anymore. The user input that was previously recorded is now submitted automatically to the migrated application. The application responses are again recorded for subsequent analysis. During the replay we can optionally suppress user think time from the original recording to make the replay even faster.
The third step finally is to compare the original recording with the replay recording. The main premise of our “like for like migration” is that the original and the migrated application should behave completely identical. So, given the same inputs, the migrated application should produce the same outputs.
The test tool will compare each screen for differences: in text content, in attributes like text color, even invisible text is compared. Differences are highlighted and can be inspected in their context. Expected differences like time stamps, dates can be marked “to be ignored”. Real differences can be submitted for further analysis and follow-up in a bug tracking system, directly from within TestMatch.
We can compare functional behavior, like screen content, but also non-functional behavior, like performance. Our test tools can compare original response time with the response time of the migrated application, to ensure that performance is at least as good as it was on the mainframe. This is one of the three promises we make for each of our migration projects: functional equivalence, performance equivalence and maintainability equivalence.
Our automated testing tools save hundreds of man-days in typical migration projects, by allowing the tests to be replayed continuously without any human interaction. Our migration specialists can focus on locating and solving issues during the migration.
The tools can also provide some very clear metrics to the project board, about the state and the evolution of the project. The number of daily tests succeeded and failed provide a great summary of past performance and trendlines for the future.
To conclude, using powerful automated testing tools is a vital part of any migration project. It is reassuring to know that every aspect of the project is being constantly tested. This is key in building up confidence with all stakeholders that by the time of go-live, the migrated application will have the stability and maturity it requires to move into production.
Want to see TestMatch in action? Reach out to our team for a live demo.
Here are some of the most common mistakes in legacy transformation projects and how to avoid them when designing your modernization strategy.
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.
For nearly a decade, IBM’s z14 family of mainframes have served as a reliable IT workhorse for numerous enterprises. But like all good things, the z14 will eventually come to an end.
Test for free the FastTrack Factory and get your COBOL code transformed in unprecedented timeframes.
If you’re currently running Adabas & Natural or IDMS on z/OS, chances are pretty high that you’ve been thinking about the need to modernize those systems at some point. Here are some factors to consider when planning your roadmap.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now