Migrating away from your current Identity Provisioning solution

Good afternoon, ladies and gentlemen, welcome to our equipping, a cold webinar migrating away from your current identity provisioning solution. Understanding your options, set the foundation for your new environment. Choose the right solution. My name is Martin equipping, I'm founder and principal Analyst at equipping a cold in today's webinar.

I will talk about the, the situation a lot of organizations are facing that have identity provisioning solutions, so sort of core identity management place, and they easier have to, to move away from that because due to the end of life of products or whatever, or are they just consider moving away for other reasons. And so the question was, does it make sense? What are the ways to do it? So how to best do it? What I will not do during this webinar is looking at particular vendors, because the question who's the best vendor to migrate to is a sort of a little bit more complex question.

It depends on a lot of factors. And so this is not the scope of this.

However, there will be a new leadership provisioning out soon. During this week, I will talk about this later, during the webinar, before we start some information about keeping a call and about the webinar itself, some housekeeping information. So keeping a call as an Analyst company, we are providing enterprise it research advisory services, decision support, and networking for it. Professionals. We provide us through our research services, through our advisory services and our events research consists of our various reports we are creating.

So grants leadership compass are comparing when there's some particular market segments. When the product reports other types of advisory notes, covering specific topics have trust to look at our website, coming a call.com/reports for our advisory. Through our advisory services, we provide more in depth information for customers for around strategy products and vendor selection, etcetera. And then we have our events aside of our webinars. Our remaining went see upcoming European identity and cloud conference, which will be held again may or teens to 16 in Munich.

It's about our leadership and best practice and digital ID and identity management, cloud security QRC. And we have a very, I think, interesting mix of topics there have a look at the agenda and don't miss the event. It's I would simply say it's a master time. They went here in Europe and you shouldn't miss it. And we have people there from, especially all over the world from us to Taiwan. So a very broad mix of people, okay. Guidelines for the webinar. You are muted centrally, so you don't have to mute around mute yourself. We are controlling these features.

We will record the webinar and the podcast recording will be available tomorrow aside of the podcast recording, we also will provide the, the slide deck as PDF for download so that you can download the slide deck tomorrow. And we will do a Q and a session at the end, but you can add a questions at any time using the go to webinar control panel, there's area questions or lag or whatever, depending on the language version you're using.

And you can use this feature down in the go to webinar control panel to enter your questions so that we can pick up these questions at the end of the webinar, the topic today, as I've said, and it's only one speaker. So it's rather simple structure of the agenda. It's about migrating away from your current, that entity provisioning solution. And there a lot of reasons, some of them are more sort of homegrown or window grow in the sense of, okay, we end the life of this product, whatever, and others are more about the changing landscape in which identity provisioning lifts.

So some of you have attended called webinars might be familiar with this picture. So it's one of my standard slides and my most favorite slides. It's about cloud computing, social computing, mobile computing as computing TRIK. So its three of the major grants, which are really changing the way we do it. And that means that we have to deal with far deployment models with far more and, and different types of users, far systems, etcetera. So the scope of information security is changing and the way we do a lot of things in it is changing.

That also means that we have to think about is sort of our standard approach on, on how we do identity and access management. And how do we do identity provisioning still the right one and this sort of this change the way it is. This also impacts identity, access management and identity access governance. And if you look at a core discipline within identity access management, we are at identity provisioning, there are various other disciplines. So if you look at our research, there's a lot of description on how segments are set up, etcetera.

So there's one, one document, for instance, understanding identity and access management, it's called a scenario which explains depths our review of the various segments within the broader I am IHG. And today, as I said, we will focus on the identity provisioning part, which is around automatically creating accounts for use and various systems, assigning entitlements, Et cetera. So what's really is changing. One of the thing is that governance came into play when we go back some 10 years.

So the entire story was primarily about administrative efficiency right now it's about information security. It's about controls. It's about a lot things in that area, other groups of users. So we not necessarily only have to deal with a few thousand or a few, some sense of 10 of thousand users anymore. We might have millions of customers, cetera. And so also the way we provision and the, the scale of provisioning might definitely change here. We might need to go more into detail regarding what happens in real time.

