PegaWorld 2025: Prime Therapeutics: Maximizing ROI by Migrating to Cloud

PegaWorld 2025: Prime Therapeutics: Maximizing ROI by Migrating to Cloud

We're going to get going. Welcome, everybody this afternoon. Welcome to PegaWorld. Today we're going to you're going to get to learn about an awesome journey that Prime Therapeutics took the journey to Pega Cloud. My name is Eric Ryan. I'm a principal solutions architect. I've been with Pega for about 15 years. Actually, my anniversary is going to be in about five days. I, for those that are interested and maybe are hitting the casino floor, my favorite casino game is Jay Gao.

If anybody likes poker based games, there's one right there poker based games with a little bit of lottery aspect to it. Definitely a game to catch. And my favorite sports team is the Patriots still. But let's see what happens next season. You got Keith. Yep. So I'm Keith Harvego a manager here at Prime Therapeutics. And a couple of weeks I'll have hit 19 years at Prime. Thank you.

The even though I know the odds are not in my favor, my favorite game are slots back home. I live about seven minutes from a casino, so it's something me and my wife can sit down and play together. And my favorite team is the Vikings. Since the Timberwolves kind of left me in a lurch after this season, they did. Hey good afternoon everyone. My name is Hetal Dave. I'm a senior principal architect. Uh, I am with Prime almost around six years by uh, I am basically I love to play roulette. Yesterday I lost a lot of money, so I need to borrow from someone.

So. And my favorite team is Chiefs. Obviously I'm from Kansas, so? So. Great. So we got four things that we're going to go over today with you. First we're going to introduce Prime Therapeutics. We're going to go over Prime's business case for moving to Pega Cloud. We'll go through the migration experience.

This is really going to be the bulk of the presentation today. And then at the last thing is we're going to give. Well, Keith and Hannah are going to give you their five top suggestions when going down the path towards Pega Cloud. So, um, so Keith Prime Therapeutics, you know, has been around, been been around for a while, I think 1998 ish. Somewhere around there. You want to give us just a little bit of background about what Prime is and what they do. Yeah. So we're a PBM out there, which means for most of you, if you get a prescription from your provider or your medical professional, they'll call you and you go to say, a Walgreens, CVS, target, wherever you get those filled. Um, we will basically process that claim and return, tell you what, you get to pay for that, among other medical outcomes.

Um, we've been partnered with Blue Cross Blue Shield. Mainly. We service around 25 million lives now. And as Eric mentioned, we've been around since 1998. We have grown when we acquired Magellan RX in 2022 to over 7000 folks. So really, we're just looking to reimagine pharmacy solutions to provide the care we want for our loved ones out in the industry. Um, yeah. Great. So we kind of know what Prime is.

Why did you go down the path to Pega Cloud? I mean, it was a great decision, I'll say that. But, um, tell us a little bit about why you made that. Yeah. So previously at Prime, we had eight separate licenses, a lot of different amendments. So at budget time, there was just a lot of teams had to come together to understand, you know, the cases, the use cases which licensing folks use. So moving to Pega Cloud also provided us with a mechanism looking at an L.A. that kind of simplified that all into one agreement, which gave us predictable pricing as well as kind of established us and simplified our IT infrastructure. Right.

So previously, like within my teams, I had Pega apps that were running on WebSphere. We also had sat on the VMware Tanzu platform. We had multiple storage arrays. A lot of different database flavors, and we had different teams on different versions. And kind of moving to Pega Cloud now has simplified us onto one stack, right. We're moving to a Postgres database. We're going to, you know, go all in kind of Kubernetes on your infrastructure as a, as a platform. And so yeah, that's kind of our main driving was just to kind of help reduce our complexities and simplify our management of our platforms. So the complexity feels a little bit less a little less today.

A little less stress. A little bit. Yeah. Okay, good. Good. That looks like it would be a highly stressful environment for sure. So let's let's talk about the migration experience that we went through. I mean it's been probably. At least we've been involved with it at least a year and a half, two years.

