S/4HANA migration is never simple. An expert panel discusses the challenges and how to plan for the day after S/4HANA Go live.
Whether you’re excited about it or not, migrating your SAP environment is probably somewhere on your roadmap over the next few years. As you’ve probably heard, it is not a straightforward process and could take a lot of resource, energy, effort and money.
Unfortunately, there is no easy ‘cookie-cutter’ or plug-and-play solution to ensure a successful migration. Every SAP landscape is unique and offers its challenges. Many organizations embarking on their HANA journey spending a significant amount of time finding best practices to follow from those who have already made their pilgrimage.
However, one critical piece often gets overlooked.
This one very simple component, if done correctly, can help demonstrate the ROI of moving to HANA, reduce the time and effort of the actual migration and can reduce the security risk related to the migration before business users starting to use the new HANA system. Lastly post migration it can improve business and performance efficiency and performance transparency. What is this often-overlooked concept? One word: Monitoring.
It may sound boring and something only your Basis team would care about, but this is not the case.
What constitutes a successful migration? That’s a multilayered question as it depends who you’re asking – the Basis team will answer from a purely technical standpoint of were they successful in migrating the data. But your management and business end users are looking to see if the system is actually performing better. Has the process resulted in better ROI? Was the migration justified and resulted in improvements to the organization?
Each organization is different and unique. Setting up a performance baseline – allowing the company to compare before and after migration performance, will help define what will be considered a successful migration in all levels not only the purely technical.
Prep stage – pre Migration
Start with benchmarking. It sounds like common sense, but this part of the prep phase is critical to your overall success and is one that many organizations don’t do well — if they do it at all. In this part of the migration, you need to mark the times the current system runs at. There are thousands of screens/transactions and jobs to run, and you need to be able to measure performance before and after the migration to ensure proper continuity of the business operations as well as to show your ROI after the migration. That means you need to understand the details as they exist prior to change.
To do so, you need to understand your existing pre-migration system performance, not only from a technical perspective, but also the end user perspective. To achieve this, a benchmarking project needs to put into place.
The baseline should include at least the following items:
- Background processing (or batch jobs)
- End user experience (dialog response time)
- The longest running transaction codes
- Any other components, processes and KPIs that may be important to your organization.
The problem is that there are hundreds, if not thousands, of background jobs, end users and transaction codes. This is where a good monitoring tool can come into play. A well-versed tool can easily parse, report and save this information so it is readily accessible after your migration.
Remember, your current system may not be available after the migration is complete. It is important to note, the benchmarking process should take place months in advance. Many business processes within an SAP system may not regularly occur but are just as critical as a daily process. This includes things such as month-end closing, quarterly billing, etc… Plan your benchmarking with these processes in mind.
During the Migration – Downtime Phase
The migration itself is an extremely technical procedure, and proper technical monitoring procedures are essential especially during the phase in which SAP goes down for the migration, leaving no visibility to the operating system and database. Creating a security risk and information gap – a window of time where the system security was not being monitored.
How can you monitor and ensure the health of the database and the operating system during the migration if the SAP system is down and you’re practically blind? Do you watch the source (current systems) and the target (the new HANA) system?
While the system or parts of it are down, your systems might be exposed to security threats, you want to make sure you don’t have an information gap, and that your systems are being monitored for changes that are not in accordance of your security policy and log every activity done in the system. Using internal monitoring tools such as CCMS, all servers running SAP will not be visible. You should be able to receive alerts, too, as migration tools fail all the time; you need to be able to see and anticipate those failures.
For example, you’ve found during the benchmarking phase, some large tables that the HANA migration tools may have issues migrating. In the migration tool, there’s no set order to which tables migrate when, so you want to be able to send/receive notifications based on log files created during the downtime phase.
All that time and effort of benchmarking become useful at this stage. The data collected earlier on the longest running jobs and transaction codes can now be used to identify specific tables that may be large and troublesome. As the migration from the standard database to HANA occurs, these large tables go through a complex conversion. Due to their importance and complexity, many technical migration experts want to know when these specific tables are being migrated and may even want to manually watch the process.
Instead of sitting around and waiting for the tables to migrate, you need to make sure you have the tools to monitor the logs and automate a message to the migration expert as needed. This not only applies to tables, but also to any issues or errors the system experiences during the migration.
As the development and quality systems are migrated, critical issues can be identified in advances and be fixed before they cause a complete failure of the production migration. By identifying those issues, monitoring the log files, and automating alerts one can ensure the proper support staff can respond to an issue before it becomes a problem.
Ready for post migration? Join an expert panel discussion about the challenges and what you need to plan for the day after S/4HANA Go live.
The tough part is over, the migration is complete. But as all the basis and technical staff know, there is still some easy, yet often overlooked work, that needs to be done prior to handing the system off to the business.
Many companies have very strict auditable guidelines such as password criteria (e.g. length, special characters, etc.), making sure DDIC and SAP* (SAP admin credentials) are secured, and that the system is overall locked down before even one end user jumps on the system. These are things that were checked in the initial system setup but had to be unlocked during the migration. All these changes need to be setup manually post migration to ensure the system’s security and compliance.
Many organizations can only allow certain windows of downtime before they require the system (now as a HANA system) back to run their business. While these are easy tasks to complete, they do take a lot of manual time, get rushed, and things get missed. Six months later these things creep up during the yearly audit and are not fun to deal with. This process needs to be automated, and a good monitoring tool can complete these checks with zero manual effort, ensuring the system is properly secured immediately after the migration but before handing it off to the business for end-user use.
Once the system is fully migrated and handed over to the business, it goes into hypercare. In the first couple of days, everyone is on high alert due to the many unknowns you’ll experience just after coming out of a migration. During this phase, a robust monitoring and analysis solution will help ensure everything has been properly brought to the target and pinpoint any areas in which the system is under performing. S/4HANA has a few new KPIs; best practice is to implement a monitoring solution that can identify which checks are missing or present.
But this is not all
As the new system is getting into regular business use all the information collected during the benchmarking process can be utilized to compare performance, show successful migration results, and justify the time and effort invested in the migration. While there are some similarities, monitoring a HANA environment offers new challenges compared to a standard ABAP system. To ensure the system health, new HANA monitoring checks should be put in place.
We would like you to join an expert panel discussion about the challenges and what you need to plan for the day after S/4HANA Go live
This article is sponsored by syslink Xandria