PegaWorld 2026: The End of Code-First Legacy Modernization: How AI Is Rewriting the Mainframe Playbook

All right. Hi everyone. Thank you for joining us this afternoon. Um, we honestly this is probably the most exciting topic here at PegaWorld, at least in my opinion. And I think you heard it this morning at the at the keynote that it's it goes beyond me. I know AWS is very excited about it. Of course we are at Accenture excited about it. And Pega is very excited about this Legacy transformation and what we're doing. But before we get started, let me start with introductions. My name is Cynthia Soto. I am part of the mainframe reinvention practice at Accenture, and I'm joined today for this panel with a couple of other mainframe modernization experts. Oops. It's still on the thing. Yeah. Let me. Sorry. Thankfully, I have somebody in the audience that's keeping me on point. I'm joined today with a with Joel Rosenberger and RUDI.

And gentlemen, why don't you introduce yourself? Well. I want to go first. I'll go first. Hello, everybody. My name is Rabobank. I lead the Legacy modernization at AWS. My responsibilities include working with the customers across the worldwide to help them solution their complex migrations to AWS and as well as work with all the partners, whether it is ISV partners or GSI SR partners to scale their business, especially within the context of legacy modernization. Thanks, Ralph. So I'm Joel Rosenberger, I'm the chief architect for mainframe modernization at Accenture. So I help our clients, um, through their journey of trying to figure out how to move those applications from one platform to the other, or even modernize in place if needed from there. And, you know, about 25, 30 years worth of mainframe experience and done just about everything you can imagine on a mainframe. Thank you.

Gentlemen. And before we get started, I do want to make a quick announcement. We're going to open up for questions towards the end of the presentation. But if you want to ask a question, we ask that you please come to the microphones, because otherwise the folks that are going to be watching the video will not be able to hear your questions. Okay. Thank you so much. Let's get started. So this morning, one of the things you probably heard when we talk about why now, why, why Legacy modernization cost is a big factor. A lot of clients come to us with that. And we have that here up on the slide on the left hand side. But I'm not going to talk about that one today because if our clients are coming to us saying, hey, we want to reduce cost, we want to drop our our TCO for the mainframe.

They're coming from a technical position usually. And when that's the driving force of a modernization, they typically fail. We see about a 20 to 30% success rate on those projects because those are the big, hulking multi-year programs and you don't get any benefits to the end. So where we're going to focus today is on the kind of the right hand side of the slide, um, the talent. Everybody knows it's been the elephant in the room for a long time. Um, the COBOL experts out here, it's, it's an aging workforce. And by 2030, about a third of them are going to retire. So it's going to reduce down the, the people who know the application, how to write the code, it's going to reduce that down. But more importantly than that, it's going to take away decades of institutional knowledge. Everything about these applications that these programmers and these support admins have in their heads.

It's walking out the door and there's no way to easily capture that. Or there wasn't. We'll talk about that on the next slide. The second thing I want to talk about is the business agility blocks that are on the mainframe. It's not the mainframe itself. The mainframe systems. You know, they're they're new, modern, great hardware. But these applications that were written 20, 30, 40, even 50 years ago are locking that logic in so tight. So to make any kind of change, you're looking at a six, nine, 12 month change window just to release a new product. Now, if we kind of flip that and we start looking at, um, looking at that business, those business outcomes versus that technology side on the left, that's where we're driving with modernization. Now, AI has has flipped the script, so to speak. It's changing the way, not only the way we're doing the modernization, but the way we're approaching it.

So if we approach it with reverse engineering, you heard a little bit about that this morning. Reverse engineering is where we scan the code and documentation and such, and we can recreate all the application documentation we can take what used to be a months and months long, very laborious process of going through the code and and tracking down all those business rules, doing interviews with SMEs to try to understand that code. We can do that now with AI. And not only does it take it doesn't take months. It doesn't even take weeks. We can do this in hours or days. So this is really changing how we approach modernization. It's not just about modernizing the code. We can now modernize the business and business processes because we can understand what the code is doing, and we can understand how the business wants to function, and we can bring those together with the combination of these tools that we're talking about today.