So we're looking at the activities, reviewing the standard sation, integrate into applications. So externalization of security out of applications, fine print, access control. So where for standards such as CML come into play, there are also some podcasts around X CML, which I think are, are definitely interesting to, to watch. And the other thing is I am is clearly too important now to be a point solutions, key concern, far more than technically tool central part of, of, of what we do in, in overall governance, because a lot of risks in organizations are access risks.

And this is really something which also changes sort of the, the way we look at. I, I, and we have to think about what is the best way to deal with it. So we need to understand this is that we are talking about a critical key capability of it. And when we then look at I permissioning as, as a key element, as I said, it's the part of technology which allows to create accounts. So once you have a new user, you can create this active directory account. You can create some of the other accounts. You can go through that. Then we end up with some questions.

So one question is why to migrate and very, very tightly aligned with the why to migrate question is the question of where to migrate. So before we think about which product to choose, we should think about, should we really do a migration of another anti tool? Some cases there is, there's a simple answer. You have to do it in other situations that might be an answer, which is maybe it's, it's better to do at later point of time. Another important question is than clearly what's to migrate. So show you migrate everything or can you, for instance, my only portions of it, this is interesting.

And that's something I will do have deeper into detail later. For instance, when you have complex host or a mainframe SAP connectivity, etcetera, with a lot of customizations and, and so on, it might be better than to say, okay, I'll leave a product in place and up and running. It's still the better way to do it. On the other hand, license costs and support and other factors might, might demand that you even change your identity provision for these complex target systems when to migrate another important question. So what do you do before? How to prepare for that cetera and where to migrate?

As I've said, I will not look at a particular vendor, not saying, okay, migrate to vendor B or C, but I will look at what are potential architectures to, to, to go ahead for, to where, where to move from where you are. So even while I had why to migrate first, I I'll start with one portion of the weather to migrate, go back to why to migrate. And then again, Western to migrate. So key cost key question here is, and that's really something you should look at very, very, very roughly and, and very sort of for some distance also.

So, so does it really make sense? Which of the reasons mentioned in your organization are compelling? It might be that, that a lot of people say I'm not, not happy. I'm not lucky with that provisioning tool, which in place, however, it might be that the problems are not primarily tool problems, but my, it might be that these problems are more organizational issues around guidelines, processes, etcetera. And so you might end up with the same problems when you use the next tool and a tool not necessarily helps as long as sort of the entire ecosystem and the prerequisites are not there.

So the other questions, what are the benefits of migrating? So given that, that when you have an identity provisioning tool in place, then probably there has been a lot of money and time been spent. So implementing identity provisioning is usually not a cheap, not a fast, not a simple task. And that means if you switch your product, you're going against exercise, you might do it far better than the first time lessons learned, etcetera. But nevertheless, it's something which is not an easy, easy going and an easy thing to do.

And so what you should do first is look at your consequences for costs, for acceptance, for functionality, and think about this is really worse to do it unless you ly have to change. So why to migrate. And I think there, there are more reason end of life. That's clearly important. So there might be a situation that more than one provision system exists in your organization, UT enterprise merger in acquisition activities. That's a common scenario in larger organizations where, where you might end up with a number of such tools.

And at some point it might be really worse to consider consolidating these tools. It might also be worse to consider other approaches. So putting, for instance, governance layer on top of various of these technical identity provisioning systems. So integrated a higher level instead of replacing identity provisioning tools, there might be more than one provisioning system, two to lack of enforcement in it. So what I've seen variously is that organizations that are this, the region X or Y are set, they have done done it differently.

They have implemented a tool from render Ray while we have the tool from render B, but we, we didn't have sufficient power to stop them doing that. And clearly this is something you can only fix if you right now have sufficient power, if you can enforce consistent strategy on that.

And even then it's the question doesn't make sense to, to, to change the underlying infrastructure, or is it better to, to look at the layer above, for instance, access governance or trust that the guidelines and process etcetera and saying, okay, at the end of the day, it, the only relevance thing is what, what is the outcome of this? Then we have to standardization specific vendors, infrastructure. It might be just a strategic decision to say, okay, we go for vendor P or C because we do most of the things in infrastructure with that preferred vendor.

