Ensure HANA migration success: What to do before, during and after

HANA migrations are not simple.

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 time, 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 ensure your system is administratively configured correctly before business users starting to use the new HANA system. What is this often-overlooked concept? One word: Monitoring. 

What constitutes a successful migration? That's a multilayered question because it depends really who you're asking - the Basis team will answer from a pure technical standpoint of were they successful in migrating the data. But 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 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.

Prior to the HANA Migration

Monitoring has historically been viewed as a technical concept. However, with the proper SAP monitoring tool it can expand into business assessments and further ensure the ROI from a user and process perspective.

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 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, so a third-party system is critical to holding this information. Should you not have a tool in place already, please see this free HANA Migration checklist  that will help you manually track these components.

It is important to note, the benchmarking process should take place months in advance. Many business processes within a 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

The migration itself is an extremely technical procedure, and proper technical monitoring procedures are required. Most SAP monitoring tools only connect to SAP on the source system (current SAP system) and use SAP to gather database and operating system information. This leads to many issues, especially during the phase in which SAP goes down for the migration, leaving no visibility to the operating system and database.

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 target (the new HANA) system as well?

Monitoring needs to be setup and configured on both the source and the destination systems prior to the migration, to ensure it remains in good health during the migration. A wealth of issues could pop up on the HANA side during the migration which will lead to time, effort and money wasted on troubleshooting if monitoring is not configured prior.

Note the on the right side, migration process log files are being monitored as well, giving you a way to track and monitor for any unusual activity.

All that time and effort of benchmarking become useful at this stage. The data collected 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, a good monitoring tool can 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.

Post Migration

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.

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. Using this checklist you can complete your HANA migration benchmarking.

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. To find out more about these checks, please download the free HANA health checklist 

Picture reference: B Balaji