And I also want to highlight the code transformation. Um, you can take that code from, from the mainframe, take it through, get all that documentation, get the test cases and such, and then you can transform that code right through AWS transform. And you can let's use Pega as an example. You can rewrite that business process and completely reimagine it. So this is a business process. Re-imagination. It's not just rewriting a COBOL app and putting it in another language, because if you're just going to pick up the, the line by line application code and move it to a new language, you're just picking up that technical debt and moving it over here. You're not gaining anything from it. And finally, we're going to talk a lot today about that, that end to end agentic delivery, because it's not just about doing the documentation. It's not just about being able to create the test cases.

It's about orchestrating the entire modernization lifecycle throughout from one end to the other, from first ingesting the code to deploying that new application in the cloud, in the PegaCloud in this case, and how Accenture has built that end to end orchestration with AWS transform and Blueprint. And and to get started on that, I'm actually going to turn it over to Joel, and he's going to take us through a quick demo on how our tools are working together to help us drive these business outcome based modernizations. Joel. Thanks, Althia. Um, like Cynthia mentioned, one of the things that's interesting about AI and what's happened is how do we move it from an IT project into a business project. And that's one of the reasons we're really excited about Pega because, you know, instead of just creating another application that's in Java code or something like that, how can we create something that the business can use more process flow?

And from there, so like Cynthia mentioned, we've been working with, uh, AWS transform and Pega for over a year now. Um, and one of the things that we've been doing is, you know, AWS transform provides the shell to be able to make this transformation happen. And one of the things that was really interesting is as we move from that line to line conversion into more of a business rules specification type of transformation of the code Pega just made so much sense because at the end, if I'm extracting out the business rules and then being able to put that into a platform to be able to easily manipulate those processes identified, that makes so much sense. So what I want to show today is kind of that in action. And so I have a video, it's, it's a multi-step thing. So I have a video that I'll talk about as we're going through it.

So talk about this talk about green screen. Maybe that's why it took so long. It was an old green screen that had to come up from there. But so this is a typical application written in COBOL many, many years ago. Probably some of you recognize as a demo that we use all the time with this, which is card demo. But if you take a look at the log on screen, you can pass a log on screen. And very typical to a mainframe application is I have a nice menu, very user friendly. Which number do you want? Do we want to look at account view update. And you got to type in the number and go to the next next transaction and the next transaction. Again this is an input screen that you typically see on the mainframe. And you know, you look at it, you have all these fields that I tab around to do all the different things.

You have everything from Fico score to your Social Security number. Very user friendly. Maybe back in 1982, but not today. So as we start moving through this, um, let's talk about how do we actually tear that apart and transform it into this business rules and into what, what we need to do from there. So this is AWS transform. So one of the things we do is we bring all that code into AWS transform. Because one of the things when you look at it originally with AWS transform, it does a really great job of static code analysis and understanding that. But if you think about it, you know, right now it supports things like COBOL and from that, but there's a lot more things that are running on the mainframe. So one of the things that Accenture has done, you can see it down there at the bottom, the suggested workflows, and from that, and you'll see it on the next screen, which is, you know, some suggested or agents that we've created.

So we're able to create some agents that go in and get the runtime from the mainframe and be able to get those metrics about how many times that transactions run, what is the latency of that transaction. So, so as we go through this, one of the things we're doing through AWS transform is we're interacting with air to create a job, to be able to use all those agents, put those agents together. And one of the things that we're doing with AWS transform is Accenture brings our agents into AWS transform. So we're able to enhance AWS transform with the knowledge that Accenture has through a composability. So we're asking it to execute that job plan, to be able to go out and scan that code. Um, go and create that logic. So something that Andre said this morning about how we can go and extract that out.

And so this is the output that comes out of AWS transform and out of our enhanced, um, rules and agents. And so if you take a look at it again, the more detailed the business rules, the more detailed the specifications that you can get. Obviously the better application that you can provide. And from there. So as you start looking at this, we're able to go in and go into everything from the, you know, project flow. We're able to pull out the domains. We're able to go in to see where the blockers are, the hierarchical dependencies. So this is all just scanning the code and using AWS transform in the Accenture agents to do that. So being able to go through and pulling that information out and this information then is once we start doing all this, is how do we actually then provide that to Pega so we're able to go in and provide that into Pega through, through, through AWS transform also.

And you'll see here in a second where what we do is we take all that information and then start another job within AWS transform from there. And so, so this is actually using the Pega agent. So one of the things we did is we worked very closely with Pega to figure out what the right specifications needed to be from there. And so when we think about it, um, you know, the specifications then can derive, um, and have Pega create that blueprint for us. So, um, and that's what's happening right now is it's going through the AWS transform and the Pega agent to create that blueprint from there. And if you see there over on the left hand side is all the workflows and all the different, um, um, messages that are coming out from, from the Pega agent and it's already creating that blueprint. And you'll see it as we go into the next slide, the different workflows.

