PegaWorld 2026: Pega Migration to Cloud with Upgrade from V23.X to V25.X

Thank you all for joining us in this breakout session. We would be walking you through the journey that we have on a few of our client implementations on the cloud side, uh, and, uh, give our, uh, the experiences that we have, uh, and share it with you. All right. So this is Manas Patro. I'm from Infosys. I'm a senior director with Infosys, and I've been with the Pega for since last ten years or so. Uh, and that's a lot about me. I wanted to give a quick brief on our Infosys practice that we work with. Pega. Uh, we are one of the key transformation player, along with, uh, we work with Pega on multiple verticals across segments. Globally, we are also the largest one of the largest. Pega GSI with over 22000 plus working Pega professionals across the globe with us. Varied across multiple roles and it's a large pool.

Summing up to around 15,000 hours of experience that we carry. With the recent Blueprint aspect, since a year or so, we are one of the leaders in the Blueprint user community, with close to 12,000 13,000 odd submissions that we have done in the past one year. Why the edge of Infosys? We have multiple accolades. Just to name a few. We won the Blueprint Pioneer Award early this year in January for the largest submission. We have the practice level of recognitions and we got the Communication Award. Also in the verticals. Yesterday it was announced we have the PegaCloud implementation, the first ever PegaCloud implementation that we did along with Pega. When we started with. And also we have one of the largest customer service implementation that we have worked with, Pega. That's at a pretty high level. I just wanted to give a brief. Our partnership with Pega, it has actually evolved over multiple years from the BPM implementation world to the AI LED and AI first stories that we are currently working with.

We are also the platinum Allied partner, uh, with Pega and multiple, uh, conferences and connects across varied meetings. And we stand tall on this entire segment on the implementations that we work along with at the client places. So the cloud. Right. So just to quote right from the on prem limitations to a cloud powered possibilities from maintenance overheads or maintenance aspects of world to the momentum aspects, right. It's a remarkable shift that we have seen at some of our clients, and that's some of the journey that we will walk you through. So though it is a larger phase of a thought process, but we wanted to focus on key four pivots that we start from the assessment. We move to what is the target state that we are looking for. How did the planning go around and from the Galui perspective? So we wanted to run you through, through these phases in detail and take any questions as we go along.

Right. With that, I will hand over to Anand Tiwari, who is our principal architect in Infosys, also part of our COE. So would you like to. Hi, I'm Anand Tiwari, I am Pega Principal architect at Infosys managing Pega COE for Pega implementations. So I would like to start with the journey of what it takes to get to cloud. Before that, just a quick question. How many of you are PegaCloud already? Cool. Good. How many of you are in the in the work or getting there? Working on it? Very good. And how many of you are yet to. The rest I'm going to assume. So great. So as you saw this morning. Right. And some of you are still considering, should I go to PegaCloud or should we with AI disruption happening. Should I look at, you know, transforming elsewhere. But you saw the morning keynote from Alan, right?

The biggest winning in PegaCloud is the saving on tokens, right? This is as much as it sounds like a one liner. It's a huge cost benefit that you have to that cannot be ignored. So I think for that you have to be on PegaCloud, right? Because the whole AI everything runs on PegaCloud. So what is it going to take? So it comes to the strategic vision, right? So if you ask our ex, they are looking for a very scalable platform and very robust platform. And what is the minimal cost it will take to run my applications. And then the objectives. Right. If on a cloud processing they want to see what is the lift and shift, I have to do how minimal it should be. Right. And the conflict with the modernization, right. As we have Pega, we also have other apps running in the enterprise and the modernization aspect of those applications, along with Pega transitioning to cloud.

Right? So so when you make your journey with your executives, okay, we want to go to Cloud. The first and foremost is the scoping the lift and shift at a very high level. Try to keep it minimal and come out of the timeline, strategic timeline with working with the rest of your partners. Because if you are dealing with a customer service application, you do have to consider all your integration layers. And when you come to integration layers, they may have their own schedules and they have their own modernization plan and their own features. Time to market. Right? So we have to make sure we first identify what is my timeline bucket, where I can fit this right. So that is what is the key aspect here. And the success of the planning is very critical to find the time window, especially, you know, in any industry, the time to market always has a conflict with the upgrade I have to do.

