To reduce risk larger organisations are breaking their journey into several steps to SAP S/4HANA. Upgrade of the core ERP system onto the SAP HANA database platform is the first logical large step. To answer the question I reached out to my team: on HANA migration how one can ensure the success of an SAP Business Suite? What I found out has been mentioned below.
1. A full-size production copy should be started with
This is a mistake to start with your first system as a development system, although it can be tempting. As soon as possible on a real full-size copy you need to cut your teeth, because on a real system only you will see how it is like to work.
The full database size should be included in a production copy, and for a cutover plan you have the beginnings of the timings, on a simulation of production you can build a detailed run book based, and the current code set (a different code-base to production is what the development systems often have) is what you have.
2. Housekeeping should be started early
You don't want to be wasteful with database space if you have an in-memory database like HANA, before you get to HANA start a spring clean and delete all the data you don't need as it is useful. It cleans up hundreds of gigabytes, even terabytes of database typically as we have a standardized process for this. 1.2TB in size housekeeping table was found in one client.
Housekeeping often takes 2-6 months to complete which is because of the amount of data that needs deleting. A really long time can be taken by the clean-up jobs to run, and by being too aggressive you should not impact business operations.
3. Burn in your production hardware
On Sunday at 4am when you cutover to your new HANA database, if it will be reliable is what you want to know. Install the production hardware early, as a High Availability (HA) cluster configure it and then for 1-2 mock migrations use it which is what we always recommend.
You could even use it for your first sandbox iIf it's ready in time, (see point 1). For some time prior to cutover either way, you want it running, so prior to production migration any teething hardware configuration errors are resolved.
4. In other infrastructure changes consider rolling
The number of test cycles is the primary cost driver of a HANA migration. To can improve stability and reduce TCO you should consider rolling in additional changes because you will be thoroughly testing it.
Including Linux Application Servers, VMWare, Unicode Conversion, Enhancement Pack upgrades in the past we have rolled in all manner of changes.
5. The entire application landscape should be looked at
At the core of your SAP environment the Business Suite system exists and in the application support area of your organization it will touch almost everyone. This means to update other areas at the same time, like BW, Portals, or Solution Manager there is an opportunity.
Project management office, Basis, ABAP and Test Management resources are already available, and compared to doing a separate update at a later time extending the scope is incremental.
6. Test Management Focus
Mature SAP R/3 environments have been in place for 10-15 years or more with many clients. They had a solid test management process when they were implemented but there has been degradation over a period of time, the quality and structure of test management.
The first step for organizations to get to S/4HANA is the SAP Business Suite on HANA and in the years to come there will be more testing, so a good job of test management is what it really makes sense now. As compared to business process your test coverage should be evaluated, ensure where appropriate the modern tools are in place and look at test automation.
7. For custom code remediation use the right tools
Over the last decade within SAP environments, custom code has ballooned rather like test management. Clients with 30-50,000 custom code objects are often seen, and there is no usage of 30-80% of this code. For the 2009 year end close Reports were written and since then it has never been run.
On HANA custom code remediation is critical to do, because by default your custom code will not be optimized and to optimize the Business Suite on HANA SAP spent a lot of time. Severe performance problems and issues with functionality can result in.
With tools like Custom Code Cockpit (CDMC), Usage & Procedure Logging (UPL) and Clonefinder,SAP Solution Manager is the starting point for this, which help in understanding custom code.
With tools like smartShift one can partner which from your existing system takes the custom code and to automatically remediate your custom code applies a set of algorithms such as the cost reduction, and human error.
8. Critical processes are identified and benchmarked
Your business users will expect lightning speed once you mention the word HANA. On HANA project the expectations of a Business Suite will be high, and a lot of excitement will be there!
Those processes that are important to the business should be identified and should be benchmarked. Some critical month end reports might be, but it was an approval mobile app in one client’s case for promotions - C-suite executives is used by this app.
Ensure they are measured as part of the test process once they are benchmarked today, and for the HANA platform additional focus can be put on ensuring they are optimized. The communication strategy helps this.
9. Early in place get the right project assets
To a Business Suite on HANA migration there are a few project assets which are specifically important. In the project library it is recommended that you get this place, in a shared location available to all, and regularly update them.
a. Run Book is the first, step-by-step guide to the migration and a few hundred pages it typically spans. It means that, due to unforeseen factors if at the last minute you need to switch out resources, to look after the next step of the project very experienced resource can be brought. In addition to this it ensures that mistakes are less likely to be made at 5am on a Saturday morning at the end of a long shift.
b. A set of project plans is the second option. 3 levels: High-Level, Mid-Level and Detailed are recommended.
- High-level plan: With the steering group it is used to communicate, and on it the milestones are defined, so where the project is at a weekly granularity in PowerPoint can be seen by a C-suite stakeholder.
- Mid-Level plan: Onto a large sheet of paper it is typically printed and can be read by human, so progress can be understand by all project members; in Excel it is usually planned at a day-by-day level.
- Detailed project plan: It is often several thousand lines long and is in Microsoft Project, and by the Project Management Office it is updated.
10. An extended hypercare optimization phase should be added
Despite taking care with custom code optimization, test management and good planning it has been ave found that between the cracks a few performance issues will fall and on HANA some processes may be slower, because for a disk-based RDBMS they were optimized. In addition, than your old database because HANA is so much faster, in the production system some processes will need to be reshuffled, so batch Windows can be reduced.
Run an extended hypercare is recommended for both of these reasons. After month end a go-live window is typically 1-2 weeks, rather than the usual 2-week window for 6-8 weeks after that it is recommended to run. To capitalize on the benefits early this enables to take advantage of the HANA platform improvements immediately and the existing project team is used.
11. Remember it is a technical migration
The Business Suite on HANA migration in most cases is a purely technical exercise. Unlike S/4HANA where there will be a new UX (Fiori), process changes etc. On HANA you can get onto the Business Suite and after that on the cool things like the Fiori UX, HANA Live etc one should focus on.
What this means is with your timeline you can afford to be aggressive. Planning, testing and executing still need to be done, but to move quickly is possible, and be averse to risk. For example, in 8 weeks to HANA in the manufacturing industry we have moved a large SAP BW client, and to HANA in 16 weeks a large SAP ECC client, including thousands of test cases and a large amount of code remediation.
12. The following sun is considered
Across three time zones that operate as a single unit we have a cohesive, global Basis team. How each other works they know, and a shared approach and document storage are there with them.
More than anything else, it accelerates the migration phases of the projects and has some cost advantages. In addition, it means that it gives much more accurate early timings as even the first migrations are run 24/7.