And as you can see here is right there is all the different workflows going through Pega. Um, and, and we can go into, and this is a full, uh. Pega. Blueprint. So we can go in and what was shown this morning about adding, deleting, changing, you can go into the data and explore that by going in and look at all the data that's happening in the mainframe. We're easily able then to go and create a pretty complete application. As a matter of fact, one of the things we were doing is we did this to a demo to a select number of clients, um, in New York not too long ago. And they, they came back and said, how did you get such a complete application? Because before, you know, it worked, but there were some gaps in the application. And it was amazing because a lot of the enhancements that we've done have actually been able to go and create that application in detail.

So so that was kind of the demo, kind of went through it quickly, but there with a few missteps and that. But so that was kind of a demo that we were able to show doing that. Now at the booth, we actually have the full demo with details. And so please stop by our booth. We are booth number 16 from there, and please stop by and we can walk through and answer any detailed questions on that. But let me hand it back to Cynthia, where she's going to ask some more questions to us. Yes, you guys are my victims now at my mercy. All right. Um, Raul, I'm going to start with you. So we've just seen how AI is, is changing the speed and economics of modernization. But from your perspective, what fundamentally broke that code first model and gave us a bigger focus on the business outcomes?

Yeah. I've been doing the mainframe modernization at AWS for close to four and a half years now. For the first three, three plus years, three and a half years, we always talked about what is your application to be in the target state. In that case, we always came up with two patterns Replatform and refactor Replatform. Maybe some of you probably know you keep the COBOL application as is, but instead of running on mainframe, you'll be running COBOL on AWS, which is Replatform. Refactor is you are taking the same application, but you're converting the COBOL to Java. It's like a line by line conversion. So it's always about what the code has to be in the target state. Are you keeping the COBOL or are you converting COBOL to Java as a line by line? But this is the first time the the discussion has completely changed because earlier we were unable to extract the business logic with with an efficiency and the speed at which we wanted to do so, we were unable to focus on actually complete business transformation.

It was mostly focused on the technology transformation. But now we can extract that business logic and mostly talk about the spec driven transformation, because now we have all the business spec ready to go. The spec is input for the future application rather than a code as an input. So that's completely what changed is how we start talking about the modernization going forward. Joel, do you have any thoughts on that? I would agree with Raul. I mean, one of the things that we've seen is in the past, it was really nice to be able to move it from one platform to the other to save cost or do something like that. But now, like you're saying is now it's, it's opening it up. I can actually get a AWS native application right from the beginning and something that would take, you know, eight, Nine years to do.

We can now do it in a couple years or even less to be able to do that. So that's really changing how people are thinking about this. So when you're talking to clients, are they still coming to you and asking for a technology driven approach, or are they interested in that business driven business first approach right up front? I think it's a little of both. And what I mean by that is I think the technology people, there's still a lot of RFPs and a lot of things that are happening from a technology point of view. But what happens is, is once we start discussing what can be done, they're like, oh, the light bulbs go off and it's like, oh, can I talk to my business teams about this? And so I think a lot of times it's still starting through the technology, but I think it quickly transitions into a business conversation about how we can unlock that business agility.

Interesting. Are you seeing the same role? Yeah. It depends on whom you are having a conversation. If you're talking to the mostly the tech teams who are running the infrastructure or who are running the applications. It always starts about. It's like a black box modernization, because my business wants to make sure the output application is exactly the same. The customer experience is exactly same. So then you are having a tech for tech modernization because business wants the same behavior, same UI, same business process. For example, if you have a batch process that's running for last two decades, you still run as a batch process. For example, you have a UI which has five different screens to complete an application. You will still have five screens. That's not true business modernization. So I always encourage our customers to bring in business early in the conversation. Then you talk about human centric design, how the new UI should look like, and what would be a process becomes from a batch to a real time process.

Then it becomes a business driven modern modernization, which is now possible, which was not possible earlier. So yeah. Excellent. Yep. I agree 100%. It quickly pivots to a business conversation about how we can move forward. Okay. So historically, anytime we have the mainframe modernization conversation, risk is a hot topic. You know, clients are very risk averse. These are there these applications are the bread and butter for their business. How are you seeing AI reduce the risk in these modernizations? Typically when we talk about the legacy modernization, especially when you have these applications built for decades, the two things that comes into mind. First of all, number one risk is I don't know what this application does because it's been developed over two decades. The people who developed over the years has gone, and whoever is there may not fully understand what is current state. So how do you make sure the extracted business logic, the business specifications 100% truly accurate.