This is sort of best of freed versus having a strategic vendor with all the pros and cons of such type of decision. There's the, the topic of end of life of provisioning solutions. This is sort of the most mandatory reason to migrate.

So if you, if you, if the solution is end of life, then at some point you have to migrate running a tool in such a strategic relevant place. This new organization that is not supported anymore, obviously is not the very best idea. Then there might be new feature requirements. So identity explosion assess the term. I have created a while ago for the increasing number of users when you look at partners and customers.

So instead of sort of include as a few employees, you might have far, far more customers and business partners, and there might be something where you say, okay, I need other features of dealer that new audit features cetera. So it just might be that you say, okay, the product is not as fits, not as well anymore as it did. You might have negative window and or integrated experience might also be a reason ever as I've said, it's, it's always important also to, to reflect where, where, where, so where to point the answer sort, so to speak.

So who, who really is, is quote as guilty. And in some cases might also be that there are just some, some missing prerequisites. Okay. You could say, okay, the vendor and the integrate must have said this to me and said, okay, we need these processes, these guidelines, cetera. Nevertheless, I think it's very, very important to carefully reflect the challenges you're currently facing before you make such a big decision of, of migrating. Because when you do that, when you do the migration, you should be as safe as possible. Sure.

As possible that you end up with a better solution than you had changes in licensing. Also that happens occasionally that winter changes is licensing and you say, okay, doesn't fit anymore to what I want. It's too costly. Too expensive projects are fully failed. Also that happens a lack of vendor trust. So you don't trust in the strategy in the roadmap, et cetera. That's something we trust might, might happen.

However, you should then trust far more in the next vendor. So before, before you switch, okay. And the negative experience with existing systems, including lack of acceptance, sometimes this, this challenge is that big, that there's no way to switch to a wide switching from, from your current system.

However, in many cases it might be also better to think about how can you make the system better or change the user interface, etcetera, to, to grow acceptance. It might be far cheaper. So there are reasons that every reason is, is always compelling. And when we look at this we to migrate, then I think it's very important to, to look at some of the cost factors and some of the migration risks not to carry you to much. I think there are also very well reasons to migrate.

However, you should be, as I've said, you should think about, you should reflect these various factors before you make a decision. So if you look at a cost factors, clearly there, there will be changes in license and maintenance costs that can be positive for negative. There will be changes in hardware cost for, for some period of time. It might be that this cost go cost goes up and then goes down again.

Once you'll have only one problem product, but for period in between, it might be both from the cost perspective frequently, it means rebuilding your workflows, Sodom, you might migrate your workflow. So a lot of things you've did in customization overall might be about rebuilding. You might need to, to rebuild custom, customized connectors, etcetera. And some of these things can be pretty challenging, especially if you think about connectors and I've talked about this before connectors to complex target systems, you need to drain your administrators, end users, your developers, etcetera.

You should definitely review your processes. And in most cases, cases, especially when you're thinking about migrating a solution for TX as manage for provision, which has been in place for many years, you also should think about redefining, optimizing, improving these processes. Well-defined processes should be more or less the same for the new solution.

However, as I've said, experience shows that when you look at identity provision tools that have been out for a while frequently, they rely on, on a, not that comprehensive and not perfect set of processes. Again, this is something which cost time, which costs money, the migration risks. That's I think also a very important factor. So will the new vendor really provide what you need be careful on that. There's occasionally there's a, a difference between the vendor promises and what is delivered.

If you go more into detail, looking at in depth capabilities, you, you might observe for KRC connector for system a B, but it's not as, as, as feature rich as we need it, especially when it comes to complex target systems. When you, when you switch to another vendor because your other vendor has been acquired by someone else, you might end up with this new vendor being the next acquisition target. That's clearly a bigger risk for smaller lenders, but it's a risk. And that means that the, the roadmap might change. I'm I'm not breaching that you should go for, for the big winners only.

It's just something you need to consider. I think they're good reasons for, for small vendors, for regional vendors. They're good reasons for large vendors. It's not something where you could say the one or the other thing is the right strategy, but it's one of the things you have to look at carefully. What about a strategy? So is this topic of identity provisioning, a strategic topic for this vendor? Are they moving forward? Are they innovative? Are they adding new features?

