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).
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.