That's number one risk. Once you identify that, then forward engineering and creating the next application is okay. But before going live, how do you prove that this application performs functionally equivalent? So that I can go back and prove to my auditors, regulators, and my security teams and all that this is functioning right? Those are the two biggest risks. I believe the first risk is 90% mitigated. The first risk is actually making sure extracting the business logic 100% prove that it actually mimics the current state of the application. So by working with AWS transform and as well as some of partners who have built their agents, we were able to reduce the 90% of that completely automated so that we can deliver those specs and then create a traceability and auditability so that that risk can be eliminated so that the, the, the technology teams can confidently go back to business and say, we can 100% sure that these specs are now truly reflect the legacy code.

That's number one. Number two, once you have the application, the modern application is ready. How do you functionally prove that this application is 100% equivalent? I think the the risk is still there. In that sense, we haven't 100% proven that the AI can completely solve the auditability of the testing capabilities yet. I think that is the area we are still investing and developing. And I strongly believe that over the next 6 to 9 months, we'll completely get there, where we'll be able to prove that the test cases can be confidently verify that these applications are functionally behaving the legacy code wise. I think we're not there yet, but that is the most risk proving that that functional equivalence. And I agree. I mean, I think when you think about risk is you're talking about the risk of the new platform and how I get there.

Let me step back a little bit. And something you mentioned earlier, Cynthia, about COBOL programmers retiring. And, you know, I think there's more risk than the actual application. I think there's an organizational risk that's happening. And and it's interesting because this isn't the first time that people have tried to modernize mainframes. It's they've been trying to do it for many, many times. And what's usually happened is usually been one of the top three priorities, but it never gets number one, because the risk of staying there is a lot less than the risk of doing something. I think with AI and what AWS transform what we're all doing with Pega, and from that, that is now inverted. The risk of staying still is now higher than the risk of doing something. And it's interesting because I was just meeting with a client in, in another country and they asked, well, if AI is moving so fast, why don't I just wait another year and do that?

And it's interesting because maybe you can, but your competition is not. And so competition is leveraging that AI to accelerate. Because in this particular case, it was a bank. And it was funny because the fintechs, the born in the cloud banks and financial institutions are moving at a very rapid pace. It's like, go ahead and wait a year. You're just going to be another four years behind because it's moving at that pace. So you need to start now because that risk has changed where the risk of staying where you're at because your COBOL programmers are retiring, your SMEs are retiring, your tech debt is increasing, and the costs are increasing too. So you mentioned the COBOL programmers. Do you see AI as replacing that dependency on the COBOL programmers or augmenting it to alleviate some of that risk? Let me phrase that a little wider.

Of programmers in general and from there I see AI really augmenting them because it's it's changing a lot in how people are programing and creating these applications. Like, can I train my programmers to use Pega? Can I train my programmers to understand the workflows and the data that connects to that from there? Now, something you said earlier, Rao, is what AI has done is made all those programmers that have retired over the years, because every time I go into a client, um, oh, the people who worked on that aren't there anymore. And from there, and it was interesting, you and I were talking about somebody on the stage said, oh, that's 20 year old code. That's young code when it comes to the mainframe code. It's not surprising if it's 40, 50, maybe even 60 years old that's sitting on the mainframe. And it hasn't changed from there.

So what AI has done is basically bring that automated semi to be able to help the programmers to understand what it is. You still need engineers, you still need some capability to put these things together. But the task that they do is changing dramatically in what they do to be more efficient and really deal with the business problem than why isn't my Java module doing what I want it to do? Do you have thoughts on that, Rob? Yeah. Two really. As part of the end to end modernization, the first important step is to understanding the current state. I don't think any COBOL programmers really want to sit down and go through million lines of code and document into as plain English work documents, right? I think instead of saying that, has it replaced versus it actually made their job easier because you really don't have to spend days and days going through these thousands of lines of COBOL code and document it and prove that you have done it right here.

