IAM migrations have become an increasingly common practice, particularly as companies embrace a remote workforce model. I have actively guided many of my clients in transitioning from one IAM platform to another, often moving from legacy home-grown tools to more standardized enterprise IAM tools.
Here are a few strategies for executing successful IAM migration projects:
Avoid Lift and Shift in IAM Migration
With IAM migration, it’s easy to fall into the trap of simply transferring current functionalities and capabilities into the new platform. Migration projects, however, present an excellent opportunity to revamp and improve existing processes. You should strive to eliminate unnecessary steps, enhance controls, automate manual tasks, and improve the user experience.
During a migration project for a financial institution, I eliminated a “model-after” feature in their existing home-grown IAM tool, effectively closing a major open risk item. The feature allowed users to request access by blindly copying all entitlements another user had. My team was able to move the client away from this access request model to a more secure model without making the underlying process of requesting access more complex in the new tool.
Assessment and Inventory in IAM Migration
It is critical to understand in detail what capabilities the existing IAM tools have. This is even more crucial when it is a homegrown tool that has been improved upon for several years.
You can understand current capabilities by reviewing documentation that was put together during the implementation of the existing tool — if they exist. This will include requirements, design, and architecture documents. For home-grown tools, beyond going through the documentation, it might be especially important to review actual code snippets of the existing functionalities and document those as well.
When I helped a client migrate from several decade-old, home-grown tools to SailPoint IdentityIQ in a large-scale implementation, we reviewed scripts for each custom functionality we were migrating over to SailPoint IIQ. We did this in multiple code review sessions with the developer(s) of each of the functionalities. There were some functionalities where the original developers had left the firm. In those cases, we worked with the next best resource that understood the functionalities of the script.
Keep Key Drivers in Mind and Plan Accordingly
There are so many valid reasons why organizations invest in migration projects. It is important to understand these reasons and keep them at the top of your mind all through the migration project. This will become important in prioritizing project activities and making key design decisions.
Prioritize Communication
This is one aspect of the IAM Migration process that cannot be over-emphasized. From communicating with the project sponsors in order to understand what the key business drivers are, to communicating with the various business teams, development teams, HR teams, and ultimately the end users.
When meeting with the various teams to communicate the migration project, three key items to communicate are:
- What is changing?
- Why it is changing?
- When the change is scheduled to be implemented?
You can conduct periodic webinars, Q&A sessions, or workshops to accomplish this. Also, they should be done well in advance before production deployment to give enough time to prepare for the change and address any concerns that may arise.
It is always remarkably interesting to see what gets uncovered when these communications begin to happen. In some cases, you would experience a lot of push-back from different teams, and often for very valid reasons. Be careful not to dismiss these concerns and tag them as “being resistant to change”. Empathetic listening skills are required here as well as strong negotiation skills. In my experience, opportunities to deliver an even better solution arise from these situations.
I had a client in the healthcare industry that shared with me how an initially planned multi-year IAM migration project failed completely because of poor/delayed communication. The first phase of the migration was scheduled to run for about 12 months. Nine months into the implementation, a meeting with the HR-IT team brought the project to a complete halt.
Always ask the questions:
“Who should be aware of this migration project?”
“Who should I be talking to about this feature or process we’re migrating over?”
Take note of any responses you receive and don’t forget to communicate with existing developers, system analysts, administrators, help desk, and other technical teams. They’ll need to be on board in order for the migration to be successful.
Adopt the Right Deployment Strategy for IAM Migration
I typically advise against a big-bang production deployment for IAM migration projects. A good strategy is to deploy new components/modules in phases while the old system is gradually phased out. It is the primary responsibility of the architects — working closely with the product owner — to come up with a logical breakdown of modules/components that can be deployed in phases. This breakdown can be structured by business units/departments, by functionality, or both — depending on what makes sense for the given situation.
Once a deployment strategy is established, it is important to stick to the plan as much as possible and iterate as needed until the entire migration is complete.
Conclusion
While IAM migration projects can pose challenges, successful execution is possible with strategic thinking. These projects may take time to complete, but the ultimate goal is to ensure minimal disruption to existing business processes while adhering to the migration plan and objectives.
Prior experience is key when choosing an implementation partner for your IAM migration, as it can significantly reduce risk.
Ready to take on your next IAM migration project? Our expert team is here to facilitate a smooth, hassle-free transition. Contact us to learn more.