Others have been involved with it even longer than that. The first thing that we want to do is sort of give you an idea of the applications that were actually migrated, and we're actually still going through it a little bit too, so that hopefully you can see your application up here and maybe relate to what what they went through and start to identify with some of the applications that that went through this journey to move to Pega Cloud. So yeah, so we have a different flavor of applications like, you know, we might be relating some of the applications are business process applications. Some of these applications are business rule engine kind of applications. Some applications are using robotics and some are like is a contact center application which telephony integration. And out of that I think we I think it was a tight timeline. Like within one year we migrated almost 9 or 8 applications into the cloud. And that is, as Keith was mentioning, from the different infrastructure, like running on the Tanzu or WebSphere kind of platforms. So it was definitely a time, time pressure applications.

And like we, we moved those all into the cloud. And P360 wasn't actually one application, right? It was no P360 was in fact three applications altogether. So that's one of the unique combination where like we had three application running, moving to the cloud in one infrastructure. Great, great. And you had a few more actually that went down this path. Provided credentialing. We had benefits coverage MNCs translate seems like all relatively smaller applications from that perspective, like 100 users, five integrations. But, but but it's still going right.

I mean, we yeah, we've still got a big one coming down the path. We have a couple of applications coming, which is one of the biggest application like core and single index, which has a lot of integrations. And when I say integrations is like connecting through the network, like Privatelink connectivity to the on premise integration. So 97 integrations to that on Pega Cloud. Can you? Oh yeah, that's a lot. Absolutely. That's a lot. What were some of the integrations that you were integrating there?

I mean, 97 is a really high amount. Anybody in the audience have contact centers? Yeah. Okay. Um, can you give us an idea of sort of what some of the integrations were that makes it 97? Oh, so, yeah, some of these integrations are like standard integration, which is a Rest based integrations or, you know, and one of the I think I would like to point out one of the challenges or basically, you know, some of the points, uh, lesson learned, kind of which was like whenever we had a connect, uh, file related or whenever you have any integration relating to the file or ftps. There are some security considerations. Keep in mind because that's where we have some challenges and Pega team help us to, you know, overcome those challenges. Yes.

And core it looks like it's scheduled to possibly go soon. So, you know, let's keep going. So, um, we what you're seeing here is that the basic representation of the journey that crime took, it's similar to what a lot of, um, Pega clients take, the journey that they take to get the Pega Cloud. So we want to kind of go through this with you, to give you a sense of what were the challenges, what are the things that Prime with their partners, Pega went through to get to the the outcome that they were looking for when getting 12 applications onto Pega Cloud? I'm going to take the first part just because, um, I assisted in some of the planning along with other colleagues of mine at Pega and Typically. So the deal had been going on for a while. For a while before this, but inevitably in Pega Cloud was on the list of on the agenda to move to. But inevitably you're going to ask yourself, okay, well, what's the effort it actually takes to get to Pega Cloud? And that's when they reached out to me.

Um, I'm part of the Solution architect team. I focus on helping clients understand what the efforts are going to take to actually get to Pega Cloud. And we went through an assessment for migrating typically, but I'd say over two years ago, this used to be a fee based assessment out of our consulting organization. And then with the initiative and the push for Pega Cloud, we turned it into a no fee offering. So out of my team, we do these assessments. They're rapid assessments that we try to get through really quick and give you a good understanding of what what it takes to get to Pega Cloud. These are essentially the steps we went through. The timing was interesting for this one. I mean, I, we were looking to, to to complete the deal within two months when, when it came to me.

So I had a really short window to complete this. So we didn't exactly do a visioning session. But sometimes we do a visioning session, sort of get an understanding of what the what the vision is, what it's going to look like, the applications once it gets on the Pega Cloud we did do a decent technical assessment, went through all the different applications we run a tool called the Cloud Readiness Tool, generates out some great output for us to understand areas in the application that may need to be addressed or remediated for getting up to Pega Cloud. So we ran that. We went through a functional assessment where we kind of understood a lot of discussions back and forth for this, the connectivity that was necessary, what the environments were going to look like for all, all 12 applications and, and then also any other things sort of surrounding the application, like data imports. Uh, what data import certificates. There's a bunch of things that aren't rule based. For those that do do Pega development that we need to understand to make sure it fits into Pega Cloud. So we did that, and at the end we gave an assessment.

