Skip to Content
Technical Articles

Upgrade of SAP IDM (not) for dummies

More than five years have passed since the current version of SAP Identity management – v. 8.0 – was made available by SAP. It introduced significant improvements in the software that had been long-awaited. Moreover, at the end of 2018 the old version – v. 7.2 – went officially out of maintenance. With such important drivers to perform an upgrade, normally the transition from 7.2 to 8.0 should have been done and forgotten by all existing customers long time ago. Surprisingly, that was not the case. The adoption rate started and remained slow, many waited till the last minute and two years later there are still some companies who use v. 7.2.

The typical reasons like budget limitations, willingness to make sure the new version is stable enough or internal reorganizations while contributing to a certain degree were overshadowed by another two, much more important ones.

Due to the core changes in the software the upgrade from 7.2 to 8.0 was not an easy one. The complexity was quite high and for many companies it felt almost like they need to do a new implementation. With not so many IDM experts available on the market to support such challenging initiative the upgrade projects across the customer base started failing. Another not so motivating factor was the unclear roadmap and future of the product. With those two combined it is not a surprise that some companies even decided to decommission SAP IDM and replace it with an alternative IAM solution.

Thankfully, the future of IDM is now secured! SAP confirmed its mainstream maintenance until the end of 2027 and the unofficial message is that IDM will be among the last on-premise products to be decommissioned giving it probably at least another decade ahead of it (more on the topic can be found HERE).

Additionally, to reconfirm their strong belief in IDM, SAP has launched a customer connection program, which is supposed to run annually and further emphasize the importance of the product. During the first cycle of the initiative in 2020 out of 149 submitted requests, 78 qualified with more than 10 votes, 10 were already offered and 12 were accepted for development in 2020. The highlights of the selected requests include an on-premise S/4HANA connector and an upgrade of the runtime JavaScript engine, which was anticipated for a long time within the community.

With SAP IdM being the foundation of the Hybrid SAP Security Environment it is clear that an investment for a proper upgrade will pay off in the future (more on the topic can be found HERE). The last statement raises some important questions: What is a proper upgrade? How can you be sure that your upgrade was done properly? What are the consequences if it is not done right? To answer those questions, guide you through the common pitfalls of an upgrade and give you some insights about possible improvements along the way is the main purpose of this blog post.

Upgrades are not born equal. As already mentioned, this one tends to be quite complex. Thankfully, SAP provides a dedicated guide evaluating the most common scenarios, which customers follow when upgrading from SAP IdM 7.2 to 8.0. We won’t dig into the most obvious recommendations the guide outlines, but surely, we will emphasize some of those, which should not be omitted. (SAP’s dedicated upgrade guide for SAP IdM)

SAP IdM follows an upgrade policy, which has a pre-defined path: if you have started with IDM since version 7.1, then you first need to move to 7.2 and only then to 8.0 rather than jump directly to 8.0. For SAP IdM 7.2, the SP level of the existing installation should be at least SP09, where SP10 is actually recommended.

There are two main strategies for the upgrade according to the SAP guide:

  • OPTION 1 – Upgrading the existing SAP IdM v. 7.2 system to v. 8.0 while preserving all historic data in the system

SAP%20IdM%20Upgrade%20Option%201

SAP IdM Upgrade Option 1

  • OPTION 2 – Installing a fresh SAP IdM v. 8.0 system and manually migrating/copying the data and the configuration from the old system to the new one

SAP%20IdM%20Upgrade%20Option%202

SAP IdM Upgrade Option 2

Although the most often selected is “Option 1”, we will list the pros/cons of both options. The graphics above depict the two methods.

Unfortunately, it is not obvious from the guide that the selected upgrade strategy impacts significantly how you run and maintain your SAP IdM system in the future. If you pick “Option 1”, you are then bound to manual upgrades in the future and patching using installation scripts (e.g. the old-fashioned way available in v. 7.2). However, if you go with “Option 2”, then the recommended approach for patching/upgrading becomes SWPM (Software Provisioning Manager).

Even though “Option 1” lists steps like importing the new provisioning framework and restructuring of the default package as optional, we highly recommend that those are executed mandatory. As you will see later, there are much more benefits in doing so rather than not. To name just one of the most common pitfalls here – in the old provisioning framework all references are still based on ids, which was the only supported way. With the new provisioning framework references can be built on so-called unique name identifiers and this is very important, especially if you plan to use the new “Transport” functionality in v. 8.0. A consequence of this reference change is how you work with the built-in JavaScript function “uRunJobNow()”. If you continue using the job id reference, you will have one and the same job id in the script for all SAP IdM systems in the landscape. However, the job id changes during transport and as a result your “uRunJobNow()” won’t run, or even worse, might run a different job. To avoid this, you should use a package constant of type job reference, which will automatically point to the right job id after the transport thanks to the new unique name identifier.

Irrelevant of the strategy you pick, keep in mind that while v.7.2 was letting you have forms and processes with the same name, this is already not allowed in v.8.0, since it leads to issues with the package transport. Moreover, all public tasks are converted to private during the upgrade due to the one-package approach and the new naming conventions for public objects in v. 8.0.