So how to make this upgrade so much, not a technical debt and make it business compelling, right? So that's where your AI story comes into play that you get as an outcome of moving to PegaCloud. And then you also have the aspect of, I don't know how to manage my infrastructure. I'm a Healthcare or a finance company or a bank. Let me focus on my application. Let me see how I can build a features for my business where I can have time to market, you know, and be competitive in the markets, market space. So in the comprehensive assessment, you basically go through the application overview. And what do I mean by that is like you have to go sit and figure out what is it going to take to lift and shift, even though I want to just do a minimal lift and shift because the application was running in-house.

Now, there are so many of us like, you know, in different databases, right? And because of certain market conditions and timeline conditions, we probably put a lot of business logic in the database layer, right? Namely the stored procedures, functions, etc.. Right. So how do I take that? And you know, how do I remediate those? Because when you go to cloud you, some of those will not work because Pega in their scope of PegaCloud, they only take the Pega data, just that whatever is in Pega data which Pega owns. So the rest is on you. So. But we have been used to using customer data where custom data, where we own our data objects, which now has to be remediated. So that scope is very important. And what are the integration discovery. Let's say I have put too much stored procedures or heavy join RDB sqls right.

You have to figure out now moving forward, how do I what is the plan for that? Right. AM I going to write APIs if I have to write APIs? It's not with my just with my team now. Now I have to work with my integration partners who have to have a plan so that they support my plan. Right? So that buy in has to be important. So the discovery is very important of integration. And the last DevOps, am I running my DevOps CI, CD pipeline in-house with my enterprise solution or I am already on a PDM, right, which is the Pega deployment manager. If you're already on Pega Deployment manager. You are ahead of the game, but if you are already on a CI CD, you're most likely are using the local end of install. So you have to plan for either moving to a Rest based APIs for deployment, or you have to look for the PDM as a solution.

Because PDM. PDM comes with also its data pipelines, which is going to be very supportive for you for your post Pega management of releases, target architecture, and the state of migration. So you have to assess the outcomes of the migration. A clear migration the assessment involves basically a clear plan. Now because when you come to assessment you have to have a plan. At this point, you should know what teams you need, who you know, who is going to do what. Yeah. So PegaCloud will basically the Pega team comes and say, okay, we are going to lift and shift your Pega to Cloud. So do not assume that all the work is done by PegaCloud team right? Because when they say when Pega says they're going to do, they're going to take care of the Pega part of it. So we have a responsibility. So either we have to do take care of the remaining assets and the business logic that's sitting in my database.

So the biggest question is, am I doing it or I bring some players who have already done this. That's where Infosys comes in. So we come in and we do that risk risk, risk identification and mitigation plan. And we are going to have either a long term or a short term strategy. That depends on the modernization plan you have in place for your integration layer. So then the environment mapping. So we have environment like ten different environments because it's in-house, right. I've been running it. And if I need environment, I get an environment that's of course a cost to it. But the, the, the feasibility of having it is there. But when you go to PegaCloud, the security layers are very clearly defined. You have a development security layer, a test layer, and then a production layer. So your sandbox dev comes into your dev layer.

Your testing layer takes care of your UAT environment, your test environment, and your staging environment. And then finally the production layer has a prod and preprod. The concept of prod and preprod the Preprod is before you go live, you test it out everything and then you go prod. Now the other important factor here is where am I running my performance testing as enterprise wide? I'm already running my performance testing in Pre-prod, which means a pre-prod is a secure production layer. So you'll be easily already having a plan to copy your data production data, mask it as part of your monthly or quarterly plan to copy that and run your PT there. Now, if you are there, you're already ahead of the game again. If you're not, you have to figure out the stage environment. The stage environment comes as development and test environment. So you have to upscale it for your performance environment.