We gave a readout so they could understand exactly what it would need to take. Me and a couple of other colleagues sort of gave a project estimate, and we started defining what the actual schedule would look like to do that. So in the end, we delivered this. The deal closed right around the time that it was supposed to. And at that point we were sort of off and running. Just to give you a sense of some of the artifacts that were generated out of this, this is an environments plan. So we actually went through the all the environments and what they look like today, uh, the SDLC, what the stack is dev test, QA, production. And we mapped it to what it would be on Pega Cloud. We took into account the app profiles, the SDLC practices.

But but time constraints is probably the biggest factor here. So in the end we were just pretty much went like for like in terms of what they had on premise is what we did on Pega Cloud. And at the bottom is the actual environment structure. The great thing is you had a standard environment structure. You had the the five environments, right for for running the SDLC. We did have one contact center that had a training environment. And then we defined the connectivity. This is sort of an example. We've actually updated the layout and the format of this.

But but I want to show some true artifacts no matter what time they were done. This defined the connectivity what's on, what was on prime side, what was on Pega Cloud side and how the connectivity was was going to work. And Heather was going to talk a little bit more about this as we as we move forward. Yeah. So did the assessment. And, um, they'll close day one right the day after we're off and running and uh, yes, a little bit about how we got started. Yeah. So I think I would like to just point out on the connecting side, like because that's that. Basically there are two different teams collaboration.

Like on the Pega side, we have to work with the support as well as on on basically premises. We have our own IT infrastructure team. We need to collaborate and basically make sure that that timeline align with each and every connectivity setup. Especially like our in our particular setup, we are going through the private link connectivity and security wise it's not exposed to the public. So we have a separate separate specification for from the security to implement. So and especially I would like to point out is like like when you are opening a Cloud change request on the Pega side to set up some connectivity, there are some SLAs and you need to assign basically a line those SLAs with the following request on on premises tickets or requests for the establish the connectivity. So just make sure you plan accordingly to uh Basically have sufficient time to implement that kind of privately connected. I imagine things like HIPAA come into play with connectivity, some serious security. Yes, indeed.

It's like some or all of the application has a Phi or PII data, which we need to make sure that it's not exposed to any unauthorized or over the internet or anywhere else. So it's like our security requirements are is never be exposed. You have to go through that privatelink connectivity to access any of the data. And then continuing the journey, we've you know, after connectivity we continue down. And yeah, so what we also ran into is you'll see with a lot of the boxes on the page. Right is we had a pretty aggressive timeline on this. So from the time we signed the contract we were coming into a renewal with VMware, Broadcom on our Tanzu platform where a lot of the applications were hosted. So we really had a deadline. Every year, Prime goes into what we call our peak season in November, where we try to kind of code freeze and not move things.

So the bulk of these apps had to not only move off of our Tanzu platform on the within Prime, but also get to the cloud before November, if possible, to not disrupt things. So going through this and setting our schedule, you know, internally, we were running a lot of these kind of through sprints and things. Um, talking with Pega, they kind of run more in a waterfall. So working with our implementation team, we did kind of land on a waterfall approach, um, through this, that just kind of helped with the ticketing, right? We had hundreds of tickets, not only internally, but as Hegel pointed out with Pega, that we had to constantly open, um, and we were struggling, to be honest, to keep up with those tickets. So that's one thing that we did leverage the Pega team to help us with was to manage those tickets. Um, we built just a really detailed migration plan with them. Right. What did Pega need to do?

What do we need to do? How did we get those tickets going? Um, so there's just a lot of pieces in here as you go through this journey to keep in mind. I think, I mean, the timelines were pretty aggressive, thinking like August, what do we suppose that, like maybe February? Yeah, we've closed right around March, April. And then we we had to move as quickly as possible by August. But we ended up we ended up extending that right. Yes. Yeah.

We did end up moving some just into the November early December time frame. I remember um, I think it was the PDL. So we had a project delivery leader on that, which was great. And you know, if I could recommend anything, definitely have a PDL involved in it because, you know, the ability to the close communication and collaboration on that is fantastic. Um, I remember he did some sort of I mean, it was aggressive, 12 different apps, if you can imagine trying to do in what, a four month, five month span. Span of time. Um, which looked okay from one perspective when you look at it app by app. But then I think we did a perspective where we took it by resource. And I think you, you and two of the other people had about 90 tasks you had to complete in one week, which, which kind of changed things a little bit in terms of the timing.