AI is actually helping you do all that manual work into automated way. As an SME, you can go and verify that to prove that, yes, I can verify that these business rules and business specifications kind of conform to the code that was written, and then it is more of a human in the loop validation and verification, rather than sitting down and going through line by line and documenting it out. I think it made our lives better rather than actually replacing it. I think I agree. I completely agree. So in the demo that Joel played for us, it showcased AWS, Accenture, and Pega working together. Joel, when you think of that process, what does a successful modernization ecosystem look like? Well, that's a good point because I think a lot of people think about code transformation as the end all be all is, I'm going to convert it to something either business rules or whatever.

But if you think about that end to end process, there's a discovery piece. When you think about discovery, because most people don't know what's on the mainframe, they don't know, you know, does everybody know that 20% of your code on the mainframe most likely has never been used in the last three years? And why would I modernize that from there? So so I think when you think about the end to end, it's really about a discovery. Then let's do some transformation business rules extraction from there. Can't forget about the data. Mainframes have a lot of data. It's not unusual to have a petabyte of data that you have to figure out what to do with from there. And then, um, then the biggest piece is testing. I think you mentioned it earlier, Cynthia, about how AI is helping us with testing to be able to generate things like test cases, test data from there, because that's one of the biggest gaps we see with mainframe modernization is no one has test cases, and so we have to create those to be able to generate that from there.

And then the last piece, which is very important, is that production cut over. What's left on the mainframe are the most critical systems. And so I haven't met a client yet that said, let me just convert the code and throw it in production and let's go. They want to test it. They want to do a lot of times in production parallel, they want to do a lot of things like that before they cut over. So I think end to end process is really more of a journey through that and not necessarily just code transformation. Okay. And one more question before we open it up to the audience for questions. What is something we can do today in modernization that we weren't able to do even 2 to 3 years ago? Well. Um, if most of you have probably attended this morning keynote, uh, Omri might have presented three, three, three model, probably seeing that three days for assessment and three weeks for a POC and three months for going live.

If you ask me six months back, if I would have, would I have said that confidently? Probably would have. I would have not said that. The reason is, I think the speed at which we can go now with all these is intoxication. The agents that are currently available, whether it is AWS transform for reverse engineering, bringing the Accenture agents to bring in the domain knowledge and as well as years of delivery experience and as well as Pega Blueprint to create the the target workflows and the data models, whatever is to go live. So this whole thing of coming the whole thing together, reverse engineering through agents, augmenting with business capabilities and domain knowledge from Accenture and as well as building the modern application using the Pega Blueprint same way everywhere else, wherever the modernization is happening, we can confidently say that we can do this three, three, three model.

We call it as a disruptive delivery. Earlier, these projects used to take years and thousands of manual people involvement, but now we can go faster. So the three, three, three model is the new way of doing the business. Yeah. Excellent. Joel. Yeah. I think you're right. Is the speed the speed that you can do things has dramatically changed. I mean, the idea I did a ask of our teams and how many hours would it take to reverse engineer by hand? Just 2.45 million lines of code. They said 16,000 hours. Now, I could do that with AWS transform in a day. And it's pretty amazing what you can do because before we never did that. 16,000 hours. Because who would pay that price just to have some documentation. But now I can use that to actually do that documentation and extract the business rules and use that for spec driven applications.

So it's amazing how this is developed. And it wasn't even possible six months ago. And it's funny how fast we're seeing the change, like addressing the risk for testing. And 6 to 9 months, that's an AI time. That's a lifetime. And absolutely. But we're making it happen. So it's pretty incredible. Um, so opening up here to the participants, if you have a question, please go to a microphone. Go. Hi. Good afternoon. My name is Arnaldo Garcia. I'm with Accenture, the federal practice out of Washington DC. My main question is around the reverse engineering. That seems to be where the business is most concerned about when applying AI to reverse engineering logic harvest. What are some of the recommendations that we as integrators can provide to our business partners on how to accelerate that process and make it less painful for them? Joel, you want to take that?

Sure. I can take that. So the question was, is for reverse engineering, how do we make the process less painful and speed up the process from there. I think one of the things is, and that's I always lean a lot on AWS AWS transform, especially if they're an AWS shop. Being able to whitelist AWS transform is much easier than bringing tools in. So it's really recommending the right tool, the right pattern for the client from there. I think the other things that we do is there's a number of prereqs for reverse engineering. Like for example, let's collect the code. Um, it's amazing how, how, um, you know, sometimes it can take 5 or 6 weeks just to get the mainframe code together. Um, from, from there. So just having those prereqs that if we can have this set up. The other thing that we've done at Accenture is interesting is we've actually have, um, ways to come into the mainframe to automatically extract that information.