So in our leadership compass, for instance, we have an area which we call innovation leadership, where we look at, let's say new types of features that are not that common, but that we expect be increasingly see this, the strategy of the vendor align your own strategy. So do, do they have the same view on identity access management? Then another question is, look at your processes, policies, etcetera, are they mature enough?

This is the, probably the most important perquisite before my ensure that your organization etcetera, as good enough, then you can't think about doing technology, but not the other way around. It never starts with selecting the product. It never starts just looking at a particular technology. It always starts with the organization. We'll talk about this in a minute, until there are all these inherent project risks, identity, access management, identity provisioning, it's a it's integration project. It's about integrating a lot of products, existing systems.

So it just makes this thing very, very, very complex because you're not dealing only with one department. You have to deal with a lot of different system owners. You have to deal with it and business it's one of the more complex types of it projects, as I've said, one of the important things is to understand it's not only about technology, it's about organization policies, processes first. So you need policies. What are the guidelines, the responsibilities, accountabilities, etcetera, which processes do you have? How do these map to your organization, do you need to change for organization?

Do you need to create new organizational roles, etcetera. And then you can look at the technology and, and think about how you can you protect your system and your information.

But this, this is very, very important to understand. And, and you also should have a good understanding of how this relates to the overall business view. For business perspective, it's about sort of use around access risks. I think our organizations today have understood that there's a risk for information and that there's, this, this still is a challenge. So how can you protect your, your information?

And then, then you have to look at the access controls, the access management. So this is the area where identity provision comes into play down to the enforcement writing and title one down to the various systems. But without understanding this context of having set this context in an appropriate way, you're likely to struggle with new identity provisioning system. And not surprisingly, we can support you with our advisory services, that area, what to migrate, all something, nothing. I think this is another important question. So it's not that it's always about.

I end up with one identity provisioning system. It's not always about I system a the same way it was system B. It's about understanding what are your various migration paths passes.

And there, there are a number of ways to do it. We have, this is reflected more, more in around access governance from, from what we do in research. So we have a new research about, which is about access governance architectures, which is looking at various sort of topologies for, for doing that at various ways to do that. So what you consider, so you, you know, you might think about, okay, I leave an existing, like a provision system in place.

I have, for instance, an access governance tool, which has some built on provisioning capabilities, or I have another provisioning tool I have more than one. It might be that you say, okay, for, for E P environment or for the micro environment, actually something different, which is very focused on that environment. While I have another one for the sort of the heteros and sometimes very, very large rest of the world.

So there, there are different ways and you can't go and say, okay, this is the right way to do it. There's not a single solution. That is always the best. It depends on your architecture infrastructure, a lot of other factors. And this is something you, you should spend time before you decide on doing a migration process. So what are the points to consider the cost of first running the system in parallel?

Clearly, even as only partially for some connected systems will be higher. You need more licenses or license for at least two products, hardware, operational costs, etcetera. You need to have skills for, for all these systems and so on. So from a cost perspective, clearly having one system in place appears to be the better choice. On the other hand, changing the sometimes RA complex connectivity for some of the environments might be challenging. You might also have organizational issues.

So if you look at, for instance, the S P environment, sometimes the S P environment sort of a, a separate kingdom, which wants to do everything for the systems themselves, that might be something where it's, it's easier to, to accept this fact and to integrate, to define clear interfaces between that area and the rest of the world. Instead of trying to, to, to find a role you've already lost, there might be a risk affecting core business applications clearly when you migrate.

So you have to be very careful, especially when it's about complex integrations, complexity of integration clearly is higher if you have more remote system. So if you have only one system it's from an architectural perspective to the simplest way to do the more systems you have, the more complex it gets.

And if you then also add, for instance, the service request manager or service catalog system, where, where you say this would be my interface for the users to request everything from their, their new cell phone, to their, their, their leasing car, to a room, to the access, right across various systems. And then you have sort of governance layer where you say, okay, this is where I do my ertification. And then I, you have the technical provisioning there.

