Regardless of the IDM platform, every institution struggles with choosing when to perform an upgrade of their IDM system.
It always seems like the enemies of progress are standing in the way: money, time, knowledge and/or discontent. However, no matter what the obstacles may be, upgrading your IDM environment is the best way to gain access to new features, tools, and improvements to not only grow your processes, but to also keep your current processes running smoothly over time.
I know it may seem counterintuitive to some, after all, as the old adage goes, “if it ain’t broke, don’t fix it,” but just because something is working today, does not mean that it will continue to work tomorrow, or that proper management and maintenance of a key system should be ignored.
A perfect example would be a situation where your current IDM solution consumes data from your HR source in a daily batch reconciliation process. The process may have worked flawless for months, maybe even years, but in the name of progress a new HR module gets added, which significantly increases the amount of data that needs to be consumed by your IDM solution, which may already have been a few years old itself.
Then let’s say the increased amount of data exposes a memory leak in your current IDM solution, which results in a process crash and a loss of data that repeats daily each time the IDM system attempts to consume the large amount of new data from the newly expanded HR system.
So now, in researching the problem, let’s say you find that there is no patch to address this, even though the product version has been around for a few years. With no patch available, you contact the vendor for help. The vendor informs you that the version you are on is too old and no longer supported. In addition, the vendor then informs you that the issue was found late the in product’s life for the version you currently have installed, and the fix was included in the next version’s release, so the only way to patch the problem is to perform an upgrade of the IDM solution.
Now your institution is left with a product that cannot support its current needs as an effective IDM solution, and an upgrade is weeks, maybe months, away from being able to be completed depending on your institution’s capabilities, budget, schedules, etc…
This is certainly not an ideal situation or one that any IDM owner wants to have happen.
Most vendors will make a public support schedule for their products where companies can see when their version will no longer be supported by the vendor, and/or when newer versions may be released. Not only is it always advisable for institutions to have roadmaps of the IDM components and capabilities they want to develop, implement, or install in their environment, but it is also a very, very good idea to always plan for new releases and watch out for patches that may be relevant not only to things happening in your IDM space today, but also what is to come tomorrow. Then, no matter what the obstacle is, money, time, talent, etc., you can be better prepared to deal with those obstacles in advance as part of your IDM roadmap and not as an emergency fix.
That being said, as a consultant, I have found myself in discussions with IDM owners who have expressed discontent about their current IDM solution and desire to move to another vendor technology. And while there is nothing wrong with changing from one product to another in most cases, I do see problems when the change is made in response to a mismanaged IDM solution not meeting the current needs of an institution.
It’s one thing to change if the solution no longer meets your needs, does not support new technologies that have been adopted internally, or is no longer offered by the vendor. In those cases, companies have little choice but to replace their current IDM solution with a new product from a new vendor. But, to do so because of a lack of knowledge, or support internally of the current product, rarely yields success.
True, a vendor or consultant may be able to come in and successfully replace the old system with something new, but if the group that owns the environment does not maintain and manage that environment responsibly, i.e. patches, upgrades, etc…, then it is only a matter of time before the new environment ends up like the old one and is viewed with the same discontent.
And now you might be wondering, “but what does this have to do with the right time to upgrade?”
The answer is “before”.
“Before,” what you might ask?
Before the product is so old that it cannot keep up with the growing needs of your business.
Before it is broken and you can’t fix it.
Before the budgets have been allocated for the next fiscal year and you’re left wondering if the environment will make it to the next budget cycle discussion.
Before the system becomes too old, too unreliable, too buggy and discontent sets in.
In a nutshell…before it’s too late.
If done right, it is never too early to upgrade. It is never too early to manage and maintain a critical system. I’m not saying that you have to be waiting at the keyboard to upgrade the day a new version is released, but I am saying don’t wait until it’s too late.
Don’t wait until your current version is out of support and you are two or three versions behind.
Don’t wait until the rest of the company outgrows your current capabilities and your IDM solution is viewed as the archaic hold up to innovation, efficiency, or success.
Don’t wait until a critical failure forces your hand and a hasty upgrade is made without proper planning or testing that then jeopardizes the future of the solution as a whole.
Don’t wait until tomorrow to think about tomorrow. Think about tomorrow today.
SIDE NOTE: If you start an upgrade, finish it. Don’t leave a system half upgraded to the point that you have no choice but to keep the old version actively running to maintain your processes. If that’s the case, then you didn’t really upgrade, you didn’t really solve any problems, but you did manage to most likely add more risk to your IDM solution so that tomorrow’s upgrade will be a lot more challenging and costly.