So, um, there's something called Zoe that allows us to actually access all that mainframe information directly from a Linux box from there. So I think there's a number of things that we can do to speed up that process, make it less painful. Right now, what we're showing with reverse engineering, we really only need a fraction of a semi during that time to be able to do that where, you know, six months ago, a year ago, we need a full time semi or two as part of that process to understand what they're doing. Over here to the left side, stage left. I appreciate that. Alex Norris, CVS healthcare. Um, Joel, the action of understanding, um, kind of the, the knowledge, the, you were talking about it that it leaves, but how do you protect that as you learn those rules, as you, as you say, okay, go and go and research this.

Um, but there may be things embedded in there that are really, um, human centric again. Um, and how do you protect that in terms of like with medical information, if you have the wrong or missing information, the diagnosis may not be right. So that's the thoughts, right? That's a great question. The question is, is there may be sensitive information in the code sensitive information in the data from that. How do we protect that as AI is going through it from there. So one of the first things I would say is, you know, that's something that we deal with a lot is one of the first questions is asking the client, is there any PII or Phi or any of that type of data within your code? Most of the times in the code itself, we come back. Yeah, there may be a little bit, but not too much, but it's one of the first checks that we do.

From there, I think the other thing is there's a number of other mechanisms, services with AWS that we can actually use to obfuscate that data or office that the code from there. So I think it's really about doing that and making sure that it's secure going in. I think the last thing I would say is that's also why it's really important to have a human in the lead with this process, because one thing we don't want to do is just let AI run amok and come up and start exposing things that we don't want to expose. So if you look in AWS transform or in any of the other processes that we have, there's always a human in the lead as we're going through the different steps to verify those outputs. Thank you. Thank you. Over here to the right. Yes. I'm Ori from open Legacy.

I think you are cheating us. You're not telling us all the things you can do, but you can do much more than that. You know, because when you analyze, you discover and so on, you understand what's going on. But you also get the information to plan your next move to decide how you're going to decompose your system. What are you going to move today? What you're going to move tomorrow? And then we get to coexistence, right? So coexistence is not a bad thing. Coexistence is actually a situation that's saying, I can modernize incrementally. I can do it step by step. Some things are going to break, but we got your back, right. We know how to actually bridge this gap. So I want to hear your point of view about coexistence and how do you deal with this. And why do you think or do you agree with me that coexistence is a good thing?

It's not a bad thing. I love that this question came from open Legacy. If you guys don't know, open Legacy look them up real quick and then you'll you'll see why I find this just fantastic. Ron, do you want to take this or. Yeah. So since we are not recommending for a big bang, you always have to take the application. You break the application into logical chunks or decompose into the the sequencing of the modules that you want to do. So you are almost picking one module at a time, one business function at a time, and modernizing it. As each business function is being peeled away from the the the mothership. You still need to have be able to integrate back. It could be an API integration. It could be a database integration. It could be file delivery integration. You really don't know depending on which application or which which business function is migrating.

So there are many ways to do it. I think open Legacy has their own set of APIs that you can be able to integrate and build it. And some of our other partners also has the capabilities to do it. But identifying those dependencies very early on and defining what those interfaces and integrations and which product to do it. And you should be able to integrate that quickly. And even within the AWS also, we are working very closely with open Legacy to build that composable architecture where as you identify that first workload to be migrated, what interfaces do we need to be built? That agent will be able to immediately suggest you, these are the set of interfaces that needs to be built, and this is the specs for those interfaces so that as you build the modern application, you not only deploying the application, you're deploying those API specifications so that you should be able to kind of integrate back into the, the legacy application so that you both will coexist.

And as you move the next workload slowly, you will move in a strangler fig pattern. Thank you. All right. One last question. Andrew Hubbard at Edward Jones. I wanted to ask about project leadership and project sponsorship at the enterprise level. From your experiences working with clients and knowing use cases. What are the differences of outcomes on where project leadership that sponsorship at the senior level lives, whether it lives in the tech space or whether it lives in the business leadership space? Are there differences on the outcomes, on who's driving the transformation? So I want to start with that one, because I actually had a really great conversation about this earlier today. If it's a tech led project, it's the success rate for tech led modernization is 20 to 30%. If it's a business led, especially an AI driven, business led project, 90 to 95% success rate.