If you have some sort of this three layered approach, those things really become complex from an architectural perspective, from an integration perspective. So it's always about balancing these, these various needs.

And again, there's not SIM single right answer on that question. It's about understanding where, where does the complexity lie and how to deal with that? There's the cost of migration. So it means a lot of reimplementation connectors. Most of the workflow, all of the workforce, maybe new processes, then you can say, okay, I would have to change the process anyway, user interfaces, cetera, cetera. That can be also quite, quite challenging, especially because it's frequently pretty hard or, and, or even impossible to switch over to things automatically. There's.

There are not that many tools that really successfully can assist to in the migration. And again, without adequate organization, you're likely to fail.

So what, what we occasionally see, not, not always, but what we see as a model, which is, is preferred by a number of customers is saying, okay, I, I might leave even a part of my legacy provision in place. And I build on an governance layer, or I might create some part to new provisioning system for really in depth creation. I rely on some other types of X governance integrated provision. So what is provided out of the box? I find the mix of things. So I don't rely necessarily on the single tool. Clearly it's important to understand that there's more than identity provision just layer above.

And the other thing I think, which is very important to understand is I think I've never seen a single identity provisioning solution in larger organizations with a larger number of flood applications that provide automated provisioning to every system. So you always will have a number of system and, and frequently these are 80 or 90% of the target systems that are served by manual fulfillment. So an interface to service request management for instance, is very important thing. What is important here is really understanding these architectural questions. You have a lot of options.

You should review these options. Not only thinking about migrating one to one, it's about understanding how do all these things fit together. As I've said, this is about looking at access governance, architecture, this and you product that it's looking about a number of other things here. So if you decide on, on doing that migration, the next question is when to migrate. Sometimes there's, there's some pressure for when.

So, so regarding end of life, etcetera, sometimes over time it shows up or it becomes clear that you have murdered time than was communicated at the beginning. And even in other cases, it's about understanding how much time do you really have, I'll start with the, the, the lowest bullet point migrate at your own pace. I think this is a very important don't, don't get a, or try to, to remain in the driver's seat, take your time to do it. Don't go into panic mode and go us or whatever, try to migrate your own pace and make it irrational decision.

So when it's about changes in licensing, an argument I've hear frequently. Then the question at the end of the day might still be that it's cheaper to stay with the product and to pay that price. If you look at your overall cost or it might be better to say, okay, I, I, I, I remain here for a while. I do it slowly. I accept that I have to pay more for one or two years, but I, I can do a very well sold out migration that might be far cheaper than switching over too fast. On the other hand, at some point you might then say, okay, it's better to do it. Let's stop it here.

Flexibility you need to have, or need to ensure that you end up with success. You need to understand. And that's, I think what's, where's again about architectural options. How can you ensure that you have a fallback or so if you, if you think about a layered model with provisioning and then on top access governance, it might be far, far simpler to, to migrate at your own pace component by component. So if you have a layered model, instead of a big model thing, there are some clear advantages regarding this factor.

And you need your resources in place, which especially in these days of, if I look at many countries, some economic prosperity, it's sometimes rather difficult to find the resources. So this is something I really observe a lot of organizations currently that I say, okay, I just don't find the people. And that's true for vendors. That's true for the customers. And you need to ensure that you have the right people on board. What are technical barrier requisites?

Another, I think important thing. And this is from an extract, from a newer product we have recently published. It's the IM I H E buyer guide. So the buyer guide for identity provisioning governance, you need to understand your, your, the flow of information around identity. So where does the identity information come from? How do you ensure identity information quality?

I said, right? It's not only about a single system. So if your, your integrator tells you, oh, we have HR. Everything comes from HR and that's it. I simply say bluntly say wrong. That's not true. If you look at it, realistically, things are far more complex. You have to look at where, where, where does the original information come from for which types of accounts? So for externals, it might be fairly different systems where do changes, where are changes initiated. And this might really change per attributes.

You, you have to understand the thing. You need to have a big picture for identity access management in place. So understanding what is the future role of you write identity provisioning and of access governance. You need to define a roadmap of deployment. So which pieces do you have deploy to deploy and mature? You need to have some technical expertise also on the target systems. So not only on your identity provisioning system, but also on the target systems. I think the letter is a very important thing, something which is sometimes underestimated.