So it was um, I think that I think at some point the realization was, okay, we still need to get what we need to get in by the end of the year so that they could get off. Tanzu. Um, but we've got to be realistic about the times and, and did a little adjustment to the point where I think we were going into was it late November? We had a deployment in December 2nd. We did have two in December that we ended up pushing out. Yep yep yep. So that worked well. Um, can you talk to us a little bit about the testing actually, how did that go in the migration? Yeah.

So we worked with each one of our teams to kind of develop. How were they going to test. So through the migration windows as you migrate. Right as you do. Right. We had a lot of database conversions from SQL server to now we have some come up with DB2 that had to migrate to Postgres on Pega Cloud, and those did require us to take some downtime and some planning. Um, and then to build test plans. Right. So those teams could in turn, um, test the application.

Right. And you got going from particular like to like anymore. Right. You're you're testing locally with everything now you're testing in the cloud with all these different integrations. So we did, you know, asked each team to kind of define their testing plan, go through them. And then the nice thing is, as you're moving through these environments and with your dry runs that Pega will provide to you right before you go live where we can do copies of our production, um, we can get a chance to test and see if something breaks and hopefully go back, repair them and be ready for that. Go live. Great. One thing that kind of struck me in so it wasn't just me, right?

There There's a lot of people at Pega that were doing this. I interviewed a few of them. Um, I'm just sort of up here representing it. The the collaboration. So I think at the beginning, you know, we started down a path. It was somewhat somewhat vendor client oriented. But I think we, you know, there was sort of an epiphany around collaboration that sort of happened to the to the point where I don't know where attending each other's birthdays and birthday parties and stuff at this point. But can you talk a little bit about how the collaboration evolved and what went on there? Yeah.

So the nice thing is, through our whole journey, we did have the same team. Um, so we did it. To your point, we got to really know those folks and they did. You know, you get to know them not only the to build the partnership. You did kind of start to get to know them on a personal level. Um, Brant, who was, you know, kind of along the journey with me from the Pega side, we spent a couple of nights all night chatting on teams or on the phone. And, you know, when you're trying to kill time as things are being moved, you start to chat along the way about a lot of different stuff. But yeah, we did build this collaboration with those teams in the partnership to get this journey done because for us, we knew everything from how we ran on within our data centers. We didn't know how this was all going to run on Pega Cloud.

Right. And how those things were going to change. It's you're so used to in some cases of, you know, phoning a friend per se, because you talk to them on teams. You know, you could, you know, if you're in the office, go tap that person on the shoulder. We really had to get to know these folks and these teams, because we had to rely on them when we put a ticket in. And a lot of times we escalated a lot of tickets, right? Just because we would, um, needed something. And Pega had SLAs. And so it was a collaboration and a good partnership that we built over this.

Yeah. Do you think you could have gotten it done without that type of collaboration? No. There's just so much that we didn't know. And again, there's things that we couldn't do, right? So we had to partner with with Pega to get access to those as well as we had challenges afterwards of moving DNS entries. We had to work because we had to keep the same names, the same logins, um, because we had external clients and folks that we did not want to try to impact and have them do a completely different type of login, if we could, you know, prevent it. Absolutely, absolutely. Um, I think I think at this point we do almost like daily meetings, only daily stand ups, a couple of two project oriented, you know, progress meetings per week.

So again, we've still got another app that's that's going at this point. So it's um, you know, continues to be a very close collaboration. Uh, when it came to actually, you know, the dry runs and the database migrations and those types of things. So you just talk a little bit about the, the experience there and kind of how you approached that piece of the migration. Yeah. So I'll start. So we we were lucky enough to be able to make for most of our dry ones, copies of our databases, um, and have Pega connect to those to kind of do an assessment, do the poll um, give us pre timings um, of those migrations. We and we did have challenges there a little bit. Um, we had some applications which are by our contact center and our one coming up for core where they're basically used 24 over seven.

And those apps were on the larger side and we needed to accommodate. But, you know, multiple hours of downtime. And we've got some gracious product owners who have worked with us and are still working with us to make those happen. Um, but it did give us a real good chance to see if there was going to be issues. The other thing we've done with some of them are apps on based on tiering is we're putting them both on, say, a single stack. So they're sharing stacks, sharing resources, sharing the database. So those dry runs became really important because we did have to look at conflicts and merging databases and rules, and we had to make sure there was, you know, those things and the dry runs, those really did help us sort those issues out before go live. Fantastic. Um, anything else about the journey that you guys?

