Successful IAM System Migration
“If you have to decide for a new house – Would it look exactly like your current home?”
The question of system migration is a boon companion for IAM customers. Over the years, some established solutions like BMC’s Control-SA and SUN’s Identity Manager had to leave the market for various reasons. For existing customers of such systems, the replacement of their current installation is becoming a compelling need for the near future. With regards to this enterprise, several vendors are advertising and promising a smooth migration from the existing legacy solution to their platforms.
They argue, that certain tools will help to automatically convert and migrate existing data configurations to the new environment. But to tell the truth, an IAM system migration is a comparable effort like moving a home. To stay in this picture: Would it be really a big advantage for you, if the mover could place your furniture in the new home without instructions, because the old ground plot could be used for the new destination?
In various sessions at the KuppingerCole EIC, Gartner IAM summit and other comparable conferences, it was made clear by several experts (so I don’t claim authorship for this finding), that it would not be wise to replace a legacy IAM system 1:1 just by using a new vendor’s technology. The installed system was probably designed a decade ago. Considering a typical functional specification at that time and the limited experience of the customer with IAM (assuming it was his first IAM system at all), it becomes obvious that a review and likely a redesign of the IAM is highly recommended before migration. When examining the different aspects of IAM, it shows that not many aspects remain unaffected from the past changes.
At the first glance, not many things have changed since the last (first) generation of IAM solutions: Identities, Roles, Groups, Systems – The data structure of the legacy IAM seems still valid and many vendors of IAM solutions promote their ability to automatically extract and move the existing data to the new system. There is not much to say against such a service (in fact, also Beta Systems provides such tools in our migration projects). But with a closer look, access governance has also left its marks in the data model. With the growing implementation of IAM in the departments, a large range of additional information must be stored and processed in an IAM system. There is the necessity to differentiate between the different types of identities: Staff members, freelancers, customers, technical identities – When the last generation of IAM solutions was designed, the systems were mainly used for company-internal, human users.
But today, the IAM universe is extended by trends like cloud computing and IoT to identities much beyond this boundary. As a purchasing criteria, customers of legacy IAM systems should check, if their shortlisted vendors can flag and process all the different identity types according to their individual profiles. In addition to this, data and reporting paths from the business organization have become more important over the past decade. Where the last generation IAM systems was requested to manage plain org-tree structures, leading IAM systems must differentiate between different managers per use case today. Over the years, the IAM solution of Beta Systems, SAM Enterprise, has been enhanced by features for business managers, line managers, risk managers and an owner concepts for most IAM objects.
Not to speak about the growing necessity to manage access rights based on certain project memberships of users, rather than of their organizational allocation.
For the IAM system migration project, this growth in data structure indicates the necessity of the legacy IAM owner, to review his IAM concept first. The automatic or semi-automatic migration of existing data to the new system is not an issue for most vendors. But if a customer starts a migration project without having updated and specified his requirements, the new IAM solution might turn out to be as limited as the old one but with a new technology stack. In any case, the IAM customers must be aware, that the migration to a new solution requires – but also allows them – to run a new IAM project, where the up-to-date requirements are considered and implemented. This includes the well-known stressful questions like ‘where to get the (new) data from’? and ‘what’s the process /reporting path in the organization for a specific situation’. With regards to such data model extensions, the replacement of a legacy IAM doesn’t differ from the introduction of a brad new IAM solution.
Target System support
It’s a commonplace, that a prior task of IAM systems is managing access rights in the corporate IT systems and platforms. Therefore customers are right, if they consider the provisioning capabilities an important criteria for the vendor selection. For the migration of an legacy system, aspects like the list of availability standard connectors to all relevant platforms is clearly an indicator for a good and smooth update. But to estimate the ability of a current system to replace the installed one, further aspects must be considered. Reconciliation is a widely underrated feature: All IAM concepts are relying on the system’s capability to sync periodically the data in the target systems and the data in the IAM repository. But the question, which system is overruling the other (IAM or target system), is answered customer individually. To replace your existing IAM system, you will need a solution, that can be fine-grained configured, which data fields are governed by which system. Not to speak from the necessity to have a bi-directional communication for all connectors (which is still not the case with all vendors today).
There is probably no other aspect of IAM, where you will find bigger differences between some customers initial expectations for an automated migration and the final reality. For us, it isn’t unusual to answer questions on our product’s support for workflow notations like BPMN, when companies are in the process of vendor selection for their IAM successor system. Such questions are often based on the idea that the support of such standards would significantly reduce the migration efforts on their existing workflow solution.
First of all, workflow solutions must be separated into the process and the user interface part. Where the general process could be migrated by using such standards, the user interface will never do. But even on the process side, many aspects of a workflow are not covered by the process description. Manager structures, substitutes, delegations or escalations are difficult or not at all specified in standard notations. The possibility that even processes in BPMN-like notation must be defined more precisely and implemented manually, is quite high. No doubt, that the availability of such an abstract process model is a help in migrating existing workflows, but it would be incorrect to expect an automated migration without further ado.
With regards to the migration of user interfaces it is even more unlikely that the new installation can significantly benefit from any existing implementation. Experience shows, that “Just make the new workflows look exactly like the old ones” is an expensive task description. Customers are concerned about the ability or willingness of end users to adapt to new interfaces and processes. Therefore they tend to ask for 1:1 replacement of the existing look and feel. But again the question must be allowed, if such a proceeding is really a promising way? If you are replacing your mobile phone, do you also insist on having the same user experience like before? And your old mobile phone was probably not older than three years. For IAM, we are speaking about 10 years. To illustrate this request: The legacy GUI to be replaced was likely to be a contemporary of Windows XP and the first Blackberry devices. It is questionable, if one should really imitate the operation concepts of this age and if the end users would really appreciate this?
The view on the workflow is indicating another subject, which must be considered for the replacement of legacy IAM systems: Compliance. Looking to the key IAM drivers from 2005, efficiency and effectiveness were much stronger drivers than the fulfillment of regulations at this time. There can be no doubt that the requirements on the compliance and auditability of IAM processes has grown over the past years. Applications / workflows like user recertification or policy management have evolved to core features of IAM. It can be, that the legacy IAM was extended this way to some degree in the past. Most legacy systems are facing limitations to do so, by design or by their discontinued technological support. In any case, customers of legacy IAM systems should be prepared to review their actual compliance requirements in order to implement the corresponding functionality in their successor solution right away.
In fact, all these examples are again pointing to the biggest weakness of the discussed idea of a ‘fast and automated migration of IAM systems’: The multi-dimensional progress that took place since the legacy system was implemented. The customer’s organization has opened up and evolved beyond your corporate boundaries since then, the landscape of the managed target systems has changed, mobile phones and tables have become major devices for end-user interaction and as a consequence the operational expectations of the users have changed significantly. Your old IAM system was probably neither designed from the beginning nor adapted over the years to really serve these changed conditions. Therefore the migration of your existing IAM solution to a new system should be seen as a chance to implement a solution that is able to comply with your current and future needs. Of course, this possibility is requiring further efforts in reviewing and redesigning your IAM concept. The idea of an automated and fast migration will lead to the second best solution in any case.
What is my / our recommendation for you how to proceed? There is one criteria that is valuable for all above mentioned aspects: Experience. With an experienced partner, the review and update of your legacy IAM system is much less risky and much more promising, than entering this venture on your own. Beta Systems is in the market for 25+ years. Our IAM solution was continuously maintained and enhanced to meet your needs today and tomorrow. With our combination of experience and product excellence we are a reliable partner to help you to successfully lift your IAM solution to the next generation.