SAP HANA migration:12 tips for success
The following post was originally published by Bluefin Solutions, a Mindtree company and global SAP consultancy that specializes in technology strategy, implementation and change.
Larger organizations 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. I reached out to my team to answer this question: How do we ensure the success of an SAP Business Suite on HANA migration? Here’s what I found out.
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 full-size copy as soon as possible, because that’s the only way to see what it’s like to work on a real system.
A production copy will have the full database size. Because you’ll have the beginnings of the timings for a cutover plan, you can build a detailed runbook based on a simulation of production—and you’ll have the current code set (development systems often have a different code base than production).
Begin 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 deleting all the data you don’t need before you get to HANA. At Bluefin, we have a standardized process for this that typically cleans up hundreds of gigabytes—even terabytes—of data. For one client, we found a housekeeping table that was 1.2TB.
Because of the amount of data that needs deleting, we find that housekeeping often takes two to six months to complete. The cleanup jobs can take a really long time to run, and you don’t want to impact business operations by needing to be too aggressive.
Burn in your production hardware
When you cut over to your new HANA database on, say, a Sunday at 4 a.m., you want to know that it will be reliable. We always recommend installing production hardware early, configured as a high availability (HA) cluster and used for one or two mock migrations.
If it’s ready in time, you could even use it for your first sandbox. Either way, you want it running for some time prior to cutover so any teething hardware configuration errors are resolved prior to production migration.
Consider rolling in other infrastructure changes
The primary cost driver of a HANA migration is the number of test cycles. 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 and more.
Look at the entire application landscape
Your Business Suite system is at the core of your SAP environment, and it will touch almost everyone in the application support area of your organization. This means you have an opportunity to update other areas at the same time, such as Business Warehouse, Portals or Solution Manager.
You will have Project Management Office, Basis, ABAP and Test Management resources already available, and extending the scope will be incremental compared with doing a separate update later.
Focus on test management
Many clients have mature SAP R/3 environments that have been in place for 10 to 15 years or more. When they were implemented, they had a solid test management process; but over time, the quality and structure of test management have 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 only makes sense to do a good job of test management now. Evaluate your test coverage as compared with your business process, ensure you have modern tools in place and look at test automation where appropriate.
Use the right tools for custom code remediation
Rather like test management, custom code has ballooned within SAP environments over the past decade. We often see clients with 30,000–50,000 custom code objects, and 30–80% of this code isn’t even used. Reports written for the 2009 year-end close have never run since.
It’s 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 your starting point for this process, with tools such as the Custom Development Management Cockpit (CDMC), Usage and Procedure Logging (UPL) and Clone Finder, which help you understand your custom code. We also partner with tools including smartShift, which takes the custom code from your existing system and applies a set of algorithms to remediate it automatically, thereby reducing cost and human error.
Identify and benchmark critical processes
If you mention the name HANA, your business users will expect lightning speed. The expectations for a Business Suite on HANA project will be high, and there will be plenty of excitement.
It’s important to identify processes that are important to the business and benchmark them. This might mean 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 benchmark these processes, you can ensure that they’re measured as part of the test process, and additional focus can be put on ensuring that they’re optimized for the HANA platform. This will help with the communication strategy.
Get the right project assets in place early
A few project assets are specifically important to a Business Suite on HANA migration. We recommend getting them into a project library that’s available to everyone in a shared location, then updating them regularly.
The first is the runbook, a step-by-step guide to the migration that typically spans a few hundred pages. If you need to switch out resources at the last minute due to unforeseen factors, the runbook means you can bring in an experienced resource to look after the next step of the project. It also helps ensure that at the end of a long shift, resources are less likely to make mistakes.
The second key asset is a set of project plans. We recommend three: high level, midlevel and detailed.
- High-level plan: Used to communicate with the steering group, this level includes defined milestones so a C-suite stakeholder can see where the project is with weekly granularity in PowerPoint.
- Midlevel plan: Typically printed on a large sheet of paper so it’s readable by humans, this level ensures that all project members can understand progress. It’s usually planned out day-by-day in Excel.
- Detailed plan: This level lives in Microsoft Project. It’s often several thousand lines long and gets updated by the Project Management Office.
Add an extended hypercare optimization phase
Despite careful custom code optimization, good planning and test management, we’ve found that a few performance issues will fall between the cracks. In addition, some processes may be slower on HANA because they were optimized for a disk-based RDBMS—and 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 these reasons, we recommend you run extended hypercare. A go-live window is typically one to weeks after the end of the month, and we recommend running hypercare for six to eight weeks after that, rather than the usual two-week window. This will let you take advantage of HANA platform improvements immediately and use the existing project team to capitalize on the benefits early.
Remember, it’s 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) and so on. After you get onto the Business Suite on HANA, you can focus on cool additions such as the Fiori UX, HANA Live and so on.
This means you can afford to be aggressive with your timeline. You still need to do a great job of planning, testing and executing, but it’s possible to move quickly and still be risk-averse. For example, we moved a large SAP BW client to HANA in the manufacturing industry in eight weeks and a large SAP ECC client to HANA in 16 weeks, including a large amount of code remediation and thousands of test cases.
Consider following the sun
We have a cohesive, global Basis team across three time zones that operates as a single unit. Each office knows the others work, 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 projects. It also means that even the first migrations are run 24/7, which gives much more accurate early timings.
As always, I’d love to hear about your experiences. Happy HANA-ing! Contact Bluefin Solutions, a Mindtree company, to learn more about how we can help.