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.