So I will always say it's better to have the sponsorship coming from the business, because this is their opportunity to not only modernize the technology, but also to modernize their business and their business processes. Amy Browne Joel, either of you have thoughts on this? Yeah, I think a business led is very, very important. From there, it needs to be a partnership between the business and IT because the business, one of the things that you need to do is you need to report to the business. The successes get early business value. You need to get that to prove that things are happening. But I agree with you. If it's IT led, it's typically cost led. And as we all know, cost is great. But at the end of the day, I think Alan or somebody said it earlier that if you're happy or no, Omri said it earlier, which is if you're happy with if you're focused just on cost, you must be happy with the applications.

You're just not happy with the bill from there. I like that statement. Yeah, I do too. All right. We have time for one more question to the two of you before we wrap it up. So let me ask you, if we're back here in two years from now, um, what do you think you will say differently than you're saying today about AI and business or Legacy modernization? Well. Um, two things. One, there are so many startups that I get to meet almost on a daily basis, weekly basis. And everybody has AI tool now, and everybody says that my tool can solve the problem, all world problems. I think that's all of tools and amount of AI agents coming in will eventually come to a point where that's curve will turn into a maturity level, where you will identify the real differentiators in the market. That's number one, so that you don't have to try 100 tools to figure out which is the right tool.

So you'll basically come to a situation where you know exactly the difference and the, the number two, you probably will also start to kind of seeing that where AI really makes the difference. Today, AI is being applied uniformly all over the place. So as Omri talked in the morning, the traceability and auditability and determinism, because AI tokens are expensive, there is no need to apply AI for every every problem. So there are areas that you will really need a deterministic way of auditability and probability, and then apply AI where there is a need so that that makes making a big difference. So my prediction prediction is you really find out the right tools that will solve the problem. Number two, you will also find out that where to apply AI. And it is the modernization is going to be. It's no longer years and decades of the project.

You. You should be able to do it as seamlessly using set of the tools that's available in the market. Excellent. Joel. I think those are really good points. I mean, I also, I, I have this slide that I talk about, which is going from 2020 to 2026 and showing how AI has really improved. And it's interesting because in 2024, AI was available, but humans were doing most of the work and trying it and that kind of stuff in 2026. Now AI is doing some of the work, like in Agentic workflows. And from that, I think in another two years, we're going to see a lot more automated processes around that where AI is being able to think and be able to, you know, make those things happen much, much faster. From there, you know, maybe we'll be down to one one, one instead of three, three, three.

I don't know. But the other thing I would really point out is I'm hoping in two years or maybe in one year, AI will be able to run videos better than me. But that's my hope and dream. We can hope for that. Oh. I'm sorry. We got 29 seconds. Hurry. So a quick question on the, um. We talked about the Phi and PII. What happens when you're actually throwing out, you know, their intellectual property. So basically, uh, clients that are not willing to share their code out to a third party, the AI agent in this case, how would you handle something like that? So one of the things that we always do is working with AWS. We always run all of our agents, everything with inside of the client's environment. So we never pull anything back to our environment. So there's never any transformation of, of that and from there.

And if they really, really want to be secure, we can actually run some of that stuff on premise to be able to do it within their, in their, even within their environment, if they wish from there. So I think there's a lot of things that we can deal with PII that we haven't run into a problem with a client saying, no, don't do that from from there. Yeah. If I, if I may add, um, the way the AWS transform is built, your code stays within your VPC, your virtual private cloud. So it's not leaving your boundaries. And even the generated outputs, the graph and the business rules, and even all the outputs that are generated business specs and all will be stored back into your, your, your own environment. So we are not basically storing neither the inputs or outputs. The processing still happens on the agents, which is approved within your, uh, your accounts as well.

So that way you are not like leaving it out outside where you were worried about whether your data is being used for model training or things like that. So none of that is happening. It's all stays within your account. Yeah. Right. And just to add on to that real quickly is if we do do a rag database or some extra knowledge around that, again, that all stays within the VPC. So everything's within side of the client environment. Yeah. Okay. So we went a little bit over, but I think that was a really important question and it needed to be answered. But thank you so much, everyone, for joining. As I said earlier, or I think Joel said earlier as well, the Accenture booth is Booth 16 right next to the AWS booth. So if you have questions for any of us, you'll most likely find us or people that can answer the questions for you at one of those booths.

Thank you so much for joining. Have a great day.