I just want to add like one thing on the dry run or basically merging multiple applications, running on the on premise and merging to the one stack onto the cloud. Right. In that situation, probably you might run into the conflict. Just we need to the dry run gives us like ahead of the time visibility on those kind of stuff. So you can prep for what's coming in your way and like, you can make sure you have a mitigation plan ready when you are going live. So maybe you could talk a little bit about, you know, it was definitely it's been a journey. It's been quite a journey. Um, I can't imagine that best practices don't come out learnings of this and it can be different, you know, one client to the other. So.

recommendations. Yeah. So we'll start kind of with partnerships right. So this you know we really, as we pointed out, built that partnership with Pega and that migration team. But it's also about building those partnerships internally too. Um, you know you need to make sure that early on, right? You bring your product owners, your application developers, folks alongside of Pega, get those folks integrated together, um, to get them to know everybody. Um, it's something that we're still continuing to do. And, you know, you can always do a better job of building those partnerships and keep them fostering and moving forward.

So that's one of the recommendations I have, is just make sure from the beginning of your journey that you've got the right people. You know, we've had to tap our internal security teams, network teams, database teams, developers. There's a lot of people when you're taking this from your internal systems to the cloud, that you need to make sure are all on board and with you on this journey and are and are ready for it. And then when it comes to upgrades, we you know, as I said, we had multiple versions. Um, you know, from 7 to 8, uh, within our own infrastructure that we needed. And we had decided to standardize on, uh, Pega 23 when we were going to the cloud. Um, as we looked before, uh, PCR was an application that was built from the ground up on 24, um, and that. Was built on Constellation. That was built on Constellation.

So that was a little plug. That was plug. But we decided at the time to do our upgrades, um, on prem before we migrated to the cloud. But Pega certainly, um, as they recommend to us, they can do the migrations as you're moving as well so they can help uplift it. Um, for us, it made sense to do on prem first so we could do version testing as well as as I talked before, we had some tight outage windows that we needed to try to minimize, and so we wanted to keep that outage window small enough that we didn't have to take the time to do the upgrades on the fly as we moved, but that was our recommendation there, if you can. And when you look at these things, if you can make sure that you're upgraded, it just sometimes will simplify your journey as you move forward. And this next one testing. I can't emphasize enough. Test everything as much as possible.

If you think it is small, test it. Um, we from being on prem, we had a lot of access to things. For example, we used an SMTP gate for our internal email communication. But moving to Pega Cloud and having to be able to talk from their AWS tenant back to our Microsoft 365 tenant, we are having to move our applications to the graph API, which unbeknownst to us, the teams did a great job of testing and we tested email functionality. But we ran into an unknown on the Microsoft side with attachments. Um, we also had to work with Pega because of the way that inline attachments were working. Didn't quite fit, and we didn't find that until late in the game. On testing, even though we had tested emails, we just had some scenarios that we had, you know, hadn't quite completely tested. So I will just say test, test and test again, and I'm sure it'll probably has a few things on testing.

Yeah, I think that's I agree with you. Like even though, you know all the use case has been validated, just retry, retest, keep testing, make sure you cover each and every scenarios you have possible. So I think yeah I would 100% agree that test test test is definitely one of the strategy I would do. And up here I have listed document new processes. So for us again being on prem, if a team was deploying something we had something that would come up right. You can go tap your favorite DBA on the shoulder and you can say, hey, I need to run this query. Build this index. When you move into Pega Cloud, there are things that you no longer directly access, right? Databases are one of them.

Pega is protecting their making sure your systems are up as much as possible. So you can't just go and add something to the production database. You can't directly query those out of a certain context. You can't make updates. Um, all of that stuff document new processes because there are SLAs that Pega has in order to meet those things. So, um, you know, we had one of our first implementations. We hadn't really thought all the way through this. And I got a call from one of the developers because, yeah, we realized there was a four hour SLA from Pega to get that ticket processed. So, you know, Pega was great and gracious and helped us escalate and got the work done for us.

