For many, homogeneous system copies aren’t as hot a topic compared to cloud replication and virtual machine transfers. However, if you have an SAP landscape on Windows/MSSQL—this is for you!
There are numerous technical and non-technical requirements to perform a homogeneous system copy of the SAP system running on the Windows\MSSQL platform:
- Hardware change
- Data center migration
- Operating system upgrades
- Building parallel landscape
- Additional landscape requirement
- Break-fix system build…
…and the list goes on. There can be several reasons why a standard homogenous system procedure may be performed. The standard SAP practices highlighted in the installation and master guides are all you need. However, there are numerous best practices you can leverage to make these transitions faster and easier.
8 steps to a smoother homogeneous system copy transition
If you want to improve your approach to homogeneous system copies, I’ve highlighted the eight steps you can include in your project for a smooth transition.
1. Project planning & documentation
One of the best practices for any project is to get hold of the latest SAP documents & guides related to SAP Installation/System copy and Database specific procedure sap notes. After dissecting all documents, you can conclude with the Homogeneous system copy path. In a few cases, it can give you a run with a last-moment change of plan if you miss the prerequisites.
For instance: the SAP Product availability matrix should be referred to review the target Operating system, Database and SAP version compatibility.
PAM Link: http://support.sap.com/content/support/en_us/release-upgrade-maintenance.html
Also, a prerequisite support pack stack requirements depend on the target MSSQL Database version you choose (Example: SAP Note 2807743 – Release planning for Microsoft SQL Server 2019).
Once all the compatibility and combinations are sorted out, you can confidently propose the target platform and versions for your SAP System copy.
2. Infrastructure planning
No single approach for sizing depends on your scenario and problem areas. Moving to a new server allows for clearing the clutter and leaving behind unwanted data. Also, it may not be necessary to size the target server with precisely the same resources as the source system. Depending on system performance, you can either upscale or downsize the hardware requirements and work accordingly with the Infrastructure team.
3. Source system analysis
It is always good to capture key transactions and configurations before shutting down your SAP System on the old server. You may also want to copy important files and folders from the old server to the new server to retain the same configurations. For example, SAP profiles or parameters, job logs, transport directory, SAP PSE files, SAP kernel, and other content directories on the application server that fit your case.
4. Target server preparations
With a Windows operating system installed and ready to be consumed for your SAP System, you can have a bird’s eye view of the server configuration, paging, stage of the media required for SAP System copy, and so on.
5. Homogeneous system copy
For MSSQL database backup/restore method can be the preferred way of performing homogeneous system copy. But, the export/import method is another supported method not explored in detail here. For restoring database backup from a lower version to a higher version, you should refer to Microsoft documentation for compatibility and the cases where an intermediate database upgrade may be required at source.
Once the database restoration or restore-recovery is completed on the target server, the software provisioning manager can be used to perform a homogeneous system copy by providing some mandatory parameters.
6. Basic post steps
Basic post steps can include from a few to many activities. Regarding hostname changes or SID, changes can involve more configuration changes on the target SAP System. Some of the transactions that need attention are as below:
- STMS configuration
- SAP Logon group
- SAP RFC group
- ST03 updated server and data
- RFC changes
- Profile parameter implementation
- SAP Kernel upgrade
- Host file and services file changes at the OS level
- SAP Load generation (SGEN)
- Database backup job scheduling
- SAP Job release
7. Validations & go-live
Final validation is essential from the technical team, and a positive sign-off from business end-users is a must for Go-live. A dedicated timeframe should be allocated for this purpose, followed by a go/no-go decision.
8. Post-go-live documentation
Even after successfully delivering your SAP System, reviewing all the documentation created during the whole process, timelines, efforts, and other related key data will help plan the same activity in future or present in front of the management team.
Hope this article has covered all the steps required for a successful SAP system copy in the case of the Windows\MSSQL platform. But it is just like a drop in the ocean of emerging methodologies & practices. Feel free to rectify or append your expert opinion in the comments section!