Upgrade to Solution Manager 7.2 - Keep calm you must!

A specific upgrade strategy is required for a secure and successful upgrade to 7.2. This must be established on the basis of a solid upgrade decision matrix, which can be used to derive an individual solution approach for the correct and secure upgrade to 7.2. Five central parameters of such an upgrade decision matrix are

1. The prioritization of the 7.1 applications to be migrated: Which application must be fully functional again in 7.2 by which deadline? Because: A Service Desk, Change Request Management (ChaRM) and monitoring based on the Monitoring and Alerting Infrastructure (MAI) are migrated in the shortest possible time, including (automated/manual) rework, e.g. In contrast, an upgrade of the Test Suite involves time-consuming manual dismantling (in 7.1), rebuilding and reworking (in 7.2). Here, however, the solution/process documentation is less of an effort driver than the complete rebuilding of test plans and packages, as only the test cases included in the process documentation, including the incidents associated with them, are migrated. Customers who only use the Test Suite intensively are therefore well advised to carefully compare the upgrade scenario with the new installation scenario, but what changes in very few cases when upgrading from 7.1 to 7.2 is a fundamental change to the process documentation. That's right, it should be tidied up before an upgrade!

   However, this is usually done at the level of 7.1 projects as part of the upgrade preparation activities. Most customers do not need more than one day for this.

2. The concrete scheduling of the applications to be migrated: Whenever possible, avoid placing the migration of the Test Suite in the phase shortly before or during an upcoming integration test.Applications such as the Service Desk, ChaRM and monitoring based on MAI must be available promptly with the 7.2 go-live. This should not be the case for the Test Suite. This is because it requires time-consuming manual preparation, rebuilding and reworking.
3. Decoupling the question of "upgrade vs. new installation" from the intensity of use of selected applications, especially process documentation in 7.1: This means that no matter how intensively you use projects and their content (processes, technical objects, etc.) in 7.1: For a switch to 7.2, this never automatically means "prefer an upgrade scenario to a new installation".There may be good reasons to switch from the old (7.1) to a dewy 7.2 new installation, as projects from 7.1 can also be exported from 7.1 via the content activation paths provided by SAP and imported into a new 7.2 installation or (re-)activated there.
4. The definition of the system landscape to be managed by the 7 or its specific characteristics in the 7.2 solution management: This requires a clean connection/configuration of the systems to be managed (still with 7.2) and please always check all (still) required RfC connections, including connection and authorization tests. Otherwise, very little will work in terms of setting up the 7.2 solution administration.
5. The creative phase for developing new 7.2 support scenarios for projects and operations: I am thinking here in particular of the IT portfolio and project management as well as its application potential for the structured organization of upcoming project plans etc., including full integration into requirements and change management.

Conclusion:

Upgrade to 7.2 at your own pace. Set priorities on the basis and application side and activate the new world for your SAP solution landscape with a plan and a sense of proportion.