But there's just new things that if you're used to hosting this with your own data center that are going to change and just as much and I call it eating my own dog food. We personally didn't do a great job sometimes of documenting all those new things and getting that word out there. So a recommendation is get out ahead as you come across these things that you're used to owning and completely owning in your own house. Just document them so you know and can let your partners and app teams know that, hey, this is going to change. I don't have control over this anymore, but that is the journey we are making, right? We are partnering with Pega to, you know, provide the uptime, provide certain level of patching things that we used to have to take care of that we no longer need to do. And then the detailed migration plan. So, you know, Pega has a very succinct plan of how they do these things. And they've been very good.

Right. They will share that with the dry runs. You'll get a run book and those things that'll show you those. But my suggestion, make sure you take those, get them out to your app teams so that you can, you know, add things that need to be done before Pega takes over the migration as well as the Post-migration steps. We're lucky enough that we have our team that I manage that does our Pega Platform for the PaaS. Um, so, you know, if you're kind of, ah, mixed or your development teams are taking care of some of that, but we needed to document processes. We had to do as far as updating DNS and things before we even turned it over to the app teams. And putting that together in that detailed migration plan will just make it go smooth. Um, especially if, you know, in our case for our one application, our unity app, where it was a, you know, a 17 hour migration by the time we were done because of all the larger factors and stuff.

Keeping track of that, because I was sitting up on night on teams working with Pega, you know, pinging back and forth what steps they were on, keeping those things up. So it was easy for us in some of those cases to keep track of where we were in the in the plan. Great. Yeah, some great recommendations. I can attest that, you know, these are tried and true recommendations to take forward in your own your own migrations. I'm going to close it up with just a couple of recommendations here. If you want to get more details about Pega Cloud, here's a few booths that you can. If you want to take a screenshot of it or a picture of it, you've got the accelerate to Pega as a service experience, right? This provides information on upgrading to Pega as a service.

Features, migration best practices. There's expert consultants there and they can talk to you about real world scenarios in addition to what you just heard today, and go through the step by step walkthrough. If you've got any other questions on that, we've got Operational Excellence Ones Model and Pega Cloud that talks about our global operations center and all the great stuff that it does. We call it the gawk internally at Pega. It's what we're using to monitor the systems, keep them healthy, keep them running, and information about things like my Pega Cloud, the self-service portal that you that you get when you move to Pega Cloud and then Pega Cloud exclusive services. This is sort of a product focused booth, showcases some cloud only services that are available to you, like enhanced disaster recovery and some other detailed information on the product. So, uh, we're supposed to get this done in about 30 minutes, leave time for questions. We're a minute over. So I think we did a pretty good job.

If we want to open it up for questions, feel free to stand up to the microphone and ask any questions that you might have. There we go. I was going to have to dip into my questions, but. I. Was hoping I'd have another moment to formulate my questions properly. But, um, when you do this, the switch, because you've done. Can you move a little bit closer to the mic, please? Thanks. I want to get it on the recording stop.

Better? Maybe. Fantastic. I feel like I need to see you. Um, obviously you've switched one application at a time that somewhat answers one of the questions I had coming in here. But when you did the switchover, did you typically shut down the old one and threw everyone out and kicked everyone over? Or did you do a smooth approach, or did you have different approaches for different apps? Yes. So I'll take.

That. Yeah. Perfect. Um, so yeah, so we did shut the applications down completely. So part of the plan with Pega is, is they want everything shut down before they start the migration. That way, because they are reading from your production database and pulling that data and rules and everything runtime. They do not want folks in the application that could make changes and things. So we did shut them down completely. And that's why we we had to plan around maintenance windows as much as we could.

And and like I said before, we had to work with some of our partners to extend some of those outage and maintenance windows to make it work. Awesome. Thank you very much. Yep. There are some edge cases where we try to come up with, um, I would say fancier ways of cutting over. But in general, yeah, we do like to do a clean cut over. It's easier for everybody. Um, if you could just say your name and sort of where you're from. I'm Ashutosh.

You can call me Ashu. And my question is related to the different version of Pega which were there. Pega seven eight. Whatever you mentioned, only one application was on Constellation. So for that particular migration, did you do the upgrade and post that upgrade? You got it done by the application owners and then you move to the final cloud version. Yeah I would take that one. So yes. So what we did is like all the applications we moved to the standard Infinity 24 or 23, you know, before we migrate to the cloud.