So that is something you have to take into account. And then the AP analysis and scoping decisions. AM I now doing my APIs on an already available API established in the organization, or is something new? I have to plan for. Right. So these are the critical aspects of the assessment and the planning part. Target Cloud environment. Target Cloud is PegaCloud. There are some do's and don'ts and giveaways and takeaways. So first and foremost in being an in-house, we probably had access to the database. So anything we want to go look, we probably use a SQL developer. We just go look. And we have we have great access right? The first and foremost thing you lose is the access to your data, right? And that is a good thing, not a bad thing. Because you know, you you're saying, okay, run my company, here's my data.

Keep it protected, right? I trust you because you take care of all my hardware, all my security upgrades, everything. Now, what I need to do is make sure whatever data I need for integration, whatever I have put my business logic in my integration layer. I have a plan to move that to APIs and then have that in place so we can run it seamlessly. And here the other important part is also to assess how cloud native is my integration environment that I'm working with. So if it's not cloud native, then again, your risk and mitigation plan comes into play. You may have to make some short term and long term strategy plans, because always the goal should be to lift and shift the bare minimum metal that's needed to go live. Because you want to go live, have a return of investment, then you reinvest in modernization.

That is the biggest win for you. And also a very good story to tell to business. So it doesn't appear at tech debt and business sees the value for it. And so the comprehensive security measures, since Pega mostly runs on AWS and Google, they have their own set of layers of security already established. On top of that, Pega takes care of its own security layer. Then you have your organization firewalls and your security groups and layers. End to end flow. Now here's where the devil is in the details now. So you have a cloud partner who is working on the cloud transition. Somebody like us in the middle, helping out with all the nuts and bolts of the migration. And then we have you who are our client partners, who are your architects, who we work with to make sure that we have planned for all the APIs that we need, any security layers we have to address at the application level, and then any data related components we have to deal with.

Now, the key aspect of in the in the flow comes the areas of responsibility, right? So the one important thing here again in the lift and shift is Pega will take care of copying your data in prod and stage when it comes to dev and QA, the responsibility is on the client side or the service partners who work with you. So we have to make sure we create the right packages. It's a great time to see how much unneeded, especially the data part, right? Any unwanted integrations that are sitting there not cleaned up. The time to do that cleaning as well, right. And as for the rules is concerned you can again another great time to do a skimming a major version. So you go with just a clean code that I need. So I start a new fresh rule rule sets and code in the cloud environment, and I leave the old baggage in my on premise.

Right. So you can keep that for references if you need. So and then again, the because what does that do is it helps your migration faster and cleaner. And the other important aspect is the data, right? I've been in production for ten years now. Oh, by the way, we didn't have an archive strategy or a, or a first strategy. Right. So this comes into a big play again because the most of the CTO's. If you go and talk to them who are who are running their assets on cloud, the one big thing they see is this cloud is saving us money. Oh, by the way, we forgot to archive and purge. So the disk cost is increasing right. So the disk causes comes separate right. So you have to make sure that the disk that is very key in the in the cloud migration. So keeping your data also trim and slim is very important.

So you need to have a strategy. If you already have that's again good. If you don't it's time to start planning because it has to go your post cutover. And as far as the cutover and hypercare you plan your day like who are all my integration players I have to deal with? Who's my systems team? I deal with my database team I deal with, have the dates and everything logged in and follow through their upgrades and schedules. So make sure that you know there's no risk for when you go live. It's planned out and no surprises at the last minute. With that, I'll hand over to Manas to talk to the planning. Yeah. Thank you, thank you Anna. So planning, right. One of the most interesting phases in any project execution probably, uh, wherein if things are not planned in the way that we anticipate the end goal, things can go off off the radar at any point of time.

So we, we, we encapsulated our learnings in terms of what needs to be planned ahead during the entire, uh, project, which we wanted to share. The key thing that we started was, uh, most of the time, I think we get started with the stakeholder alignment, right? Every stakeholder, because there are so many components in the moving pieces here. We need the right alignment with all of the key stakeholders who are involved in locking down how the release would look, where the changes would be aligning in their respective maps so that there is a clarity upfront and not during the execution, which causes a lot of potential delays and it delays, right? Technically. Then the next thing that where we had seen more, uh, emphasize, uh, way of for the planning is on the integration aspect.

