I'm writing this week's blog from the trenches on the front line of an SAP Upgrade & Migration project at a very large customer site about to go live. Back in June 2015, we published an SAP Performance Best Practices for Implementation, Upgrade & Migration article, and I wish this customer had read and implemented some of those best practices recommendations. Particularly regarding what I'm about to point out in this publication so you too may avoid the potential pitfalls. The scenario is an SAP ERP 4.7 to ECC 6.0 Ehp7 Near-zero Downtime (nZDM) upgrade, combined with a database upgrade and platform migration in the same go-live weekend. The culprit is missing performance baselines and historical stats on the source system pre-go-live to compare with the target system post-go-live!
Upgrade
SAP is stopping standard support of ERP 4.7 this year and we find that many customers are upgrading or planning to upgrade to the most recent ECC release. Based on the best practices, we recommend saving SAP workload statistics and/or having 3rd-party performance monitoring with saved history and baselines so that you can compare application performance before and after the upgrade and/or migration. There are additional steps required to retain the stats in an upgrade from releases prior to Netweaver 7.00 because of significant changes in the workload dictionary within SAP, particularly the MONI table which stores workload data. These 2 notes are useful and need to be planned ahead because they involve implementing corrections and manual steps in the upgrade pre and post-steps:
- 1005238 - Migration of workload statistics data to NW2004s
- 1006116 - Migration of workload statistics data to NW2004s (2)
Migration
If you are just doing a heterogeneous OS/DB migration, the standard SAP R3load tools and/or procedures will exclude the workload data. Thus it's best to keep the performance history somewhere you can access after the migration, such as Solution Manager if you have configured the BW to retain the workload or a 3rd-party tool that keeps that data off-host for reporting and analysis.
If neither of the above is possible, at a minimum the SAP Earlywatch report and Upgrade/Migration going live checks should be scheduled with SAP. These are remote services performed by SAP from India, and they need to be scheduled at least 4-weeks in advance:
- SAP Go-Live Analysis Sessions (before)
- SAP Go-Live Verification Sessions (after)
More information can be found here.
Key Takeaway
Don't be caught post-go-live without historical performance and baselines to help guide you in troubleshooting performance issues and comparing improvements or identifying optimization opportunities. Depending on the database and platform changes, there can be many more specific recommendations pertaining to performance best practices, however, at least take care of the SAP side.
Want to monitor your systems before and after the upgrade and compare performance baselines down to the transaction level all from the cloud? Subscribe to our cloud-based IT-Conductor. With a few clicks and a few minutes, you can monitor and alert your SAP systems. Truly SAP Performance management without the hassles!