And then we perform the UAT on prem exit and then we migrate to the Pega Cloud. We perform the same Uart script onto the Cloud to just compare side by side results. And one more question. How is Pega specific Cloud migration different from other usual custom application migration? I think one thing I would say like especially like we got a support from the Pega definitely. Right. It wasn't basically that will make our journey very easy when Pega is helping us along with our application partners, you know? So frankly speaking, for our migration journey was very easy because of the help from the Pega team. Thank you.

When you say custom migration, do you mean migrating? Like internally? Not like not Pega Cloud. Yeah. So Pega is a Platform, and Pega has been a Platform all the time. Sometimes people move Microsoft full stack code Java code. So I was trying to correlate these two parts. Okay, great. So I can.

Yeah. So I used to manage the team that had our Tanzu platform. And we recently as part of our cloud journey, as we moved away from that, we did applications there that did move from the Tanzu hosted application into our GCP, um, implementation. So it's a much different journey, I'll say from that. Right again is we're using the Pega platform, which kept it simplistic. When I look at those applications that migrated in the last year, those were running in a platform that was called Taz. That was the Tanzu application service that were spring boot applications. And they did have a lot more complications in trying to figure out versioning. Sprint, you know, versions of springs, different integrations and stuff, and a lot of that.

We were simplified. And when we moved to Pega Cloud taking a Pega app, because a lot of that was already solved for us by Pega. Thank you. Thank you for the overview. I'm Rajeev Vaswani from Blue Shield of California. We are in the midst of our Pega cloud migration. So a couple of questions. One, the connectivity between Pega I was at AWS or GCP. Um, two Prime.

How did you execute that? Was it like through providers like Megaport, Equinix, some secure connectivity. And second, once you migrated, did you change your team's skill set to more DevOps to manage now? Pega in the cloud. So connectivity was, as I mentioned, that we we go through the private link using the PVC like private cloud virtual cloud connectivity where we where we have the VPC endpoint from the Pega hosted cloud versus the on prem applications. Right. And then we match those two through the private link. So we are using the standard AWS connectivity pattern. Okay.

And did you use like a provider for that or just the private. Public internet for the connectivity. We don't have public internet. It's just a private connectivity between the two AWS instances. Okay. And we had a you needed some some deeper connectivity controls on that I remember. So do you want to talk a little bit about that. I think it was especially on the later later migrations where we need to lower environments and stuff. Yeah.

Oh yeah. So one thing we did do with our security team and sorry, I only have a second part of your question that I was going to get back to there too. But one of the things we did have to do is our security did dictate that our production environments couldn't talk to our non-prod environments. Um, so somebody couldn't access, you know, production to non-prod visors. We had to work with Pega to implement that as a whitelisting between our stacks. We also recently had come into where we needed private connectivity between our stacks. Because even those technically were traversing the public internet. So we've been working closely with Pega to get those tickets open, and they've been a great partner in helping to come up with a solution so that we can do this stack to stack communication. And I apologize, the second half.

The second was more just how did your team skill set change once Pega was in the cloud? More DevOps oriented as compared to maybe just on prem? Yeah. So I'll say that we're still evolving. Um, so from previously before, right. I have three folks in my team with James and Nick that supported the Tanzu Kubernetes on prem. So now they don't necessarily have to do the day to day care feeding watching right of that platform. Um, and as we grow, as we get past these final migrations, right, we'll start to focus more on, you know, what's roadmapping in the future on some of these versions, um, kind of help implement better ways of monitoring solutioning. So yeah, our skill sets are changing more from hands on day to day work to more of how can we be better partners to our application teams and support them and keep the platform, you know, to the best of their ability as they move forward.

Thank you. Yep. My name is Pat McGurk from Holiday Inn Club Vacations. My question is. Related to the title of. This. What has been your ROI? Have you seen it? Has it been realized?

And what does that look like? So so far, I'll say we we haven't officially seen the ROI has been pretty net neutral for right now. Like we worked with our Pega team and a lot of these things to keep the cost pretty similar. Um, and initially we probably saw a little bit of an uptick because we were paying for Pega Cloud while we were still paying for a lot of these other platforms. And again, we are still some of these platforms. We haven't officially fully retired, so we will see more of an ROI as we no longer have to license a WebSphere or some of our SQL server DB2 we did get rid of at the end of last year, like our tanzu costs. So our ROI really has been in kind of shifting right from the one platform to the other. But it really, I think will come up probably here in year two. More have seen a true ROI on this, on this movement and should see a positive benefit.

