PegaWorld | 27:40
PegaWorld 2025: Cloud Modernization: ANZ Bank Transforms from Legacy to Future-proof on Pega Cloud
Discover how ANZ Bank transformed their operations from legacy on-prem to future-proofed Pega Cloud®. By upgrading and migrating ANZ's legacy Pega applications from on-prem to Pega Cloud, ANZ Bank has been able to stay current with patches, updates, and upgrades in record time and frequency that simply wasn't possible when operating on-prem. Join us to learn how ANZ Bank approached their cloud modernization journey and how they are setting themselves up for success.
PegaWorld 2025: Cloud Modernization: ANZ Bank Transforms from Legacy to Future-proof on Pega Cloud
Are really grateful to be here and represent the work my team has done over the last three years to transform our Pega estate to a modern platform. So the things I'll talk to you today about are the our what we've been through in terms of that legacy to modernization, the value of a SaaS offering that we're finding and leveraging the latest features.
So a little bit about ANZ. So our purpose is to shape a world where people and communities thrive. And we bring that to life by improving the financial well-being and sustainability of our customers. And the reason that's important in technology is we provide the systems and architecture that support some of the most critical processes within the bank, which include home lending, disputes and payments.
So ANZ's are one of the top four banks in Australia. We're the biggest bank in New Zealand. We've been in operation in one form or another for almost 200 years and operate across 29 markets and 8.5 million customers in over 40,000 employees.
So, um, when we set out on this program, we had some goals. Um, and it was broader than our, our Pega estate. We had a number of different workflow assets. Um, and some of them had been in operation for 15 years, and we had to organize ourselves around those assets because they were old and and required specific skill sets. And so we had key person risk but we also had risk around those particular assets. So what we wanted to do is is modernize all of our assets, reduce our on premise infrastructure, simplify our architecture, decommission the legacy assets and legacy infrastructure. Um, and, and really reduce the support costs.
So like I said, we had several platform teams. We had several application teams that were managing a disparate group of assets. And this this picture kind of brings it to life. So what you can see is up the top is our what was our current state. And all those salmon boxes were a range of different applications. So there were um on on different versions. So all the boxes down the the bottom in blue are the different versions of Pega that these assets were on. And the box is highlighted in the blue circle where all out of support. So they were what we'd consider legacy.
So we had several Platform teams managing them, several application teams managing them. What we wanted to move to and what we've almost completed is that target state down the bottom. So we've simplified our stack. So we've got five stacks. We've organized ourselves around division so that we can provide our our users transparency around cost. But we've also separated out some of our key applications so that they've got a clean runway around change so they can manage their own change their own upgrades.
Um, what we've also done is collapse a lot of the smaller applications into what we call our standard workflow, which is a standard offering, and we have about 53 teams and functions using that standard offering. So we've been able to reduce our support costs by, by um, by doing that.
Now you might say, how did we end up in this, that current state situation, which was um, obviously quite messy. So being on premise, it was really hard to, to upgrade, um, for, for a number of reasons. Some of it was by the time we got to an upgrade, the architecture had changed. Um, sometimes the underlying infrastructure needed to be upgraded as well. It was all happening internally, so there was a number of teams to coordinate with, and it would take us several months. And that was a real challenge for the business as well. The business was trying to drive value and, um, develop new features on their application, and we'd have to put a hold on that while we were doing that upgrade.
So if I move on, we've we've been going along that journey and it's definitely, um, had some challenges. So a big one has been the data migration. We've got about eight years worth of historical data that we need to manage. And we really wanted the majority of that in the one place. So we wanted to migrate it all. Um, there's a sensitivity of that data. So Australia is a very highly regulated market. Uh, and we have to go through a number of approvals to, to get that data into a cloud and um, a third party service, um, and even for go live, a lot of, a lot of applications had a number of cases that were a work in progress. So they had a significant backlog and work in progress. So they needed those ready for day one. And so they all had to go through on that change weekend.
Integration and security. Uh, you know, I always felt like everyone was always ahead of us, but, um, I'm finding out that that that wasn't necessarily the case. But when we started a lot of the security patterns that we were developing were new to the bank, and so they took a lot of sign off and review. Our applications are very heavily integrated. So those of you who have workflow applications, you would know that's where you get the value by integrating them and bringing the data through and and having them communicating with other systems. Um, and so what that meant is we've got to coordinate with a number of other systems, and even through the program, through the the migration of a particular application, they'd come back to us and say, look, the way we need you to integrate has changed. And so we'd have to do rework and so on.
I mentioned the regulatory oversight. Um, so we have to go to our regulator and ask for a no objection to have our data hosted by a third party. Uh, and so that, that before we can get to that internally, we had seven steps of approval. We know we've got risk teams, assurance teams, business teams. And each time we're, we're presenting, um, for for approval, there's a significant amount of work to get there, and business change management, as I mentioned before. Businesses are trying to develop their own features. They've got their own things happening within their business, so they can't just up and leave their queues to train and learn a new system. So that was also a significant challenge.
So as we've been moving, we've started started realizing the value of this journey. So there's been a 14% reduction in total operating costs. And a big part of that's been, um, been because as I've said, we had several platform teams. We've been able to combine them to a single platform team now, and rather than having to manage the the assets, they're actually acting as a center of excellence. So they're coordinating activities and and acting as consultants to the other application teams.
Um, We've got simplified architecture. Um. We've been able to decommission a lot of on premise infrastructure, which is also part of that cost. Um, but also upgrades are now done in weeks. So we've been through a number of upgrades now, and whereas they took months, really a majority of our efforts just, um, testing environments, fixing our customizations. But the out of the box work, out of the box features work pretty seamlessly.
And an important thing that we've learned through this program as well is, um, because we're now able to archive data within Pega, it actually improves system performance and stability. So that's been a good win as well.
So by outsourcing the platform management to Pega, there's a range of tasks that we no longer need to do. Uh, and there's a couple that have been um, really big wins. And an example of that was a couple of months back. Now we got the notification notification from Pega that they were doing three database upgrades. And uh, we were like, what do you mean? Well, we haven't we haven't been speaking to you about this. We haven't been involved. They said, you don't need to be. You just need to turn up and do business verification testing. And the whole team was really nervous about this. And I said to them, look, this is the new model. This is their expertise, and we need to trust them with it. We did that and it worked seamlessly.
Um, we've done two version upgrades. As I as I mentioned, they've gone well and we're getting better at. We've done another one since since then and, um, we're getting better at them each time, uh, and patching and so on happens without any downtime. And it's a task that our, our platform team no longer, no longer needs to do.
If I give the other side to that coin, I think there have been some challenges. Outsourcing. Outsourcing this service. You know, at the beginning we had, um, we had an outage and we had a change that happened that we weren't ready for due to a miscommunication between the teams. To piggies credit. Um, they turned up, they showed what their learnings were, and they've improved their service offering. And since then, uh, fingers crossed it's gone really well.
So, uh, I'm pretty sure you've all heard about blueprints, and I know that's not the purpose today, but. But, um, one of the benefits of moving to the latest version for the business is that we can leverage the latest features. One of the challenges that we've had for the business is for them. There's no there's no operational value to moving to cloud. Functionally, it's it's the same, um, asset. but when we're able to use the latest features, they're able to see that value.
And so we had um, our first this is our first go at Blueprint, which happened about six months ago. Uh, we had a scams process that, uh, was using basic workflow, uh, and by using Blueprint typically and I can say this because I used to be on the business side, but typically we bring the business in, we'd ask them for their requirements, they'd do the best they can to articulate those and say what they they new to technology teams would do the best they could to to interpret them and capture them. And then it was good luck trying to deliver.
But by using Blueprint, we can build as we go. We can give them a prototype, which means they say, well, actually that's in the wrong spot, or that that's in the wrong order. And um, and the feedback from the business was it was amazing. It made a real difference Friends and significantly reduced our time to value and and with this we were able to integrate into our fraud monitoring system. So we've automated the case creation and allocation to a scams officer, which was previously all happening manually, which is driven quite a bit of value into that process and helping them to reduce the the number of losses and protect our customers.
And this is just a little bit about our strategy. And it goes to that that value of using a modern system. Um, so our strategy is to orchestrate processes for ANZ and drive automation. And so by, by being able to integrate really easily with modern systems and using some of Pega's out of the box features, we're able to bring in data, enrich it, and give context using information from documents in the process. And ideally in a lot of places, we're able to use that information to process straight through. But where we can't or where there's judgment required, we provide it to a user to, um, to to make judgment. But they've they've got all the information, whereas they used to have to go go outside of the system and look in a number of places. Now it's presented to them. They're able to have all that information there and make a decision.
The big kicker for us and and where we're quite excited with the agentic, um, agencies, um, taking action to downstream systems. So whether that's through robotics APIs, but that ability to make a decision via a prompt to to send those actions off will significantly drive automation across our teams. Thank you.
Q&A Session Q so that's the main things I want to cover off today. Time for questions. Okay. Yeah. Um. Thanks, Andrew. So if there are any questions, if you could use the mics, um, and maybe whilst we wait, wait, I'll ask for a quick one. Andrew. Yeah. Um, so if you could, uh, start again knowing what you know now, what would you do differently to what you know, how you did it the first time around?
Uh, yeah. Probably a learning early on in some of our migrations, we did, um, have some defects. And, uh, and that was on our go lives and on our implementations. And what we found was our testing wasn't thorough enough. And a big part of that was, um, our ability to to use the right data to do testing. And so, uh, we worked with the Pega team on what best practice was, and we got a lot of their advice on how we can do that. And so we improved our testing significantly. And we can not this weekend, but the weekend before we went in with our, our merchant disputes, um, application went live on Cloud and we had no material defects. We had a few small ones which we fixed the following weekend. So that was a learning through the process. And and it was. And to to be fair, Pega were quite good in terms of giving us that advice about how to test in Cloud. Okay. Thank you. Anyone else?
Hey. Thank you for the great presentation. It was very insightful. So I had a question on one of the things that you mentioned as far as a value proposition. Uh, you had a 14% reduction in TCO. Can you elaborate more on that? Which phases or what assets of the cost parameters went down there. Obviously some that went up. So yeah. Can you elaborate on that? Yeah, I had a follow up question too. But after I'll ask after.
Yeah. So, um, look, obviously the licensing costs went up significantly. Um, but what we've been able to do is reduce our on premise infrastructure. So that's all all of that's going and that's part of the bank's strategy is we're we're trying to exit our data centers and, and be a cloud first organization. Um, so the second part was I mentioned before that we've consolidated our platform teams, and that means we don't need as many people to support those applications. And because we're playing a different role and Pega is doing a lot of that work, we need less people. So there's a reduction in run costs. But a big one was we looked at our asset lifecycle management investment, which is the, the, um, the, the funding that we get to address end of life applications, and we were spending between 1 to 1 and a half mil per year. And we won't need that funding anymore. So that's that's kind of gone. So that, that. That was a significant amount of that. Thank you.
Yeah. Hi. Andrew Anu Shah from Accenture. So you did show us that you condensed your architecture from a 20 plus apps into five plus apps. So I think I've got two or need to get two points of view around it. One is how did what are the key decision drivers to condense it? And what we generally realize with Pega applications is as a business, I'm too used to having my app in my way, and over a period of time, if you just suddenly come and tell me that it's an architecture change, the change management seems to be a really complex piece. So what? How how did we manage it?
Yeah, look, it is I think it's a really good point that a lot of those applications are really heavily entrenched in the business, and they're used to doing things in a certain way. Um, but what what? As part of the review of those applications, the ones that we could, um, collapse into our standard offering, we could see that what they were doing in terms of a flow was the same as what our standard offering is. So we we had to do that assessment. We had to show them how it would work. Um, and, and again, talking to them about the features that they got on the newer versions when they were on a very some of them were on Pega seven and early versions of Pega seven. So, um, you know, there was some, some stability issues and things like that. So and to be fair, um, because some of those applications had been, um, been running for so long, we'd built things into those applications that were quite valuable to the business. So we've had to build some of those things into this application as well as as we migrate them across. Yeah. Yeah.
Yeah. Hi. Thank you for coming all the way from Australia to hear long travel. Great story. I think a lot of organizations are going through this, so it's very insightful. I just want to know how you approach this because there are two ways of going about it. You can take your current application, upgrade it and just move it to cloud. Or you can, you know, it's like taking garbage and moving it. Or do you actually fix it and then move it? And the costs of modernizing. I think your presentation said the costs of modernization are one time costs. So your TCO numbers here is probably the run rate costs. I just wanted to see think about how you looked at the one time migration modernization costs, and what was the thinking at the bank around it?
Yeah. Um, look, it's a it's a big conundrum, right? Because you have to you have to have a defined scope is my view. And so our scope was clear. It was around migrating to cloud. Now, as part of that, wherever we could, we were fixing things, but we had to stay within our scope because and I've been involved in projects where it becomes a migration, but then you're adding automation and new features and the scope changes, the cost change. And so our business case was really around that modernization. We have both funding and support for each of the applications. And and we're working with them now around leveraging some of those new features. Um, but look, and to be fair, as part of upgrading, there are things that you're forced to remediate. So some of your old customizations and stuff won't work in newer versions. So you do need to remediate those. Okay.
One final one from me Andrew. So now that you've almost finished the cloud migration project, what do you see? Um, next on the on the radar.
Yeah. Obviously, being here, it's hard not to get excited about things like Agentic AI. Um, and so as you know, Paul, we're we're working with you to try and get the, the right commercials in place to have that happen. Um, so I guess for, for me and my team, it's really about, um, driving process automation and doing that in a way that's, um, the best outcome for the customer. We have applications that have quite good STP, and we've got applications that are literally just workflow. So by driving integration, by enriching, uh, the information that users are receiving, by automating the actions that need to be taken, we'll be able to achieve that. We're also, um, obviously part of a big organization. So we're we're working with a number of other applications like Salesforce to, to to be integrated in the right way. So it's a seamless experience for all users and and for customers. Great. Thank you. Anyone else?
Oh we do. Yeah. I'm going to ask you one other question. So you asked about the you mentioned about the BV. So is there a difference in the BV that you perform on prem versus performing on cloud. And especially the the pace of movement is much higher on the cloud. Have you taken a step back with like a reduced bv the the scope of the BV being lesser.
Look, I think if you're referencing the the database change, uh, I think um the probably the scope was, was similar for bv Um, but but I think we have realized that we do need to go back and review our whole testing approach now and, um, and increase the level of automation, especially as you as you saw on one of the previous slides, we've got stacks that have, uh, a few applications in there. And so, um, when we make a change across those stacks, we need to be able to test across all those applications in an automated way. And so that's one of the things we're working on now. Thank you.
Thank you. I have a quick question from a colleague about what's the time frame. What how long this transformation took.
Yeah. So it's been a three year program. Three year. Yeah. So we're we're coming up on three years. Uh, well, one of the applications will spill over. Uh, that's because they started later than expected rather than it's taken longer than expected. But yeah, we've been able to get faster and faster as we've gone. And to be fair, we we started with our oldest and most complex applications first, and the more modern ones have been a bit simpler to migrate.
And it looked so fragmented. Did you have to change? Like what did you use for deployment pipeline? Did you have to retool your existing one? Did you use one? And like because now you merged it all into what, four stacks?
So so um, we leveraged Pega's tools for they've got Pega deployment managers. So we're leveraging that now and have found it a good tool.
What about enterprise logging. Do you guys use. I don't know if you use Splunk for example when it was on prem. Yes. What is it doing right now in the cloud.
Yeah. So again Pega have um their monitoring tool PDC. And again, uh, as we're upskilling in that, we're learning that it's quite a powerful tool and has a lot of good data. Okay. So it's like PDC is kind of isolated to only Pega. And that suffices your company. That's right. But we have we have Splunk and Splunk across the rest of the organization. So OK and the like.
Did your DBA team like you had to give up database control completely. Right. And let's say if there is a production issue, the ability of a DBA to go in and quickly do a query that's gone. So did you have to rebuild? Like, I don't know, triage processes around the production issues or. Look, look, as I mentioned earlier, we did have a we did have an outage. And and that I guess goes to your point that you are giving up control. Um, and that's the risk I guess you're taking. Um, but it, I mean, we had production issues when we were on premise too, right? These things do happen. Um, but like I said, I think the the point of it is that the relationship is one where Pega came, they performed their Post-incident review. They were completely transparent, showed what they were going to do differently, and we've seen the change in process. So yeah. Okay. Thank you. Thanks.
Hi. Um, so, um, I wanted to ask about when you're doing a cloud migration. I mean, I mean, security is an important part of cloud migration, right? So just want to understand what sort of implications, when thinking from bank's perspective, that you have come across, uh, when doing, doing like a data migration and case migration and all that. And what sort of additional time that you have to spend or sort of I'm just trying to understand the implications that you have come across.
Yeah. Look, obviously, um, moving data to via the internet to, uh, to an, another location has its risks. And so, ANZ has quite high standards around how how we authenticate at each stage. And some of the implications of that, even for users in other locations, because we have users in other locations outside of Australia. So sometimes the the they have to they have to be authenticated back in Australia. So there's a bit of sometimes a little bit of lag there. Um, the other thing is in terms of uh, the, the some of the risks around the data migration, if that migration doesn't go well, then the the case data is all wrong. Uh, and, and essentially it won't work in production. Right. So, so that that data migration is probably the most critical part. It's been my experience. Okay.
There's no more questions. Um, thank you very much, Andrew. Thanks, everyone.
Related Resource
Product
App design, revolutionizedOptimize workflow design, fast, with the power of Pega Blueprint™. Set your vision and see your workflow generated on the spot.