All of the integration dependencies needs to be aligned first in terms of what changes they need to make for this rollout to happen and take them, uh, have them API ready, have them authentication ready to be upfront prepared that when I go for my migration or the cutover, that everything is in place from all of the integration components, data migration, one of the key aspects wherein we, we plan for all of the Remediations upfront and, uh, be it any to any database or Postgres, which we, uh, which we saw most, uh, being prepared in terms of what is compatible, what is not compatible and manning that in the right fashion during the planning phase itself, that actually helps in the overall timeline. Lastly, the the application enhancements. While there are multiple controlled application teams which will be having enhancements running in parallel, that has to be streamlined.

That has to be according to the overall throughput that we are mapping. From a performance perspective, that is an absolute must. Sorry. From an execution governance perspective and the runbook discipline that is, that carries across the project with the key aspect, there would be the architectural oversight, wherein the formal review and sign off on the cloud architecture on what it is bringing is, is critical, and it needs to be in compliance with the enterprise standards, which is which is actually going to help you as we move along. Right. Testing environments. As Anand mentioned, multiple testing environments across the phases of the project is actually going to make the product more robust as we move along. Especially the pre-product pre-production environment testing that we run through for the valid and performance and the load that is a deciding factor. And when we go, how we go and whether it will sustain, right.

Runbook documentation as pretty much in most of the enterprise projects wherein when, who, how part and the one learning was multiple pre checks and multiple pre dry runs is actually it actually helped us to define the overall elapsed and any dependencies of the integrating systems. So that that helped a lot. Finally the collaborative code merging, which is on the periodic changes that we were making in terms of the making it cloud ready or in terms of the regular Bau. So that should be seamless as much as possible for an overall stability. Then comes the testing, which is mostly the preferable or the actual ask would be a continuous QA process wherein with every changes we are running the QA process rather than towards the end. That helps. Uh and uh, all type of testings, which is on the functional integration and which is the view mode.

Finally, the pre-prod stress testing, which is the actual load factor, which is deciding whether, uh, what load factors has to be applied and the environment, uh, needs to be modeled accordingly. And lastly, the readiness review for your alert monitoring and operational processes establishment. Right. With that, we go live. So go live. Uh, and before go live, this conflict is always going to happen, right? You are working on an upgrade. You have time window. There is time to market. That's happening in parallel. So it's very critical to make sure we don't have any releases at least four weeks prior to go live and try to see if we can move the next go live. Sorry, the next releases, or if your time to market on the new platform, then trying to continue on the old platform. Other than any hotfixes that is very critical in that four week window, that kind of reduces your risk for go live.

That's a kind of a prerequisite, right? So for as far as the go live with your data, you have a detailed runbook again, that three different plays here. One is the PegaCloud team. And before we go live, we go with the notion that once I shut down my current in-house system, I'm not going to turn it on. So it's important to have a package ready to make sure I disable all the jobs, all the qp's anything that's not needed deploys a package and we draw those rules. Make sure that even if accidentally the system comes up, those jobs or anything doesn't kick down, they doesn't kick in. So that will be your first thing. You'll deploy and shut down your system, your current system. Then you start working, hand it over to your Pega team. They are going to take it over. And they have their timeline.

They already negotiated, which is probably 24 hours to 30 hours, whatever it takes. So they'll work on it. They probably are giving you a timely update. And then once you get it, your technical team is now going to deploy all the changes, all the fixes they did to make it work on the new platform. And there's a technical validation that goes through. At that point, you're doing a second go life decision, the first goal decision you make when Pega hands it over to you. Right? AM I having enough time window to complete my rest of the deployment, or am I too late now because something happened? Some Murphy showed up and the best they could do is they said one day it took two and a half days. It never happened. I'm just saying like, you know, so just to have a plan, like a good strong rollback plan, then the second aspect is when the technical validation happens, everything goes fine.