Any other questions? So we got five minutes left. Great. Well, are you coming up okay. Hi, this is Sunil from Bank of America. You speak louder. Yeah, yeah. Can you hear me? Yep, yep.

So when you migrate to the Pega Cloud, do you have any performance testing done? And also, do you have any performance testing tools provided by Pega or do you have your own tools around that? So yes. So when we migrated to Pega, right? We performed the performance test during because Dry Run is the one that's going to help us to run the performance test, because you are migrating your production data to the cloud at that point during the dry run, and use that environment to run through the performance testing. So that's why you get the real, uh, real performance results from your production environment kind of stuff. But to kind of go to the question is, we had our application teams already had some performance testing, right internally that they were using. We didn't have a tool provided by Pega. What we did get, though, from our Pega team is they did provide us with a person to keep keep an eye.

When we are running those performance tests, they keep an eye on the back end of the systems looking to see, hey, did we see spikes? Did we see that we needed to autoscale or, you know, downscale? What's the performance looking afterwards? But yeah, those parts we are providing our own testing tools and our own setups. Okay. Another question I have around is data inbound coming in. So let's say if you wanted for your data analytics reports, what are the patterns you use to get the data inbound from the Pega cloud to your on prem? So going backwards from Pega Cloud back on prem. So for most of those we've had to utilize our private link right.

So we worked with our network team to get that private service connect between the two. So we've been using SftP through theirs. We've also used some of our APIs through our Wso2 platform. You probably have some other ways we've moved data. We also have the direct link connect private link connectivity with the database. Example is like extracting directly to on prem databases. So there are a couple of patterns like one is direct database, another is file generation through SftP. Okay. So direct database is also you don't have any performance issues when you have the direct.

So far we haven't experienced any performance issue. Okay. Last question is around patching. Is it seamless. The patching is seamless because there is patching around. because if you are using either GCP or AWS, there is a patching around that. There is patching around Pega Cloud. I mean, Pega Platform so is are you getting those notifications about patching? And also do you experience any downtimes I mean, during that patching, is it seamless?

Yeah. So Pega will provide it. Um, basically as a zero downtimes. Um, now does this always work out perfectly? No. So I'll be honest with that part of it. Um, but yes. So from a standpoint of Pega takes care of like recently, we just got a notification through our ticketing system in Pega, the, our portal that they needed to patch a patchy vulnerability. Um, they would just go ahead.

And we had we were able to schedule those, you were able to look at those and push them, I think up to what, two weeks in a window? Um, and then if you need them longer, you can work with Pega. But those pretty much the infrastructure patching has been pretty seamless. Um, with the Pega upgrades or Pega patches, right? They do have to do the restart, so you do want to plan for it is a rolling restart through your web pods various stuff, so it should be zero downtime. Um, we've had some instances where unfortunately, right, we've seen a few hiccups due to some interconnectivity with some other systems and things that we've had to plan for. But I'd say for the most part they are seamless upgrades with very little to no downtime. Thank you. Yep.

We got about a minute or two left. Yes. Hello Oscar here. So with the downtime, did you get the help you needed by by then? And what's the availability of your application? What is the demand on your uptime. So how did you solve that with Pega with the downtown downtime that you got. Like during the migration. Or.

Yeah, for example, if they upgrade your platform and something goes down, how do you solve that to your customers? So we have set up alongside Pega has been really good about, right? We gave them our SLAs, right? So we set our SLAs on Pega Cloud to be the most restrictive we have today on our on prem systems. So they don't perform any maintenance or patching until our downtime. Windows, which typically are 10 p.m. to 5 a.m. so they only are supposed to provide or touch the systems during that time. There are times when we've hit unhealthy pods and certain things that have caused restarts.

Middle of the day, things you can't just avoid with Kubernetes that are going to happen, but all your other maintenance you can work with Pega to set the the maintenance windows and things for application. So if there is downtime, it should happen within your defined SLA windows. Okay. Yes. Thank you. Thank you. Well thank you everyone. Hopefully you know, having everything that you heard today get you some some confidence and excitement about migrating to Pega Cloud if that is on your agenda and plan. So thank you Keith.

Appreciate it.