🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - AI driven application modernization at scale (MAM103)
In this video, Ravesh from Pega Systems explains how AI is driving application modernization, focusing on the 85% of workloads that haven't moved to the cloud due to legacy system complexity. Pega differentiates itself by focusing on rewriting applications rather than just analysis, offering three transformation dimensions: moving to cloud-native architectures, transitioning from programming languages to no-code platforms, and shifting from analog to agentic processes. Matt Healy demonstrates Blueprint, Pega's tool that uses AI agents to analyze legacy assets and generate cloud-native applications in under a day. The demo shows transforming a grants management system and integrating with AWS Transform for mainframe modernization, completing the process in less than two weeks.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
The Challenge of Legacy Application Modernization and Pega's AI-Driven Approach
Good afternoon, everyone. My name is Ravesh, and I'm with Pega Systems. Over the next 10 to 15 minutes, we're going to take you through a journey of how AI is driving application modernization. We'll start with legacy applications and the challenges they present.
If you've been in the cloud modernization business for a while, you'll know that 85% of workloads have yet to move to the cloud. This is a statistic used by AWS. When you think about why 85% of workloads haven't moved to the cloud, it's because you have applications that were written 30, 40, or 50 years ago. These are complex applications where either the original developers have retired or there are over a million lines of code. You don't understand the dependencies between the application logic and the data.
Many of these applications are mission critical and require a very high level of availability, so there's too much risk involved in moving them. When we think about legacy transformation or legacy modernization, that addressable opportunity is that 85% of workloads. Maybe it's not exactly 85%, but it's at least the top 10% within that 85% that are ready for disruption through AI-driven modernization and have not yet moved to the cloud. If you talk to clients, this is not something they've just started thinking about. Clients have tried to modernize mainframe applications, COBOL applications, and AS/400 applications. In the past, these modernization efforts have all been very human-centric and labor-driven, requiring years or months of work to understand, analyze, and reverse engineer the code.
You need to understand the data dependencies, the processes, and the data itself. There's a lot of risk involved in this work. Sometimes there are regulatory requirements embedded in these applications that haven't been fully understood. So what gives us confidence now that we're ready to tackle these 85% of applications that haven't moved to the cloud? What gives us confidence in this world where everything is AI?
If you think about what AI is doing today and how AI is being applied inside IT, this is work that was done by McKinsey last year. They presented this at re:Invent last year. If you generally understand the SDLC, the overall IT lifecycle cycle, there's a lot of compression that AI is driving. According to McKinsey, they estimate about 50% compression in the overall IT lifecycle. If you notice where the biggest compression is happening, it's in what's called design and discovery. A lot of the AI-driven compression is happening within design and discovery because we can now use AI to help us understand requirements and look at applications.
We can reverse analyze applications, develop forward engineering plans, develop forward engineering test cases, and understand and help redefine business processes from analog processes to more digitally native business processes. We can also discover functionality. There's a lot of compression happening in this area, which is where AI is being applied. Some of you may have looked at AWS Transform or other tools. There's a lot of tooling happening in the analysis space. You might ask, if AWS is doing AWS Transform, what is the role of Pega? What is Pega trying to do here?
One of the things we've done as a broader industry is focus almost exclusively on the analyze problem. Almost everybody is focused on analyzing legacy applications, whether it's a COBOL application, a Lotus Notes application, a .NET application, or a Java application. Most of the tools in the market today are focused on analysis. Pega is the only firm that's actually focused on the rewrite problem. If you look at the overall value chain from a client perspective, this is where Pega differentiates itself.
So if you're a large client, an insurance client, a banking client, a healthcare client, and you want to modernize these applications, you've got to focus on analyze, rewrite, integrate, and deploy. Generally, that's the life cycle. Where we fit in, where Pega fits in, is we're focused on the rewrite. If you can analyze it, we can rewrite the application for you.
Our philosophy is anchored around 33 key dimensions of transformation. First, we are in the business of retiring legacy applications. This means we're going to move from old architectures to new cloud-native architectures. That's the first degree of transformation. The second degree of transformation is moving from programming languages to no-code platforms. Why is that important? If you think about how business changes today, there are continuous new business requirements, regulatory changes, process changes, and supply chain changes. All of these changes require business process change.
You can rewrite an application in a new programming language, but six months from now that will become legacy because you would already start to accumulate technical debt. It's just a cycle. That is why we firmly believe that part of our transformation value proposition is moving from application languages to no-code platforms. Because then any time there is a business process change or a regulatory change, it's a configuration change. It's not about requirements, design, and analysis. It's a configuration change. You can simulate the change using AI and you can change your workflow. That's the second degree of transformation.
The third degree of transformation that is also happening is moving from analog processes. A lot of times you have systems that are talking to other systems, orchestrating data and orchestrating the flow of work between your ERP system, your fulfillment system, and your order management system. You've got a lot of orchestration that happens right now. Think about in the modern agentic world, do you really need that, or can agents start to drive the orchestration between different systems? You're starting to move from analog processes where a lot of these point-to-point connections were made through all sorts of integration technologies to where now you're using AI to drive agentic automation across these workflows.
What we have done at Pega is we have built the tooling to facilitate the modernization of these legacy applications. We call that technology Blueprint. If you just look right behind you, our booth is right down there, right past where the AWS section ends. You can actually go see our technology and experience it in real time. But what we're going to do in the next ten minutes is actually show you the technology in action. If there is one thing you take away from this talk, it is ABC: Anything to Blueprint to Cloud.
We're going to show you two examples of two apps. One is a very complex COBOL application and one is more traditional where you're doing requirements, design, and discovery, and you're using those documents, applying them to AI, and AI is going to build the application for you. So just remember: Anything to Blueprint to Cloud. I'm going to give it to Matt. He's going to walk you through two demonstrations. One first application using requirements, and then the second one using AWS Transform on a COBOL application.
Blueprint in Action: Transforming Requirements and Legacy Systems into Cloud-Native Applications
All right, thank you, Ravesh. What's up everybody? Matt Healy. I lead Go to Market for the Pega platform. Just a couple of minutes ago I asked our team if I had any swag I could throw out, and they handed me a bunch of pins. I was like, I can't throw pins at these nice looking people, I'd end up on the news. So you're welcome for that. But yeah, to Ravesh's point, let's go through a live demo of what this transformation process can actually look like. Bear with me, and if the network goes down, we're all heading that way and talking to the folks who are responding for this.
So if you're not familiar with Pega, it's a workflow automation and AI agent platform largely leveraged by large enterprises and large government agencies to automate their back office processes, their customer service processes, and their customer engagement, think marketing. Obviously at a large enterprise who's been in business for fifty, one hundred, one hundred fifty years, there's a lot of legacy.
We kept getting requests asking what we could do to help analyze the information they have available and use that to transform and reimagine those processes into new cloud-native applications on our platform, which allow them to drive the automation, AI agents, and experiences they're looking to deliver. That's where Blueprint comes in. Blueprint is available to anyone. You can even try this out after the session at Pega.com/blueprint. It has a set of AI agents built into it that allow enterprises to bring different types of information from their existing processes and legacy estates, and analyze that to extract the business processes and data models needed to bring it to the cloud and start to reimagine it.
Let's say, for example, I was working at a government agency that hands out grants. We take in applications for grants and then we disperse funds after they go through an approval and validation cycle. I might have a legacy system that looks something like this, maybe built on .NET, maybe Lotus Notes, maybe a homegrown application, or maybe an off-the-shelf application. Whatever it may be, I want to get off of it. I might have that video and I might have some more context available in the form of documentation. Here I have a requirements document describing the different aspects of that process, what types of data, what types of decisions we need to make throughout the process. I can take those assets directly without having to go through any analysis by hand and import them into Blueprint.
What Blueprint is going to do is send the different assets out to each one of those AI agents. For the video processing, it's going to listen to the transcript. If there's a walkthrough, it's also going to look at the screens and extract the information. Essentially, what Blueprint does is analyze those assets, extract the business processes, extract the data models, and extract the people involved in the process. It's going to take that information and build a template that I can then begin to adapt and turn into a future-state application on the cloud. From there, I can invite all of my business and IT stakeholders. I can have many different people engaging on this palette and almost treat this like a whiteboard purpose-built for business process transformation. We can all get in here and say, alright, this is where we're coming from. Now let's make this look like where we want to be in the future. Let's reimagine our processes.
We can dive into the steps of the process and get to some really high-level fidelity of the requirements of our future-state application. We can do that for all of our workflows. We can model out our data and our integrations, so if we need to connect to any back-end systems, we can model that out in here as well. We can even go as far as importing application integration assets or data assets that we have. If I have a legacy database I want to migrate to the cloud, I can take SQL and import it in here. It will replicate the data structures for the cloud. Or if I have third-party integrations which I need to replicate with my new system, I could take a YAML file, an OpenAPI specification, and integrate that in here and have that replicated as well. I can then move on to the people involved with the process. Who do I need to be thinking about in terms of serving experiences and different channels, and dive into each one of their requirements in terms of what they need to be able to do, what security we need to have available for them, and what they need to or should be able to see, access, and edit along their journey. At the end of this Blueprint process, this is something teams would spend half a day or a day working on, getting their business subject matter experts and their IT teams collaborating in this environment. At the end of it,
I have a comprehensive requirements document. This was assisted by AI, and one of the things our AI agents did was research best practices for the use case based on what I'm looking to automate. I can take this blueprint—the metadata from this application—and deploy it to the cloud, whether on AWS, GCP, or my self-managed environment, and generate a cloud native application in about five minutes. So I'm able to go from blueprint to the cloud, something I can touch, feel, and execute and test in less than a day.
Along the way, I can even preview before I do any development work, before I even touch the cloud. I can preview what my application is going to look like and how my workflows are going to come to life for the various sets of users I want to make it available to. This is what Pega's out-of-the-box back office portal looks like. I can see how a claims adjudicator's day would look, what their experience would be like, and what forms they would have to complete. I can see what dashboards they'd be able to view. I can even look at a mobile application. Maybe I have a Salesforce application that I want to plug into, and I can take a preview of that here as well.
One of the unique things about Pega's architecture that is core to our philosophy is that business processes and workflows should be abstracted from channels. What you're seeing here is the same claims adjudication workflow plugged into multiple sets of channels for multiple users. This allows large enterprises to serve their customers directly, their back office teams, and their customer service representatives, giving them all the same capability to create work and do work without having to encode the business logic in each and every channel they want to deliver. This unlocks increased agility and decreased total cost of ownership in these multi-channel environments.
I can even see what it would look like if I wanted to embed that workflow directly to a customer either through a form-based interaction or through conversational self-service. This is where we get into AI agents, which are everywhere. We couldn't get off stage without showing AI agents, so I'm going to do that now.
One of the things that's natural with our approach where workflows are separated from channels is extending workflows to conversational self-service. You want to give people access to get work done through natural language. We heard Matt Garman this morning talk about the need for predictability in our AI agents as well. That's essentially how we're approaching this. This is what we call predictable AI agents. You'll notice I did no prompting. I didn't configure an AI agent anywhere. What happens in Pega is when you build an application, we automatically wrap all of your business processes with a conversational AI agent, and all that AI agent can do is act as a concierge to your pre-structured processes.
Let me give you an example. If I came in here and said, "I broke my leg and need to file a claim," the agent will look through all of the workflows I defined and hopefully find the right one, and it's going to begin to walk me through that same process which I had up on the business process palette page. It's going to walk me through collecting that data. I can say this was today, five hundred dollars, four hundred dollars, diagnosis negative. I can't type, but you get the idea. The whole time, any interaction I'm having with this AI agent is tracked as a case, as an instance of a workflow, the same as if I submitted it through the website or the same as if a customer service representative filled it out on my behalf. This gives me that control and confidence in deploying AI agents at scale.
Mainframe Modernization with AWS Transform Integration
Let me show one more thing. I'm running out of time, so I did want to show one more thing. Obviously, we're talking a lot here at re:Invent about getting off the mainframe. One of the other things we've done is integrated a blueprint with AWS Transform as an AI agent. I can have a mainframe application go through the Transform process to build that deep understanding of what's in that, which you see here, and then we've built an AI agent which actually runs in Transform and translates that analysis from that mainframe system into information which can actually go and create that blueprint that we were just looking at. I can kick that process off automatically and then begin to go from mainframe to something my business and IT teams can collaborate on and begin to reimagine and rethink to the cloud and deploy that in just a couple of seconds here. We would love if you swung over to the booth. It's about forty-five steps that way. Come see a demo and talk a little bit more in depth. Booth 366, so don't miss it. Thank you for your time. That mainframe application, just so that it is running Transform and building the cloud native application based on the extraction, is less than two weeks using AI. Thank you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)