Great. If something now broke down, I had time to fix it and move forward. Or should I start my rollback window? So the rollback when should I rollback? Right. Those windows have to be very clearly orchestrated, and the decision is very critical in that window itself. Now the final phase is the business. They come in, they validate all good. Go green. You go from that point on, it's a fixed forward. There is no going back. Yeah. So that's the goal. I part as far as the post go. I prepare a dedicated war room when I prepare a dedicated war room and be ready. It's not just the people on the Pega team who did the work, right. It's also your integration partners from networking team, system team, DBA to yourself, right? Have a negotiation where they are on standby, right? You are in the war room, but if needed, they have to be.

You're not at that point you go looking for them, right? Especially in a call center kind of application. This becomes very critical when system is slows down for a minute or two minutes. Right? So the escalation happens so fast. So then the Change Manager tracking, you know, I'm it's just more a closure part. The homework is to do all the C tasks and everything upfront and have the approvals and then the executive outcomes. Make sure the executive communication happens and throughout your go live, make sure there's two channels of communication. Keep your executives in one channel of communication so they get the periodic updates. Either you're moving forward, going good, or some escalation is needed, right. Or, and then within your technical teams have that separate. And then you go in the details of if anything has to be discussed. Same thing with your chat channels also and the war room throughout.

Have a negotiation with your product support team or product team on business side. So they manage the users because there will be certain changes and the users can, you know, it could be user error. And that comes as an incident. It doesn't have to come all the way to the IT team. It can be handled by the product team itself. So if your war room goes for two days and let's say by day two, you're you're hearing the same problems you heard on day one because there was some workaround or some user error. You're in a very good state, right? And by day three, if you if the same problems come along, I think the the implementation is successful at that point. You just look for a success story. So once your two weeks is over, remember to celebrate. It's very important because some of these upgrades are phased manner.

Yeah. Go ahead. Sorry. So the session is about upgrade from version 23 dot X to 20. Yes yes. But we are talking about very standard upgrade process. Yeah I'll take the questions. So the 23.24 dot very good question you asked. Sorry. Thanks for interrupting. Right. So the reason it went some people want to move. Yeah. Yeah. So the reason it's standard is because there's not much of a change from a 23 to 25.1. Yeah. The only thing underlying changes in the Tomcat layer that happens and your UDFs that you have to take care, right. If you have any UDFs, you have to make sure all the because all the others will not work. Right. So other than these two. Right. It's mostly the same thing. For example, in the last one I did right in one of the clients, 23.1. While we were doing the upgrade, we moved to 24.1 before we could mitigate and we could go live.

We went to 24.1. All happened in same window, no additional timeline added. So the so because we took care of all the UDFs, we did our homework already, if at all. We have to go to 24.1. What am I losing or what I need to be prepared, right? The UDF was the only big, big thing that was showing up. Not the VM based deployment and container based deployment. No, this is not talking about PegaCloud, right? Yes, this is a PegaCloud, not VM at all. This is taking your VM also to. PegaCloud. PegaCloud. To PegaCloud. No, no it is from your in-house in-house could be VM in-house could be a private cloud also. Right. And if your in-house private cloud why should I go. PegaCloud. That could be obvious question right. So the problem with that is that you are now with working with multiple stakeholders using the same private cloud within your organization.

Now you go to PegaCloud. You're working with a pure player whose only focus is Pega, who is giving you the software as a service. So, you know, so your only focus should be application at that point because they take care of all the database security, everything in the regular maintenance window. And you are their priority, right? But when you have in-house private cloud, you are one of the 20 things or 20 other applications that's running in the ecosystem. And you are one among the 20. So you're not the priority. They have their own priority, and they're going to tell you when they're going to do what. So that is the difference. So from a versioning point of view, there is really, you know, not not a big change. So if you are in, let's say 23, you can blindly go to 24.1 should take the same window of time.