SAP IdM has a quite complex component structure, spreading through database objects, runtime components, VDS and SAP NetWeaver add-on software components. The upgrade guide covers them all, but the aspect of the OS folder structure should not be left behind, especially in “Option 2”. Usually SAP IdM has import jobs, which get their sources from files. Those files (e.g. email templates) should be re-created in the new environment to ensure a smooth transition. Although regular sending of emails can still use the old file-based templates, the new approval task expects that the email templates are imported in the dedicated templates database table.

One of the big changes in technical aspect between 7.2 and 8.0 is the switch from Java 1.6 to Java 1.8 for the runtime components. To be more precise, v. 8.0 depends on SAP JVM 8.1. If you follow the upgrade guide, the switch itself should not be a problem, but keep in mind that you might have some headache, if your target systems are connected in a secure way to SAP IdM. You should make sure that all target system certificates are properly migrated/reimported and that the new Java runtime has similar configuration as its predecessor to avoid any broken communication channels.

There are also some functionalities, which were visible in the Management console of v.7.2 but are missing in v.8.0 Developer Studio. However, this does not mean that they are not there and you cannot use them. Two of them are job variables and job scheduling rules. The former are still available and stored in the mc_job_variables table in the database, but they are not part of the package transport, so if used, they should be re-created in each system. As for the job scheduling rules, they also exist on database level and SAP released a note explaining how to create your own using SQL. However, our recommendation is not to fiddle directly with the database and instead adopt a free and easy to use add-on for managing all your scheduling rules in one place.More about IDM Scheduler add-on by ROIABLE can be found HERE

Unfortunately, several audits our experts performed for new customers showed that some of those important aspects were neglected during the upgrade. Consequently, we had to perform additional steps in order to make sure their system is in a proper state. If after the upgrade your SAP IDM system acts strange, it’s definitely worth checking.

Last but not least, when we talk about the upgrade from SAP IDM 7.2 to 8.0 – there was one major addition (replacement) to the portfolio of supported databases. Sybase ASE was included in the list, replacing Max DB and new installations on the former started piling up. At first, customers were somewhat hesitant if Sybase is really an enterprise-ready database. Personal preferences aside, let’s look at some insights from Gartner.

Gartner%20Peer%20Insights%20-%20Oracle%20vs.%20Sybase

Gartner Peer Insights – Oracle vs. Sybase

Since Sybase was acquired by SAP in 2010 it became SAP standard alongside their leading in-memory database HANA. Picking the right database is important for any solution, but this is especially valid for SAP IDM where significant part of the software itself depends on DB stored procedures. Besides the technical impact such choice can have also a serious financial impact. The license gap between Sybase and Oracle (which was probably the most popular DB for SAP IDM before) is now wider than ever. While new customers can start directly with Sybase, existing customers of IDM running on Oracle were presumably faced with a lack of choice: till recently SAP was advising against a DB switch, after the upgrade due to the complexity and significant technical differences between Sybase and Oracle.

However, our team of SAP IDM experts has already helped several companies switch from Oracle to Sybase (plus few more migrating to other supported DBs). Respectively, such move is not just possible, but it actually adds a third option for upgrading from 7.2 to 8.0.

This “Option 3” consists of full system upgrade following the official “Option 1” approach, including the optional steps for the provisioning framework and splitting of the packages. Then it is followed by “Option 2”, where a brand new system is installed on a database of choice (e.g. not the database, on which SAP IdM 7.2 was running – for example Sybase ASE). The last step of the new option is called – database migration. The already configured system from “Option 1” is migrated on the database of “Option 2” resulting in the following:

  • You have a brand new installation of SAP IdM v. 8.0 and thus you can use SWPM for future upgrades/patches
  • You are running on the new provisioning package with properly split connector and custom packages
  • You will have the complete history and audit trail of SAP IdM from its initial implementation
  • You could be running on any of the supported SAP IdM databases of your choice, according to your preference

Cleary “Option 3” is superior compared to the other two. However, most customers already performed their SAP IdM upgrade following either “Option 1” or “Option 2”. The logical question is – can you still take advantage of “Option 3”? Yes, you can!

2 Comments
You must be Logged on to comment or reply to a post.
  • till recently SAP was advising against a DB switch, after the upgrade due to the complexity and significant technical differences between Sybase and Oracle.

    Could you please share a link on that statement from SAP? We’have recently upgraded from 7.2 on Oracle to 8.0 on ASE and want to be ready to all kind of surprises. Personnaly I don’t recomment such switch too, but I’d like to know how SAP explains that.

    Thank you for blogpost!

    • Hi Artem,

      I am not sure about which statement you particularly mean, but SAP position on the migration hasn’t changed. They still do NOT recommend it and there are many reasons for that. Most of them related to the technical complexity, not to any other limitations. The blog just explains that such a migration is possible and working just fine. We have done it multiple times.

      If you want to read more about it, I can recommend this blog article -> https://roiable.com/article-sap-idm-8.0-database-migration-now-possible.html

      BR,

      Todor