Sun Identity Manager is a king that has fallen. It is now called Oracle Waveset and it is as good as dead. Yet there are still many Sun IDM installations that hesitate with the migration. One of the major concern is the cost of the migration project. But as I have written in the first part of this post there are ways how to bring the cost/benefit ratio of the migration project to an acceptable level. However there is even a bigger issue that is inherent to all migration projects: risk. Most organizations that have deployed good IDM solution know how big that improvement was. Operating without an IDM is no longer a feasible option. So, how do we switch one complex IDM solution to a completely different product without completely ruining your efficiency and jeopardize your security in the process?
Most organizations cannot simply turn Sun IDM off and then deploy a new IDM product. Even if you choose a good product it takes several months to prepare new IDM solution. You have to configure, customize and test it sufficiently well to replace existing Sun IDM. An organization that has an IDM system can no longer live without it. Therefore deployment of a new system will take place while the old one is still running. But there is a problem. Even if you migrate the data from the running Sun IDM to the new IDM at the very last moment, it will take weeks until everything is tested and ready for cut-over. But at that time the data are already few weeks old and most likely out of date. And even if they are manually updated the cut-over is still a huge risk. The updates cannot be really tested. So there is a risk. Not to speak about the inherent risk of the whole operation: you are going to make a critical change to a system that typically manages almost all your applications, that can easily impact all your users and that can efficiently stop all your business in a few seconds. And the scariest thing is that many bugs will appear only after few days or weeks of operation when there is no way back …
No, this “flag day” cut-over approach does not really work. Some IDM businessmen might try to talk you into this. Yet this approach is insanely risky to be used in any real-world scenario except for the smallest and simplest ones. It is not a practical approach. And we are very pedantic when it comes to practicality of IDM solutions. Practicality is one of the very foundations of the midPoint project. Therefore we have a much better solution.
Imagine two IDM systems that work side-by-side and cooperate. No, not just imports and migrations. But systems that can cooperate for a long time: months or even years. I mean a really sustainable solution that allows gradual migration. You start with Sun IDM full of functionality and midPoint which is almost empty. Then you are moving resources one by one from Sun IDM to midPoint. Proceeding gradually in small, controlled and containable steps. Each individual step is so small that it can be rolled back if needed. Step after step you get to the point where Sun IDM is empty and all functionality is in midPoint. Sun IDM can be safely turned off at that point. This is almost too good to be true. But it is true. MidPoint now has a connector for Sun IDM. So midPoint can control Sun IDM. Or midPoint can synchronize data from Sun IDM. Both scenarios are possible. Therefore sustainable coexistence of Sun IDM and midPoint is a reality now. Gradual migration projects are possible now. This is practical way how to significantly reduce the risk of Sun IDM migration project and finally make it feasible.
We already have a couple of successful Sun IDM migration projects. We are working on projects where Sun IDM has been coexisting with midPoint for several months. We know that this is a real and practical option. And we know that this is the right way for the efficient and safe Sun IDM migration. This is the right time to get rid of that old IDM skeleton in your closet.