But again, I think the recent one he's referring is the on prem to cloud, right? It was yeah, it's all on prem to cloud because when you go 26.1, even if you want to do all in-house, I think the cost of maintenance and stuff will go up, but you will not be able to use Generative AI capabilities, any of it, because you have to generate a AI capabilities. And if you're in house, you have to have one instance running on PegaCloud, and then you can then through that you will be leveraging a Generative AI. So you are adding one more hop to your network, and you have to channel through all your calls through that layer. That is the, you know, the con of staying in, you know, keeping it in house. Okay. I hope I answered that question. Can you talk more about this?

Yeah, sure. We'll meet at the booth also. We have you can come to our booth. Booth. 20. The next slide. We are going to talk about a Templatized version also. So maybe that will sync much with your question. And that doesn't take what is under the condition. It is like the practical example of how we can do that. And for the non native right you'll always have non native situation right. There is one mainframe running or there is a some other Cots product that's running right. That is pretty, pretty much non-native as a Non-cloud native. So there you do have. You can do your work by yourself. Or if we are engaged, we can talk about Infosys. We have a application modernization platform that does the work for you where you take your, uh, this is my source system. I want to make these, uh, you know, code cloud native and it will translate that to it will give the Pega APIs that you can install and you can use it.

So it kind of makes your transition faster at a lower cost. So you can, you can it's more realistic. And yeah. Sorry. Yeah, sure. Sorry. So. So the question is how long will it take to make do an upgrade. It has you have I mean I can tell you like X days, right. But you have to take into. If there is any question, if you can come to the mic, it needs to be. Everybody, just. In case. Sorry I asked. I did not ask that. So you have to take all the different variables in aspect. If you are only running one application, that's great. If you have ten applications running in one instance, that's 111 kind of story. If you have ten applications running in ten instances, it has a timeline, right? So it can be one single phase or it can be I have done one single phase all lift and shift within a four month window.

Right. And I have also done three, three phases with segregating three different instances, right. And in a nine month window. So that's the thing. Yeah. Go ahead. The mic if you. Can, just to add right holistically when we are building up the roadmap, right, it is looking at around 17 to 20 weeks of duration. That includes your hypercare and support. So that's where we are going to. So before the next question, can I just be the last line if you don't mind? CTA connectivity, if you're using a call center application, right, the CTA come into play. Now CTA has its own roadmap. AM I on the Pega old CTI layer or I'm using Pega the Citi AI Cloud. Like if you take Genesis Amazon, they are cloud solutions. They are much more robust, easy to configure, and much simpler than to use versus the Pega, you know, layer solution, which is more a soft phone that runs on a desktop.

And then you have to, you know, go through the back end layer. Yeah. So now I take some questions. Thank you. Yeah, yeah. That's the mic. So a couple of questions. Yeah. This is Krishna from empower. So I have a couple of questions. So one is do you have any metrics to justify the cost that a customer is going to benefit by moving to the cloud? And they also have second concerns with respect to the data security, because these two primary concerns, every customer wanted to have the opinion or answers before moving to the PegaCloud the. Second, I didn't quite get the second one. So one is basically, do you have any cost metrics to justify OK. Whether it will go. And second is a data security move to security. Data security. Okay, okay. Thank you. And the second one is right now you just discuss only about moving Pega to a Cloud.

Correct. But your overall process has other ecosystems, right? Your internal integrations to the systems. Right. So do we have to do any POC because you may have other applications, right? Other your system of records, we just need to integrate. Correct. So you could have firewall issues. Everything right. We first have to ensure that, okay, we resolve those before even planning those roadmaps. Right. So what are the strategy for that one. You want to take that. Go ahead. Yeah. So the first one you know what is the benefit of going to cloud comes with what your roadmap is. Right? And I mean is the cost justified to run the Pega in-house. Right. That is a that's more a CIO level kind of decision, right. So does the organization need to continue to keep the infrastructure maintained in first run? Most of them are five years ago, if you ask, you get a different answer.

But if you start now with all this agentic transition happening. Most of them are now actually trying to move their applications to cloud, even integration layer. They are moving to the cloud cloud equivalent, right? So and that is you cannot just take from Pega point of view, from Pega point of view, take, you are already now positioning yourself for Constellation UI, right? You're moving from a, just a standard web based APIs to APIs where the exposure is easy. If you have that interplay, all these variables that you have to take into account. And then the aspect of, you know, do I need to GenAI? What is the cost of using Pega capabilities versus using an in-house, you know, enterprise? GenAI. I think we had the answer this morning. So you have to take the token cost now into, you know, so so that will be your, you know, that's where you it's purely business to business case to case, application to application.

