HANA Migration Monitoring Best Practices

There's a line in the sand: SAP customers need to be on SAP HANA in the near future. The most advanced organizations running SAP have already taken the necessary steps to migrate to the cutting-edge performance of HANA. As hardware costs fall, it's becoming easier for mid-level management to both implement the new database and to prove ROI. Falling prices and the defined deadline mean more and more companies are ready to take migration on.

But migration isn't ever quite that simple. We've compiled this list of tips to help you achieve HANA migration successfully through careful monitoring. When your company decides to make the switch, pull up this list before you get started.

Best Practices for SAP HANA Migration Monitoring

Let's get some important facts out of the way: in order to actually accomplish all of this, you have to be certified. Every migration involves months of preparation. Lots of people will likely be involved. And there are multiple phases: prep, uptime, downtime and post processing. Let's look at best practices in each of these phases.

Prep Phase

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 of 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.

You can do this one of two ways: Hit the start and end button for every transaction and log the times manually; or employ a robust monitoring solution that will do both of those actions for you. Remember that once you start to migrate, the former system is down and you can't look at the data you take manually. If your monitoring solution retains that data, you can. Best practice? Get a monitoring solution that retains data, and benchmark thoroughly before starting the migration. Get months worth of data. It sounds like a lot, but it's really just "enough."

It is also exceedingly important that you identify which profile parameters are important to your organization and document their values. Parameters could be technical such as memory buffer settings, but can also get into audit based settings such as system security. You then need to monitor and the value they should be once you've migrated. Because the typical migration doesn't involve such careful monitoring and the typical outcome doesn't allow for automatic parameter discovery, there's no way to cut down the time spent trying to detail and set up your same profile parameters once you're on HANA — unless you use a solution such as Xandria to auto detect the defined settings. Best practice? Implement a monitoring solution that watches profile parameters at the OS level and can detect  specific parameters important to your organization. Once the system comes back up it will ensure that everything is in its place. Bonus points: It provides proof for auditors.

Downtime Phase

The downtime phase is the piece of a migration many engineers dread most. Best practices dictate you monitor both source and target during downtime. Because SAP goes down during migration, you won't be able to see this phase with standard tools that utilize SAP's internal monitoring tool set.

You need a monitoring option that looks at the database, memory and CPU and keeps log files of what happened during the migration. Using internal monitoring tools such as CCMS, all servers running SAP will not be visible . You should be able to receive alerts, too. Let's say, for example, that you found some large tables during the benchmarking phase 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. Migration tools fail all the time; you need to be able to see and anticipate those failures.

Once the SAP HANA migration starts, monitoring comes into play because you need to monitor the process itself. Everything will be using resources during this time, and you should always know how much of each resource is being allocated and where.

Post Processing

Once the system is up you should be making sure all of the profile parameters that were discussed earlier are correctly in place prior to handing the migrated system over to the business. As mentioned, parameters could be technical such as memory buffer settings, but can also get into audit based settings such as system security. Benchmarking of before and after performance, parameter values will allow you to verify successful HANA migration and hand it to the business for Hypercare

HANA Hypercare

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. HANA has a few new KPIs; best practice is to implement a monitoring solution that can identify which checks are missing or present.

Once proper operation has been verified for a few days and the proper checks have been implemented, the system is ready to go back to normal operation. If you are not sure how to set up HANA health monitoring you may want to read the post discusssing the crucial HANA health checks you must do to ensure proper operation of your HANA system.

PS. We've lately published a case study of HANA monitoring with one of the largest European retailers. You can read more about it here