iTranslated by AI
re:Invent 2025: Accelerating Mainframe Modernization with Agentic AI - Case Studies from Itaú & ADP
Introduction
By transcribing various overseas lectures into Japanese articles, we aim to make hidden, high-quality information more accessible. This project introduces the following presentation!
For transcript articles of re:Invent 2025, please check the information compiled in this Spreadsheet.
📖 re:Invent 2025: AWS re:Invent 2025 - Reimagine mainframe workloads at speed with agentic AI - ft Itau & ADP (MAM207)
In this video, Paulo, Worldwide Tech Leader for AWS Mainframe Modernization, explains reimagining patterns for mainframe workloads alongside Anuradha Verma, Vice President of Product Development at ADP, and Douglas, Mainframe Platform Executive at Itaú Unibanco. The session introduces methods to automatically extract business rules from legacy code and rebuild them into a modern architecture using AWS Transform and an agentic IDE tool called Kiro. ADP extracted 8,000 business rules from 70,000 lines of code, achieving a 2x increase in efficiency. Itaú processed 600,000 lines of code, reducing time by 96% for reverse engineering and 82% for forward engineering, while improving test coverage from 20% to 80% and achieving an overall 75% speedup. New features such as data lineage, data dictionary, and test automation were also announced.
Note: This article was automatically generated while maximizing the retention of the original presentation content. Please be aware that there may be typos or incorrect information.
Main Body
Three Strategic Patterns for Mainframe Modernization: Replatform, Refactor, and Reimagine
Welcome to MAM 207, Reimagine mainframe workloads with agentic AI. Some of our customers struggle with high costs, increasing risks, and a lack of agility due to hosting core applications on mainframes. My job is to work with these customers to modernize these workloads and migrate them to AWS, helping them increase agility, reduce costs, and mitigate risks. I am Paulo, Worldwide Tech Leader for AWS Mainframe Modernization. Today, I am honored to be joined by Anuradha Verma, VP of Product Development at ADP, and Douglas Santos, Mainframe Platform Executive at Itaú Unibanco. Thank you for sharing your stories about the journey of reimagining with AWS Transform and Kiro.
In this session, we will specifically cover the 'Reimagine' pattern. First, I will explain what it is. Next, I will cover common challenges in the reimagination journey. Then, I will discuss the roles of AWS Transform and agentic IDE tools like Kiro—and explain what they are in case you aren't familiar with them. Afterward, Anuradha will explain ADP's journey and the results achieved by reimagining their mainframe workloads using this approach. Then, Douglas will explain Itaú's journey of doing the same. Finally, I will wrap up with some of the launches we made at AWS Transform this week and how you can get started on your journey.
When customers begin modernizing mainframe workloads, they must first face a strategic decision. You need to determine what strategy you will use to modernize your mainframe workloads and what combination of patterns will best achieve your business goals. Customers often use "replatform," which allows for a rapid move away from the mainframe. In short, it maintains functional equivalence by recompiling COBOL code so it can run on x86, executing it on a runtime that provides features similar to those available on the mainframe.
Another very common pattern is "refactor." Using refactor, you can convert COBOL code into a modern language like Java and run that Java application with libraries that also provide mainframe-like functionality. This also maintains functional equivalence, but at least allows for a technology refresh since you can move away from the mainframe technology stack. Another very common pattern is "reimagine." Reimagine is used when customers need to rethink business processes and applications—if you want to deprecate some business rules, add new ones relevant to current needs, and change the architecture from the ground up.
For example, even if there was validation logic executed in the past, if it relates to regulatory requirements that no longer exist, that part of the code is never executed. It just adds to the maintenance burden. You can delete those. If you need to add new features to your environment or ecosystem to compete with digital-native businesses, you can add those new features. And, for example, if batch processing is providing D+1 information to your customers, you can redesign them into an event-driven architecture to provide real-time information to your customers. There are many other patterns not listed on this slide, but depending on your needs, "retire," "retain," or "replace" might also be relevant.
Characteristics of the Reimagine Pattern: Small Scope, Decentralized Governance, and Addressing Integration Complexity
What sets the Reimagine pattern apart from others? First, it is the scope. When you perform a "reimagine," you typically do it with a smaller scope. That is, instead of migrating the entire system, you focus on application functionality. This allows for more frequent deployments and enables you to get more value earlier. As such, you can focus on key features that provide competitive advantage and release them as quickly as possible. When you do this, the other side of the coin is that you add complexity to the environment. Since integrations are being added, you need to deal with that as well, which I will cover in a few minutes.
Governance is also different. Instead of the centralized governance typically seen with Replatform or Refactor, governance is distributed across different business units. Because each tribe owns its own application modernization development, they will have specific systems they own and must modernize. Regarding skills, when performing Replatform or Refactor, knowledge of modernization tools is required. If you are doing a Replatform, you need to know how to use those Replatform tools. The same applies to Refactor tools. However, when doing a Reimagine, you need to know how those legacy applications functioned and where you want to take them; after that, you are just following the standard software development lifecycle, so no specialized skills regarding tools are necessary.
Investment in the Reimagine strategy is also typically higher. It takes longer to reach the final state, but at least you gain value more frequently. By the time you reach the other side, you have already arrived at the technology sector you aimed for from the beginning.
The Crisis of Knowledge in Reimagine: SME Shortages and the Limits of Manual Processes
The main challenge customers face when implementing Reimagine is related to knowledge. When performing reverse engineering, SMEs have to spend a lot of time analyzing legacy code and existing documentation. There is a high likelihood of gaps in the documentation, and it is often the case that the people who originally developed the application are no longer there, no longer employed, or have retired. This is one of the challenges.
Another challenge lies in forward engineering. Analysts reviewing business rules extracted through manual reverse engineering must coordinate with developers building the modern version of the application to ensure that the modern version actually aligns with the specifications based on the legacy application. This is also a challenge; in summary, it is basically a crisis of knowledge. There is a shortage of SMEs, and manual processes take a long time and do not scale.
These were the problems customers came to us for help with. We have traditionally focused primarily on Refactor and Replatform, but we decided to start investing in helping customers move down the Reimagine path as well. To assist these customers, we proposed a combination of different AWS services.
AWS Transform and Kiro Solutions: Leveraging Agentic Tools for Reverse and Forward Engineering
One is AWS Transform to tackle the reverse engineering portion, and the second is Kiro. For those unfamiliar with AWS Transform, this is the first agentic transformation tool for mainframe workloads. While it works for other enterprise workloads as well, this session focuses on mainframe capabilities. It helps extract knowledge from legacy applications. For example, if there is no documentation explaining how an application works, running it through AWS Transform allows you to obtain technical documentation describing dependency analysis, execution flow, inputs/outputs, error handling, and all integrations. It is also possible to extract business rules from it. You can get dependency maps, perform decomposition, and much more. This saves SMEs a significant amount of time that would otherwise be spent on reverse engineering.
Kiro is an agentic IDE tool. It operates based on spec-driven development, so when you write specs in Kiro, it generates code based on them. You can take all the output from AWS Transform, load them into Kiro, and then guide Kiro to build the modern version of the application.
How It Works: Detailed Workflow
To go into more detail on how it works, we first load these mainframe artifacts into an S3 bucket and connect them to AWS Transform. AWS Transform analyzes the codebase. It checks all dependency mappings and classifies all components—what is COBOL, what is REXX, what is a Copybook, and so on. It also performs cyclomatic complexity calculations, so you know which components are difficult to modernize and which are not.
Analyzing missing files can have a significant impact on modernization projects. After all, you don't know what you don't know, right? So, if you don't load those files into AWS Transform, AWS Transform cannot guess what that logic was or what logic was contained in those components. Also, as of this Monday, we can now perform data lineage and data dictionary analysis. This allows you to know which components use which data sources and how they use them—that is, whether they are creating, editing, deleting, or simply updating those data sources. And the data dictionary allows you to explain what those data structures contain. Since most of the fields you have in mainframe applications are limited to 8 characters, you really don't know what they mean, do you?
Here, Transform helps you guess what those fields actually mean in real life. Next, we move on to documentation. In the documentation section, we extract technical flows, all the inputs and outputs I mentioned, and integrations as well. Business rule extraction is also possible. In other words, at the component level, we extract all business rules implemented in COBOL code into English. Then, we take the business logic of all these components, group them by entry point, and provide a perspective from the application level. At the application level, you can check all CICS transactions that are entry points, all jobs that are entry points, and also get a summary at the application level.
We can also perform decomposition, so you can define domain names yourself and provide some seeds that serve as examples of components within those domains. Then, Transform performs dependency tree analysis to find other components that are part of the same domain, and also performs semantic similarity analysis. And finally, it helps you plan your migration. This is from a reimagining perspective, right? There are other features for other patterns, but in the planning step, we take all the domains and arrange them in the order of the ideal migration waves. First, we start with downstream dependencies. For example, suppose you have common components that are part of one domain. By migrating those first, you won't need them anymore because they are required to coordinate with other domains that depend on them. If you migrate downstream dependencies first, you won't have to keep going back and forth between the mainframe and AWS, right?
Putting It Together: Loading Artifacts into Kiro
Next, we take all these outputs obtained from AWS Transform—mainly business extractions, documentation, and the original source code, data lineage, and even SMF activity—and load them into Kiro. The first thing we do is teach Kiro how to use these artifacts. In other words, we instruct Kiro to perform requirements creation using business rules. Kiro creates user stories and acceptance criteria based on the business rules. We instruct Kiro to understand execution flows using the documentation, and also instruct it to use source code when technical implementation details are needed. For example, suppose there is a tax calculation part in the code. If that formula is not in the rules, you can get it from the COBOL code, right? The reason we do it in this order is so that Kiro doesn't generate a modern application that perfectly mimics the behavior of COBOL.
Then, what Kiro does is start generating these packs. In other words, it creates a requirements document containing all user stories and acceptance criteria and hands it to you, asking, "Are you okay with these requirements I just created?" You can change them, or you can have Kiro continue. Kiro generates the design for you. The design includes technical architecture, application layer, data persistence layer, etc. If that is also fine, it creates tasks, and for each task, it generates code, Infrastructure as Code, and even data transformations. In other words, it can convert the data model to the cloud and generate the application code that uses that data.
You can also use Kiro to run the tests that were created. In other words, you can run unit tests and integration tests on the endpoints you just modernized. You can also run tests to verify that business rules are correctly implemented in the modern version. Furthermore, integration is also possible. I gave the example of Application A calling Application B, but if Application B has already been modernized and you are migrating Application A now, you can provide the API and Swagger documentation for Application B to Kiro, and instruct it to use that API documentation and that API contract to call Application B, which is already on AWS, instead of calling the legacy Application B on the mainframe. Could you please hold your questions until the end? I am on stage.
ADP's Tax Engine Reimagine: Modernizing a System that Processes 77 Million Employee Statements Annually
There are many metrics I can share regarding the efficiency improvements of this approach, but the best people to talk about that are our customers. So, to talk about ADP's story and results, I would like to welcome Anu.
Yes, I am Anuradha Verma, VP of Product Development at ADP. I mainly manage the Compliance Solutions division and am focused on tax. Today, I will talk about our journey in how we view tax and how we are trying to modernize one of the most complex and critical systems we have that handles regulatory and compliance needs. Before I begin, a brief introduction about ADP. We are the #1 HCM provider in 140 countries. We have approximately 1.1 million clients in over 140 countries, with clients of all sizes, from small family-owned shops to large Fortune 500 companies. In fact, we process one in every six payrolls in the United States.
At this scale, our clients entrust us with scalability, reliability, security, and most importantly, trusted expertise. With that in mind, tax becomes very, very important. Because it involves compliance, keeping our clients safe, and avoiding penalties and problems. From that perspective, we are focused on reviewing the tax engine we have on the ADP mainframe and considering how we can not just modernize it, but reimagine it. This is one of the systems that has been around for several years, and as the system grows, it becomes increasingly complex. There are many processes and rules built into that system.
To talk about the complexity and scale of this system, there are over 77 million employee statements annually. We remit 1.6 trillion dollars to various agencies on behalf of our clients. We support 8,000 tax jurisdictions. There are over 10,000 forms and their variations corresponding to various agencies. And to support all of this, over 12 million jobs are executed on the mainframe.
The biggest challenge we face in our compliance system is that we are dependent on changes that agencies bring in over very short periods. Therefore, we need to respond in a timely manner and maintain compliance. By doing so, our clients can also maintain compliance. With that in mind, we started our tax modernization journey a few years ago. What we realized was that simply modernizing from one tax stack or module to another would not be the best investment or strategy. So we rethought our strategy and are now on a path to reimagining our tax ecosystem. We are not just migrating systems from A to B. We are reimagining every process. We are reimagining what should be taken out of code and turned into rules, or what should be externalized entirely. By doing so, we can respond to changes more rapidly.
When we started this journey, our initial approach was to build a new system and start migrating clients to the new system. However, we quickly realized that it was a long journey, that we would never be able to reach parity quickly for all features, and that we would sometimes have to revert clients. So we quickly changed our approach, and what we are doing now is in-place modernization. We take a large system, break it down into smaller components, and consider how to modernize those smaller components, and while modernizing, how to reimagine them at the same time.
I talked about ADP's scale and its ecosystem, and we are facing several challenges, and I will also talk about how we are mitigating or trying to solve them. One challenge is the increase in complexity. These are complex, fragmented, and rapidly evolving tax ecosystems. When changes are needed, we must change them very quickly. And because things that have been done over many years are embedded, as clients get larger and more clients are onboarded, it becomes difficult to meet these complexity needs at times.
The second challenge we have is low tolerance for errors. This is natural, as we are a compliance solution. Tax is about compliance and accuracy. To meet the needs of increasing clients and the needs of agencies to maintain compliance and provide well-scrutinized, clean data, we must ensure we are accurate when we modernize or restructure.
Another is adaptive compliance. The demand for systems that adapt instantly, learn continuously, and validate gently is very important. Because you cannot run with static rules in new modern systems. They must be adaptive, and therefore, building a system that can handle such complex needs is very important to us.
And of course, global scalability is always on our minds. When we run declaration processing at year-end or quarter-end, we process millions of declarations, mail them or file them electronically, and we only have two weeks to receive confirmation from all the agencies we support. Therefore, the time to respond is very limited, and we must scale up and process so that our employees and clients have enough time to validate, provide approval, and fix or correct if there are any issues.
So, this is our approach. As I mentioned, we are splitting the large legacy system into multiple modules, taking one module at a time, and considering the reconstruction of that module. Of course, there are some challenges with that. Because, as Paulo said, if System A is on-premise and System B is reconstructed or modernized, we must maintain connectivity because there is data exchange. However, so far, as long as we ensure it is fully tested and verified, it has proven to be scaling and working well for us.
Another benefit we are seeing is that all clients will be able to utilize the same module at the same time. Instead of building the entire system and then migrating clients, clients are getting early access to the features we are creating. So, it is really helping us in this regard. Another approach we took was not to proceed form by form or state by state, but by taking declaration types and looking at all states with similar kinds of declarations, so that we can support all declaration types for all clients simultaneously.
For example, when doing SUI declarations, it is better to do it for all clients in all states at the same time. By doing so, we can test, verify, and fix the minimal differences between states simultaneously. And overall, the biggest help we have received is understanding our ecosystem through AWS Transform. While reimagining the system, leveraging this tool to use agents, extract business rules and processes, and understand interdependencies is very critical to us. By doing so, we can focus on reimagining how we want to do tax again, rather than thinking about what the existing rule base is.
And this has proven to be very useful for us, and while the system helps us extract these processes and rules, our SMEs are now able to focus on other tasks. So, we entered into a collaboration model with AWS, and it has been proving to be very helpful for us. We are not small, but we took 70,000 lines of code—this is for one declaration type—and leveraged AWS's help, and AWS experts helped us build agents to extract those rules and test with those rules.
So what we did was take these lines of code and 214 legacy programs, and not only did AWS Transform help us extract business rules, generate documentation, and write test cases, but it also helped us reimagine how these rules should be extracted and expressed in the new codebase. AWS Transform helps us with an agentic system. It ingests our code, evaluates the JCL COBOL program database, and helps us convert the code into business logic and business rules.
It helps us with data analysis, and with the help of Kiro, code is generated, and we can test and analyze that code, and modernize the system accordingly. So, we are not just doing a conversion from A to B. We are rethinking whether it makes sense in this new world. And do we really need to write that much code? Can't we make it a configurable system that even the business department can help set up?
This is the reconstructed technology architecture. We are modularizing the system and trying to separate the front-end, back-end, and persistence layers. We are leveraging many AWS services, and we are building in AWS multi-region. We are leveraging EKS Fargate, OpenSearch, MKS, and Postgres, S3, and some Redshift for data persistence. This allows for scaling to meet various needs, and as the biggest benefit, since tax is a seasonal business, we can scale up very rapidly during declaration periods and then scale down, realizing significant cost savings compared to our previous monolithic infrastructure.
There is still a long road ahead, but these are the initial results. AWS Transform helped us extract 8,000 business rules from exactly 214 programs. And what we have verified is that we have achieved a 2x efficiency improvement. Another big factor was that to extract these rules, we needed SMEs who understood the domain and understood the code, but AWS Transform provides these very quickly. Of course, we need a bit of human-in-the-loop to understand if it's accurate, but because we can test the before and after of the system through these tools, that is also simplified, and we can deploy with confidence that this works for us.
As other benefits, because we are proceeding module by module, we can extract these rapidly, integrate, develop the code, move it to production, and see results very quickly instead of waiting for months or years. This is really helping us. AWS Transform provides flexibility, supports the business rule extraction journey, and scales up to meet the needs of our client base of 1.1 million clients. And we have to respond within two weeks. It is helping us scale up and down. It helps us meet compliance needs and adapt and change rapidly when new compliance rules are added, and overall, it is bringing very significant productivity improvements.
So, we set some goals for ourselves to use Transform and move this journey forward. We have set goals to complete declaration modernization by 2028, to support all form declarations for all client types in all markets, to simplify compliance changes by 80%, and to reduce manual exception handling by 50%. What we are working on next is leveraging Transform to modernize our tax engine, making it faster and more accurate in declarations, and making the engine more scalable and robust. Instead of just checking for errors, we will assist clients by providing insights and anomalies, and even if a declaration looks correct, we will detect it, determine if the changes are okay, if the declaration is accurate, and proactively identify problems. Now, I will pass it over to Douglas. Thank you.
Itaú Unibanco's Challenge: Modernizing Payment Functionality with a Goal of 100% Cloud by 2028
Hello everyone. My name is Douglas, and I am the Mainframe Platform Executive at Itaú Unibanco. My mission is very simple: to migrate thousands and thousands of MIPS to the cloud in a smart way and in a short period. I am happy to share with you how Itaú Unibanco is reconstructing its core systems using AWS Transform and Kiro. Before I begin, I would like to introduce Itaú Unibanco and talk a little about why we have been transforming our organization.
Itaú Unibanco is the largest bank in Latin America, operating in 18 countries with over 100 years of history. We have a market capitalization of $74.7 billion, a brand value of $8.6 billion, and we are a full-service bank providing products and services to 70 million customers. And why did we start this digital transformation?
Digital transformation has fundamentally changed the way we operate. Over the past few years, every new technology has changed all customer habits. Previously, customers would go to branches to do banking. Now, customers recognize relationships through digital channels and various touchpoints. It is not just about taking out loans or investing money. It is about relationships and loved experiences in digital channels, anytime and anywhere.
And to remain relevant in this scenario, Itaú Unibanco started its digital transformation based on six strategic pillars: product mindset and design to build products that customers love, agile methodology to solve actual customer problems, AI to increase efficiency and hyper-personalization for customers, and the critical part—technology. The right technology that is evolving, scalable, and resilient. And to have the right technology to evolve, we needed to embrace a modernization journey focused on value delivery to customers and the bank's competitiveness.
And what was the main goal? First, reduction of dependencies between platforms and systems. Second, improvement in team agility, autonomy, and reusable solutions. Third, improvement in time-to-market. We need to be faster for the business and for our customers. And fourth, to be accompanied by analytics-by-design.
And we have been executing this journey since 2018. We started by running small workloads in a private cloud. In 2020, we started a long-term partnership with AWS to migrate workloads to the public cloud. In 2023, our commitment was to run 60% of our business services in the cloud. Currently, we have reached about 70%, and at the previous re:Invent, our CIO, Ricardo Guja, announced a new commitment: 100% in the cloud by 2028. Yes, you heard that right. 100% cloud by 2028.
And what are the numbers that support this achievement? We have done a great job so far. We increased delivery to production by 2,000%, reduced the cost per transaction by 45%, and reduced incidents by 99%. In summary, we have become faster, cheaper, and are able to provide higher availability to our customers. And these numbers supported making this decision.
So why are we here? To reach 100% in the cloud by 2028, we have over 50 years of legacy mainframe programs, and the period to completely modernize our platform is four years, now two years. And what have we learned based on legacy modernization? In fact, first of all, when we start this modernization, we do not know what we do not know. To cover all dependencies and understand all business rules, we invested 50% of the engineering team's time in understanding what this code does.
In the testing process, we invested 30% of our time testing applications, but the coverage was very small. Sometimes, coverage during the testing process was as low as 20%. And decomposing these monoliths into microservices is not easy. And to create a new way to achieve our commitments and speed up the modernization process, we started a direct feedback loop with the AWS Transform team, helping evolve the product and support us in achieving our commitments.
We selected a small subset of payment functions to test AWS Transform and AWS Q. This workload has approximately 70 online programs, 107 batch jobs, and about 600,000 lines of code.
And the goal? To move to pre-production by re:Invent 2025. And yes, we achieved it. We are running a pilot in production, and we plan to roll out this functionality to all customers in January 2026. That is probably what Vito said.
There are two big steps in this process: first, reverse engineering when using AWS Transform, and second, forward engineering when using Kiro. What are the challenges in the reverse engineering process? All rules are scattered across platforms or different programs. In this scenario, we discovered many misaligned rules that should belong to different domains. And only one person knows what this codebase does. Documentation? No, there is absolutely no documentation.
And AWS Transform supported us in two scenarios. First, cross-platform extraction of these rules using business context. This is not technical documentation or line-by-line documentation; it extracts all business rules in business context. This is a game changer for the forward engineering process. And we can create a validation framework to ensure that all business-critical logic is available in the forward engineering process. What is the impact of these results? What previously took weeks, months, or quarters can now be completed in hours. And we need to move forward. We need to advance.
This is the forward engineering process. Using traditional approaches, there are two big problems: first, the quality of generated code, and second, how to test this generated code. And by using Kiro, we were able to see different results in this process. Based on the rules extracted with AWS Transform, we can generate all code following all requirements for architecture and code quality, and generate all test cases.
And the impact? We created automated tests for every process. We generated high-quality code integrated with all APIs, and improved test coverage from 20% to 80% in this pilot. We are now more confident about the coverage and code quality during this process. And what are the truly important numbers in this process?
Looking at the end-to-end process, we achieved a 96% time reduction in reverse engineering. In the forward engineering process, there is an 82% reduction with Kiro. And the testing process? The numbers were amazing. Test coverage improved 4x, and the efficiency of test creation is 97%. Looking end-to-end, it is 75% faster than traditional approaches. Yes, compared to manual modernization, it is 75% faster.
From a cost perspective, although it is not our top priority, reducing costs is very important for us. We reduced 1,070 MIPS in this pilot. And what are the key learnings and success factors in this process?
First, start small. Test, fail, and learn before scaling. Second, think about testing. Using reusable patterns here is very important to scale this kind of solution across the organization. And in my opinion, the most important success factor is that executive commitment is non-negotiable.
In this kind of initiative, when using Gen AI to test new products, you need CIO-level sponsorship. And based on these numbers, what are the next steps for Itaú? First, expand the solution to the entire business community. Second, standardize the Gen AI pilot for all similar codebases to speed up the process. And of course, continue contributing to the AWS team to evolve the product and solve new problems found in the modernization journey. And now, we are more confident that we can reach 100% cloud by 2028.
And our modernization journey is continuous. And I hope this case serves as inspiration for you to start or continue your modernization process. And I hope you stay here next year to share new results and new achievements from Itaú. Thank you for the partnership. Thank you all for listening.
New Features in AWS Transform: Activity Analysis, Data Lineage, and Enhanced Test Automation
The numbers seen from these customer cases are very exciting. And by working very closely with Itaú, ADP, and other customers, we built new features within AWS Transform and announced them this Monday. We launched activity analysis, so now we can ingest SMF records 30 and 110—that is, CICS and batch—and provide metrics regarding execution and execution time. This can help you make decisions regarding the target architecture on AWS.
We also launched data analysis features. This includes data lineage, showing which components are accessing which data sources and how they are accessing them, and a data dictionary that explains fields in legacy copybooks, allowing you to understand them better during modernization. We also launched an enhanced chat experience. This means that in the chat window of the AWS Transform web app, you can ask questions about the output obtained from each Transform agent. For example, if you are doing dependency analysis, you can ask the chat, 'Which job comes after Job A in the scheduling chain?' And Transform can already load scheduling information from Control-M, CA-7, and others.
In terms of automation, we also launched several features. There are five here, but many more features are included within them. We have test environments: when performing a migration, we provide a tool that compares the output of test execution on the AWS side with the output on the mainframe side, allowing you to find discrepancies and fix them so they behave the same way.
We also launched test plan generation. This looks at the application's execution flow and business logic and describes in English what test cases should be to have positive and negative coverage for all rules. We also launched test data collection scripts. When creating these test cases, we also provide scripts that can run on the mainframe. This allows you to extract data before and after executing the application, and you can reproduce this test in the modernized version to see if the results are the same. This test data can be huge, and since there may be hundreds of datasets to load or tables to dump, this is very helpful.
We also launched test automation scripts. If you have data and a test plan, you can also automate the execution of these tests while performing comparisons at the end. And if you are performing refactoring, we have a feature called Reforge. This improves the readability of Java code converted from COBOL, and this feature also generates unit tests to ensure you do not cause regressions when performing optimizations.
Getting Started with Your Modernization Journey: Available Resources and Engagement
We also launched six new regions. Previously, we only had North Virginia and Frankfurt regions, but this time we launched Mumbai, Seoul, Sydney, Tokyo, Canada Central, and London. For those of you who were excited by the numbers from Itaú and ADP and wanted to start this journey, we have prepared several resources. Well, wait a moment. We have a website regarding AWS Transform where you can get more detailed information. You can also schedule an experience-based acceleration engagement with us. This is an engagement at no cost to the customer, where we help you take something to pre-production in a short period, in just a few days. We also have detailed information regarding the AWS Mainframe Modernization practice. We look forward to joining you on your mainframe modernization journey. Thank you very much.
- This article was automatically created using Amazon Bedrock while maintaining information from the original video as much as possible.
Discussion