But yes. Yeah. Correct. Yeah. Yeah. Yeah. But if you have a multiple application, we have this slide which talks about a wipe tool where we can put your specific business case and get the answers for you if you work with us, right. You stop at route 20. We will go through that. As a practical answer. There are savings. We have seen the infra cost. We have seen the amount of to and fro between the multiple operational teams that has reduced. Right? So definitely there is a saving. But then, uh, where does the Pega license cost come into picture? Because you'll have to club the whole package. Right. But still we have seen it is it's a beneficial number. Numbers can't be disclosed. But yeah. Yeah. From the data security question, there's two two aspects of it. Right. One is during migration. Right. So what does Pega connects your system.

Because by then you already have a direct connect or a, you know, you know, a VPN depending on again, your implementation mostly I've done started with for to do the POC like you brought up, right? Like a simple POC connectivity through a private VPN and then switched to a direct connect. But let's say your whole ecosystem is already on Cloud your only Pega you're bringing Pega, then you can just use, you know, you can be just good with VPN if you're not, if not taking a large direct connect and then you can make your rest of them using Transit gateway, they talk directly. They don't have to come to your Fi or your, your firewall, right? They can interact directly with each other. Right? So, so it depends again, on case to case, you know, you take those aspects into, you know, so. Sorry, before I just take the next question, I just want to spend 10s maybe that might have an answer.

So just. The encryption. Other things are Pega does in each layer. If you're going AWS or Google, they provide their layer on top of that, the APIs that we provide, the application layer, we focus on TLS, you know, Saml based federated identity. So these are your. And like AWS says, right on the mantra is minimum give less, right? Start with less at the application layer. Yeah. Sorry. You had a question I know you're waiting for. I think you were talking mostly like in-house. Cloud to PegaCloud upgrade, right? Not PegaCloud to PegaCloud upgrade. No. In this case. Yeah. Why would. I don't know what the case cannot. Know in our situation. The reason I'm asking is there will be two scenarios, right? In house to PegaCloud and PegaCloud to PegaCloud upgrade will also happen. You mean within the PegaCloud application uplift, right? Yeah. Okay. Thank you.

Already we are in PegaCloud. We will move from 23 dot x to 25 dot x. Both on Cloud. Yeah, both on Cloud Cloud. Yeah. So in that situation, do. Do you guys had any experience like PegaCloud to PegaCloud. Yes. So that's very good. So once you're on PegaCloud. Right, what you should have and what I suggest you do is have your main dot upgrades as a maintenance releases part of your scrum. Don't wait for a, you know, like a ceremony to do your upgrade anymore. Make it as a dot, dot upgrades. Right. And that will come with, you know, if you have a good automated testing in place regression testing, because that should be enough for you as long as you're not moving. You know, when I go from 25.1 to, let's say 26 tomorrow, right, or 24, I'm already on 24. I want to move to 25.1.

Now, if your, if your, if your UI is not changed, if if moving from UI kit to, let's say you're on UI kit as well, right? You're not moving from UI kit to Constellation UI, then it should be simply like a two scrum, you know, and then third by third sprint, you should be able to go go live. And I don't think you also covered the pre upgrade tool running. And what is the customizations and all of that. Because part of our planning okay. During the planning exercise, those are the things that we pre-run. And we consolidate that and we run through and validate with all of the teams, right? Whoever is the key responsible from an integration perspective. Right. And the third question I have is when you did this upgrades, uh, like, did you face any customization issues And how did you overcome that?

