What to Consider with a Legacy IGA Replacement

May 19, 2020

Let’s say you want to replace your legacy identity governance and administration (IGA) system and bring your organization into the modern era. You might find yourself asking the following questions:

  • What are the prerequisites for replacing our legacy system? 
  • Do we need a migration strategy?
  • What’s the business case for upgrading
  • Do we have a roadmap for the project’s estimated costs and timeline? 
  • What vendors or solutions should we consider, and how can we choose confidently
  • Should we look at an on-premises or a cloud-based solution, or both? 

Since we’ve covered several of these topics already we’re going to focus here on the first two. 

prerequisites for replacement

It’s important to look at features and functionality in any IGA solution, but remember that these capabilities are enforcing your identity and access management (IAM) policy and process. Strong governance should be your starting point when looking at a replacement system, because the most effective implementations are the ones that reinforce your governance policies. 

Following are some critical actions to take before you begin the replacement process, to ensure that it proceeds according to your expectations.

  • Make sure to coordinate the necessary teams, time, and budgets upfront, before the project gets underway. Anticipate that buying an off-the-shelf solution doesn’t mean it will be plug-and-play. 
  • Scope what the new system you’re considering will do against the functions of what the old system was doing. Some use cases, typically edge cases, can be problematic. Make sure you have those covered.
  • Know your use cases, but be flexible. An upgrade often means accepting compromises rather than making a one-to-one exchange. Evaluate your priorities and know what you can live with, and what you can do without.
  • Question—or revisit—why your business processes exist and what needs they serve. This could be a good time to let go of kludge processes designed around sub-optimal systems.
  • If you’re planning to replace your on-prem tool with a different on-prem tool, look at the processes, customizations, and integrations you will need to adjust. 
  • If you’re planning to replace your on-prem tool with a “cloud-compatible” one, make sure your use cases are covered. Some cloud-friendly tools are immature and don’t yet cover the capabilities organizations with legacy systems have relied on.
  • Think about whether your organization is willing to adopt best practices or whether you will need customizations to adapt your new system to your existing processes. Adopting best practices is often harder for mature, complex organizations.
  • Do your homework. Make sure the vendor you selected is aligned with your objectives, and is not overselling its capabilities. Seek to correct current implementation problems that are your responsibility, and not the vendor’s. 
  • Take a subjective view of cost considerations. Customized solutions are more expensive, but can also be more aligned with your business. Cloud-based, off-the-shelf tools are cheaper, but require you to follow the directions on the box. 
  • Look at what skills you have in-house and what staffing you’ll need to bring in for a successful implementation. Migrations are complex and you don’t want any surprises. 
  • Make sure you have high-level buy-in. Even if you’re buying an off-the-shelf solution, you still need C-level sponsorship. Supportive leaders can remove roadblocks and rally the necessary resources. 

develop a migration strategy

No migration is as simple as “rip and replace.” When replacing your IAM system, you have two options: you can turn off the old one and then turn on the new one; or, you can run the old and new systems simultaneously and convert from one to the other, function-by-function. Which strategy you choose will play a huge role in how the project unfolds. 

Either way, when it comes to necessary resources, it’s important to be prepared. You’ll need regression testing on your legacy system. You’ll need to consider your new user experience and how to train users on the new system. You’ll need to evaluate the implications of audits that may take place during the transition period. You’ll need to pace the project’s scope according to a realistic timeline (even a “big-bang” cutover, which is simpler, doesn’t happen over one weekend.) 

Your migration strategy needs to be determined upfront: too many things depend on it to decide as you go along. Ideally you’ll make migration decisions based on long-term drivers of business health—like safety, maturity, and user experience—and secure the critical resources ahead of time.

We’ve seen some companies attempt to replace their IGA system only to end up shelving it: the implementation wasn’t well-planned or well-executed, and as a result they never realized the tool’s value. The earlier you can map out the right strategy, determine the right policies, and have the right discussions, the better off you will be. 

If your legacy system isn’t keeping up with your demand on its capabilities, the user experience is terrible, it’s too resource-heavy, you’re paying too much for it (or it’s too expensive to run), or your architecture needs to move to the cloud, then it might be time for a replacement. Focusing on your key business drivers, considering these prerequisites, and developing a migration strategy not only will help you make better decisions, it will steer your project toward a successful outcome.