Tips for a successful SAP Business Suite on HANA migration

Good article from John Appleby, Bluefin Solutions. 

Larger organisations are breaking their journey to SAP S/4HANA into several steps to reduce risk. The first logical large step is the upgrade of the core ERP system onto the SAP HANA database platform. But how do we ensure the success of an SAP Business Suite on HANA migration? Here’s how…

1. Start with a full-size production copy

It can be tempting to start with your first system as a development system, but this is a mistake. You need to cut your teeth on a real full-size copy as soon as possible, because it’s only here that you will see what it’s like to work on a real system. A production copy will have the full database size, and so you have the beginnings of the timings for a cutover plan, you can build a detailed run book based on a simulation of production, and you have the current code set (development systems often have a different code-base to production).

2. Start housekeeping early

When you have an in-memory database like HANA, you don’t want to be wasteful with database space, so it’s useful to start a spring clean and delete all the data you don’t need before you get to HANA. We have a standardized process for this and it typically cleans up hundreds of gigabytes, even terabytes, of database. In one client, we found a housekeeping table that was 1.2TB in size. Because of the amount of data that needs deleting, we often find that housekeeping often takes 2-6 months to complete. The clean-up jobs can take a really long time to run, and you don’t want to impact business operations, by needing to be too aggressive.

3. Burn in your production hardware

When you cutover to your new HANA database on Sunday at 4am, you want to know that it will be reliable. We always recommend the production hardware is installed early, configured as an High Availability (HA) cluster, and then used for 1-2 mock migrations. If it’s ready in time, you could even use it for your first sandbox (see point 1). Either way, you want it running for some time prior to cutover, so any teething hardware configuration errors are resolved prior to production migration.

4. Consider rolling in other infrastructure changes

The primary cost driver of a HANA migration is the number of test cycles. You should consider rolling in additional changes so you can improve stability and reduce TCO because you will be testing so thoroughly. In the past we have rolled in all manner of changes including Linux Application Servers, VMWare, Unicode Conversion, Enhancement Pack upgrades, etc.

5. Look at the entire application landscape

Your Business Suite system is at the core of your SAP environment and will touch almost everyone in the application support area of your organization. This means there is an opportunity to update other areas at the same time, like BW, Portals, or Solution Manager. You will have a project management office, Basis, ABAP and Test Management resources already available, and extending the scope is incremental compared to doing a separate update at a later time.

6. Focus on Test Management

Many clients have mature SAP R/3 environments, which have been in place for 10-15 years or more. When they were implemented they had a solid test management process but over a period of time, the quality and structure of test management has degraded. The SAP Business Suite on HANA is the first step for organizations to get to S/4HANA, and there will be more testing in the years to come, so it really makes sense to do a good job of test management now. Evaluate your test coverage as compared to business process, ensure you have modern tools in place and look at test automation where appropriate.

7. Use the right tools for custom code remediation

Rather like test management, custom code has ballooned within SAP environments over the last decade. We often see clients with 30-50,000 custom code objects, and 30-80% of this code isn’t even used. Reports were written for the 2009 year end close and never run since. It is critical to do custom code remediation on HANA, because SAP spent a lot of time optimizing the Business Suite on HANA, and your custom code will not be optimized by default. This can lead to severe performance problems, and issues with functionality. SAP Solution Manager is the starting point for this, with tools like Custom Code Cockpit (CDMC), Usage & Procedure Logging (UPL) and Clonefinder, which help you understand your custom code.

8. Identify and benchmark critical processes

You mention the words HANA, and your business users will expect lightning speed. The expectations of a Business Suite on HANA project will be high, and there will be a lot of excitement! It’s important to identify those processes that are important to the business, and benchmark them. This might be some critical month end reports, but in one client’s case it was an approval mobile app for promotions – an app used by C-suite executives. Once you have benchmarked them today, you can ensure they are measured as part of the test process, and additional focus can be put on ensuring they are optimized for the HANA platform. This will help with the communication strategy.

9. Get the right project assets in place early

There are a few project assets which are specifically important to a Business Suite on HANA migration. We recommend that you get this in place in the project library, available to all in a shared location, and update them regularly.

a. The first is the Run Book, which is a step-by-step guide to the migration and typically spans a few hundred pages. It means that if you need to switch out resources at the last minute, due to unforeseen factors, you can bring in a very experienced resource to look after the next step of the project. In addition to this it ensures that at 5am on a Saturday morning at the end of a long shift, mistakes are less likely to be made.

b. The second is a set of project plans. We recommend 3 levels: High-Level, Mid-Level and Detailed.

High-level plan: used to communicate with the steering group, and it has the milestones defined on it, so a C-suite stakeholder can see where the project is at a weekly granularity in PowerPoint.
Mid-Level plan: typically printed onto a large sheet of paper and is human-readable, so all project members can understand progress; it’s usually planned at a day-by-day level in Excel.
Detailed project plan: is in Microsoft Project, and often several thousand lines long, and updated by the Project Management Office.

10. Add an extended hypercare optimization phase

We have found that despite taking care with custom code optimization, good planning, and test management, a few performance issues will fall between the cracks and some processes may be slower on HANA, because they were optimized for a disk-based RDBMS. In addition, because HANA is so much faster than your old database, some processes will need to be reshuffled in the production system, so you can reduce batch Windows. For both of these reasons, we recommend you run an extended hypercare. A go-live window is typically 1-2 weeks after month end, and we recommend you run it for 6-8 weeks after that, rather than the usual 2-week window. This enables you to immediately take advantage of the HANA platform improvements and use the existing project team to capitalize on the benefits early.

11. Remember it is a technical migration

In most cases, the Business Suite on HANA migration is a purely technical exercise. It’s not like S/4HANA where there will be process changes, a new UX (Fiori) etc. You can get onto the Business Suite on HANA and after that focus on the cool things like the Fiori UX, HANA Live etc. What this means is that you can afford to be aggressive with your timeline. You still need to do a great job of planning, testing and executing, but it is possible to move quickly, and be risk-averse. For example, we have moved a large SAP BW client to HANA in the manufacturing industry in 8 weeks, and a large SAP ECC client to HANA in 16 weeks, including a large amount of code remediation and thousands of test cases.

12. Consider following the sun

We have a cohesive, global Basis team across three time zones that operate as a single unit. They know how each other works, and they have a shared approach and document storage. This has some cost advantages, but more than anything else, it accelerates the migration phases of the projects. In addition, it means that even the first migrations are run 24/7, which gives much more accurate early timings.