You need, you need to have the people who understand how to connect your identity provision to the target systems. And for some of these systems, especially more complex systems, these skills can be pretty rare. You need to understand how to integrate with integrative service management. As I've said before, this can become pretty complex where to migrate. This is something I had in my story, at least partially before. So is your target the pu play identity provisioning? Is it something where you say, I need trust another identity provisioning product?

And I might put another layer on top, such as an access governance layer, or is it about an integrated identity provisioning and access governance solutions, which can be, do far more support the recertification in many other areas. Again, this is about understanding your big picture of anti access management, identity, access governance, understanding what you have in place, which different components, how they fit together, where you need to move. And then you can can think about what is the best way to do it. There a lot of factors.

And it also might be that you say, okay, I go for cloud identity, access management, without identity access governance. I go for a cloud solution because most of my applications today are, especially in the future will be cloud services anyway. And I can't manage the few internal ones well from the cloud, if this works for you or not, I think depends on also a number of factors and notably we will publish around European Ference. We will publish leadership compass on the cloud identity access management space.

Additionally also, also just reasonably published a report on cloud anti access management, which defines this market segment for the first time. So there are various options and you need to understand, will you stay on premise? And if you stay on premise, which combination of various tools you want to use, or do you want to go to a cloud again, a lot of questions you need to answer before you do the migration. It's also important to understand that identity provisioning will not solve all your challenges.

So we have the access governance part that might be integrated with identity provision, usually. So most of the products have some, some level of access governance capabilities, some more, some less, but identity provisioning is more fulfillment access governance model layer above this analytics of access rights request management re-certification and below that.

So in the, the second and the lower box was the do to border. You have the systems. And usually it's about saying, okay, my, my identity provision says that marketing Cooper is part of a specific system role. And the system role maps down to some, let's say, SAP business roles and ad global groups, etcetera. And then it ends up with some entitlements, but you, you don't know, or you don't decide sort of the, the single ACL on the active directory, the single transactions and the SAP system from that level, it's sort of a, a defined breaking line between these two levels. What we see.

And again, this is something we have recently covered in your report. We see a tendency towards providing more in depth management of the lower level, through what we call entitlement and access governance. Some vendors talk about data governance here. So we see a little, some more integration, but nevertheless, you also have to understand where, where that, so how, how deep does your identity provisioning go and where do other things come into play? And that's, again, you need to understand where your identity provisioning sits before you say, this is my next step. This is my next move.

I've also put together some questions to ask to your vendors. So when you think, say, okay, I want to, I want to have a new identity provisioning tool.

There, there are a lot of questions out of my buyers, kind of picked some of the questions where I say these are some of the top questions to ask the winners. So one is what is, or our leading systems. The vendor sees for identity information. It should not be only HR. It should be flexible.

This is a, I think a very, very important way of thinking as well, because the world is changing. Give more types of users, etcetera, more complexity. And if you want to keep your identity information fully high, which is mandatory for, for, for good access management and good access governance, then you need to under to do this step far more, roughly what is the depths of your connectors? So not only depressed, how many connectors does the vendor have, but the deaths, how deep do they go in SAP?

Look at this, especially for the more complex system such as SAP mainframe cetera, are the connectors owned by the vendor or not connectors that are owned might end, might result and sort of challenges in regarding the skill when you needed them in, in your project, not necessarily, but it can happen. What is your identity model? So one tier two, tier three tier, again, a very important thing, factors that you have persons which can be for instance, employees and customers, or employees and business partners and customers of your own organization.

So they have multiple identities and all of these identities can have multiple accounts. Look at this. Is it support or not? Is there sufficient flexibility for that? This is important. If you look at this computing drug stuff, if you look at all more types of users that are, you need to have more flexible identity model, how many workflow models, or is there at least a workflow and is it Al, is it simple cetera? When do you need to do code?