Great question actually. So most of the customization where I saw not much in Pega, in Pega, and mostly it was RDB Sqls and, you know, Java based functions. So we had to plan that for APIs. So that is why that integration is the biggest risk that you will add in your assessment phase, which you have to go and look literally, you know, and that is also in the POC phase, right? You don't want to just bring in and engage. You give that, take that four week time, do a small connect and see, okay, what is that? You know, I'm connecting not because what happens in this, the having database in house is a blessing and also not right. Because people go and build things, you know, you don't even it doesn't even go to enterprise architecture. Somebody does a DB link connect, they start writing reports, pulling data you don't even know until you go Cloud oh, where is my data?

Oh, we didn't even know it. You oh, we have been doing this for the last one year, by the way, like, you know, like, so no record of it, right? I have faced that situation too. And, you know, I'm just. And then we had in the last minute, we had to do a big, big Bics processing for them, right? I had to had to work it through because we had to go live. Right. That's holding us now, right? It was like, you know, nobody knew. Right. So what do you do? You faced any issues like with the users when you. Know, because that part is all nailed out now at this point, right. If I if you ask that question two years ago, I would've given a different answer. So now it's the so is so, you know, like, like, you know, it's like used so heavily that it's.

That's not the reason I'm asking that question is because Pega is changing their out of the box rules in every version. And if you save as those rules into your application version, that is causing impacts in the upgrade. So we observed that. So that's. Okay. Yeah. We can discuss that use case if you want to come to the booth. I just need to know a little bit more. You know, uh, the other aspect I have also will join me is my other other copartner. The landing. Place and part of the initial distribution system to. Come to the. Assessment phase. Those rules are identified and then those are taken into account. Not just that like, you know, all the customizations because, uh, all our clients, you know, what we have seen is, uh, they started with Pega six, they went to seven, they went to eight, then Infinity, you know, onwards.

So they will have some rule somewhere sitting, hiding behind the scenes, which will break when we migrate. So unless you have done the modernization altogether at one go and you are already on Infinity and you are good to go, then it's okay. But you kept on migrating. You have built a stack of, you know, Legacy in your Pega application, and you have to do a proper discovery, assess it, and then, you know, plan for migration and remove that customization. And we'll take more questions at booth. Yeah. So we're running out of time. So I'll just take the last 20s and then we'll take your questions sir for sure. So the one that I was referencing was this is the Infosys Topaz platforms, uh, runbook, wherein we try to prompt it and we try to ask and get it, get the entire runbook created for the migration, which gave us this.

And it also gave the detail of the Gantt, how it can execute all of the migration phases, all of the value adds, and multiple other things. We would like to discuss more. If anybody is interested, please do come to us, our booth, and we can show this in live. Uh, that would give a good picture. Sir, you had a question? Yeah. Thanks. So did you migrate multiple applications in one RTL Okay. And then when you were going through your your migration, how did you manage ongoing application changes and deployments during the migration? I assume you probably took a baseline code at some point, deployed it into PegaCloud, started testing for the migration and any and any remediation that you had to do. And then as you were developing, how did you manage that as you went through the migration? So unfortunately, we have only one minute to answer.

I'll try. I'll do my best to answer in one minute. So basically, I'm assuming all those applications are running a single instance of Pega. Right. So okay, that's good because I had that. So but yeah, so you have to make sure in that four month window that we're talking about, right? Or the eight month window, you are facing it. If you have, if you are all running in one instance, you want to do all of them in one shot, right? So in that window, you will have to take. That's why I said the. Talking to your stakeholders is important. Understanding what time to market releases they have, right? You want to do that assessment to avoid too much of, you know, you know, like code movement and then limit to a window where you can manage it because you will have to stream, like you said, you have to baseline the code and everything that's done has to be deployed here.

And that has to be that four week window where you want to negotiate, where you can not have a release and test it out. Everything in a new platform, this is just makes your life easy post. Go live, right? If you don't do that, if something shows up, your war room is like running for two weeks now, right? So what you didn't spend upfront, you're spending later and that later part can be much more expensive because it comes with escalations. It comes with a lot of other noise you have to deal with. Right? Yeah. I think we are good. So thank you so much for attending. And if you guys have any other questions, we'll be available in our booth of Infosys. Please come and visit us at the Innovation Hub. Thank you, thank you.