Feeling ‘Sun-burnt’ by Your Sun Identity Migration Options? Part I

By Robert Block ·

2014 is RAPIDLY approaching. Industry leaders such as FishNet Security have been talking about preparing for your Sun Identity Manager (IdM) migrations since 2010. However, this blog entry is an update focused on the trials and tribulations of a migration.

First, let’s start with the word “migration.” In IT-speak, this implies some transition from one tool to the next tool, a “movement” of things between tools or both. On behalf of the entire industry, I’d like to apologize for the rampant use of the word “migration.” “Migrating” from Sun IdM to any other product is marketing hype or a vendor sales position.

Next, what about the term “R&R”? Yes, I know you are thinking: “How can I rest and relax now that you have told me no migration path exists?” I would say that “R&R” in this case really stands for “Rip and Replace.” This what is actually going to happen for all intents and purposes. You’re going to “replace” Sun Identity Manager with something, and then “rip” Sun IdM out of your environments and minds forever.

R&R sounds painful and expensive, right? Many in this industry are touting one-day complimentary workshops, script-driven assessment tools, migration roadmaps, etc. Let me save you the trouble and give you the low-down now: You need a deep and accurate understanding of your Sun IdM configurations and environment before you can effectively proceed.

Let’s examine specifically what must be replaced:

  • User Interfaces: In Sun IdM deployments, the average is 20, and most are custom forms.
  • Workflows: With Sun IdM deployments, the average is 25, and they are written in Xpress Script (think proprietary version of Latin).
  • Connectors: The average Sun IdM deployment includes 16, and most are built with some customizations and not all are configured with active reconciliation. More on why this is so important later in this blog post.
  • User Objects: Luckily, this item is pretty straightforward, with the exception of schema extensions and custom attributes.
  • Role Models: WOW. Talk about no longer supporting a framework for Roles, given you cannot export Sun Identity Manager Roles to any other solution — none, not even Oracle.

Alright, so now to your replacement approaches:

  • “If it ain’t broke, don’t fix it.” — Some might say, “My Sun IdM deployment is operating effectively, therefore we just want to pay the enormous fee to continue on Sun Identity Manager after 2014.”
    • Survey says … BAD IDEA. Well, unless budget isn’t a concern. And if that’s the case, I have some beachfront property in Arizona for sale.
  • “Clone and Own” — Others might say, “My Sun deployment works today, but we realize we need to get off this infrastructure, and now is the time. We just need to replace one-to-one what we have in production, and we are good to go.”
    • Survey Says … NOT POSSIBLE. Sun Identity Manager was born more than a decade ago, and it does a great many things uniquely. Every other product has its unique methods of satisfying the same requirements. Is the role model the same? Are the forms generated the same way? Are connectors built the same way? How else can vendors differentiate themselves? The fact is you will spend more time analyzing your existing environment than you would re-gathering your requirements, only to find out that the new tool won’t work that way anyway.
  • “Regroup and GO!!!” – Before jumping into action in any particular direction, take time to evaluate a few items:
    • What are your business requirements and are you meeting them effectively today? This is a perfect time to address new business drivers that have emerged since your Sun IdM implementation, or close the gap in areas where you did not achieve the objectives set for your IAM program. (By the way, you actually have to determine whether the business wants the plain truth or the sugar-coated version.)
    • What is your current IT strategy when it comes to cloud adoption?(Cloud-based Identity Management is becoming more of a reality, so maybe you don’t need to take a traditional path to Rip & Replace at all.
    • Who are your strategic IT vendor partners now? This will lead to your likely replacement path or, at the very least, a qualified place to start the conversation.
    • Are you working with a credible integrator who has replaced Sun Identity Manager before? Nothing beats leveraging another’s pains and lessons learned for your gain, and experience trumps perceived upfront cost efficiencies in this particular case.

Since the 2010 announcement that Sun IdM would sunset, FishNet Security has encountered and had experience with each of these approaches. I don’t know a customer yet that wants to “pay to play.” We have struggled quite a bit with the “Clone and Own” approach, which is why our survey says it isn’t possible. Again, just unfolding all the layers of a customer’s Sun deployment (unless they have maintained exhaustive documentation) has proven to be a not-so-worthy and futile exercise.

Stay tuned for more on what we recommend you do and what we believe are some technical gotcha’s you should be trying to avoid.

Click Here for Part II