When you need to code which language cetera, do you have the skills, cetera, et cetera, who will do the project, meet people before you need to trust them. You need to know to get them to know them. I think this is very important and clearly also reference customers. So there are various questions when it comes to, to selecting sort of the right vendor for you, a tool that might help you as the upcoming call leadership Comant identity provisioning. It will be available later this week, week compares vendors in their offerings. I think we have 26 different vendors in that report.

So there's really a broad coverage. However, what I have to say is as with all of that type of tools, it's not just taking the right most in our case, right? Most winner saying, okay, this is the best one. It might be the overall best one, but it might be one that does fit to you. It might be also the one who's the perfect fit, but it's just one tool that helps you selecting your vendor. But you need to, I've talked about a lot of factors. You need to look at this even more roughly, and as I've said, we can support you with our advisory services, how to migrate there.

Let, let me give you an example, migration part path. I think the first step was reviewing your migration needs always. So do you really need to migrate? Yes. No. Define your target architecture. So how does it look like how, which role will ING play in future? How does it play together with access governance with entire system level entitlement management and all the other things? Once you have done that, and once you have ensured that, that your guidelines, your process, all the stuff is available.

You should define a migration roadmap and then select the products you need, depending on your specific requirements. If you go for a layer approach and, and frequently will be sort of layer approach. And if you go for an sort of integrated IM, so usually might use that. So IM I solutions Alexei governance, and you might even say, okay, I used the access governance part, and first my first integrated with my existing product and then my migrate, my, my, my connector step by step.

So moving forward in that way, I think it's a, it's a very interesting way to do it by saying, okay, I'm I first set up my new tool. I have an integration layer where people can request access. I connect back to my existing permissioning, and then I move connector for connector over to new or set of new tools or whatever you end up from your architecture. So this is basically, if you go down off the, there are various phases of doing this migration step by step, but that's one of the examples you might do it. It's not that this is always the best service way to do it.

That's the reason why it's called example migration part that, but it's one of the ways to do it. And there's a good logic doing it that way.

So to, to sum up when it's about migrating your, your legacy provisioning, it's not that you just go out and say, okay, I pick a tool. One, I pick another tool which does more or less, the same just frequently is not the best way to do it. It might be, would be a good fit, but more importantly, you need to understand how do you want to do it in future? It might also be that you say, I just want to have a service layer, which is far less sort of product, which is far more exposed to services because my overall it architecture so complex.

This is what you really need to do first understand what are the options, where to move. As I've said, there are various reports. And when then going to the Q and a session level show slide with some related research, not all, but we have a Broad of reports available on this topic. So with that, I come to the end of my presentation. And right now it's time for you to answer your questions.

And for me, then pick these questions so we can spend some minutes around the, in the Q and a, and if there are any questions from your side, don't hesitate to enter them using the questions of hag or whatever. It's called section, depending on the language of the go to webinar control panel. And as I said, the, the slide will be available. Feel free to approach us directly.

Also, if you have first questions on that and the new leadership compass identity provisioning will be available later this week. So if there are any questions I recommend you, you entered them.

As I said, we will soon have our upcoming conference. Also there, we will talk about, I allow to talk about provisioning, about architecture, about other aspects. So we will cover that in detail, look at it also from different perspectives, so different mindset so that you really can, can find your way on how to move forward. And there are many reports available, which are related to this topic. And as I said, if you have questions, please enter these questions now so that we can pick up these questions.

So regarding the research, we have this buyers guide and access governance and identity provisioning. We have a report which customer into detail around migration options for you, legacy provisioning, the upcoming leadership pro compass on identity provisioning, report, access governance, architectures, and leadership access governance. There will be us leadership, composite cloud IM, and one on IM suites later.

This here, the advisory note and entitlement access governance and various I reports around migration options. Also sometimes focusing more on how to migrate specific platforms over. So there's a lot of research there. If there are no questions, then I assume I have done a good job and answer your questions during my presentation. As I've said, feel free to get in touch with us directly.

We are very open to support you in your decision making and process around migrating to other identity provisioning tools and reshaping your overall identity, access management, identity governance infrastructure. So thank you for your time and looking forward to have practi again. And one of the upcoming call webinars there, some others within the next few days. Thank you and hope to you, thee. Bye.