10.4 Conversion Tools
In this section, we’ll present the conversion tools available to start the preparations for your system conversion.
10.4.1 Maintenance Planner
The Maintenance Planner is a web-based tool that helps in understanding the prerequisites for system conversion. Executing the Maintenance Planner is mandatory to complete the system conversion checks of business functions and add-ons in the system to identify whether SAP supports the system conversion.
If the system conversion is supported, the Maintenance Planner tool generates a stack configuration (stack.xml) file that is needed to execute the SUM tool. SUM is a tool for general maintenance that can be used to support your system conversion from SAP ERP to SAP S/4HANA, as well as to do other activities, such as combine, update, and migrate to SAP HANA in the Database Migration Option (DMO).
Note
You can directly launch Maintenance Planner using via the following:
https://apps.support.sap.com/sap(bD1lbiZjPTAwMQ==)/support/mp/index.html
It’s important to identify the steps you need to take before the system conversion is initiated (prechecks) and ensure the consistency of business processes postconversion. To execute prechecks, you need to execute SAP-delivered (through SAP Note 2182725) report R_S4_PRE_TRANSITION_CHECKS and fix the errors. This is an iterative process until all issues in the report output are resolved. SUM also executes all these prechecks during the conversion process.
10.4.2 Custom Code Migration Worklist
The Custom Code Migration Worklist (Transaction SYCM) helps you check your customer self-developed custom code. This activity needs to be performed to ensure that custom code can migrate to the SAP S/4HANA system without any issue and that all the custom objects continue to work as expected. The activity also gives you an opportunity to cleanse the custom code, remove obsolete objects that aren’t being used, and also adapt them to maximize performance.
The checks are based primarily on the SAP S/4HANA simplification list concept.
SAP Simplification List
SAP prepared for each release of the SAP S/4HANA collection of individual simplifications items that inform you of what needs to be taken into consideration during the system conversion from an SAP Business Suite to a target SAP S/4HANA system.
The simplification items classification is by description, business impact, recommendations, and relevant SAP notes to guide prechecks and custom code checks.
The simplification list is available at the http://help.sap.com.
The approach provided by the SAP simplifications list to analyze the custom code is as follows:
- Run the Custom Code Analyzer (program SYCM_DOWNLOAD_REPOSITORY_INFO) in the system as described in SAP Note 2185390 (Custom Code Analyzer).
- Schedule program SYCM_DOWNLOAD_REPOSITORY_INFO as a background job to update the where-used index.
- Rerun the same program in the foreground, and click Download ZIP File.
- Export the file from the source system, import it into the evaluation system, and analyze the code.
10.4.3 SAP HANA Sizing
In this section, we’ll discuss how to translate your business requirements into hardware requirements, that is, how to size your SAP S/4HANA system.
The purpose of this book is to cover the SAP S/4HANA logistics functionality, but it’s relevant to walk through this fundamental concept of sizing for your reference. We’ll also include detailed technical information if you need to expand the SAP S/4HANA sizing in more detail.
Sizing Fundamentals
In an SAP HANA platform, performance is the most important factor. In this section, we’ll show you the four main sizing components.
Memory Sizing
Memory is the main driver for data sizing, and it’s determined by the size of the data footprint in SAP HANA. The data is composed at the column and row store of metadata and business data.
The SAP HANA database includes at least the following memory areas: code, stack, caches, operating system, and system files. Memory areas sizing is a small portion of the total memory but needs to be taken into consideration. The main two memory components are the size of table data and the working memory.
The table data is located in the compressed column store of SAP HANA, and the working memory component size is almost the same size as the table data component.
CPU
The SAP HANA in-memory technology requires more CPU power due to the parallel processing capabilities. Compared with the old relational database management systems (RDBMSs) that don’t offer these processing capabilities, he CPU power offers the optimal response time required by SAP HANA and should be part of the sizing exercise.
The sizing recommendation for the CPU is measured in SAP Applications Performance Standard Units (SAPS). SAPS is a measurement unit that describe the throughput of hardware in an SAP environment. SAPS is derived from SAP ERP Sales and Distribution (SAP ERP SD) from the standard application benchmark of measuring the number of fully processed order line items in one hour.
Note
SAPS measures the number of order lines items processed in one hour (100 SAPS = 2,000 processed order line items in 1 hour).
For example, a 16 processor, 244 core high-end server has a total CPU power of approximately 500,000 SAPS. Or you can process approximately 10 million sales order line items per hour, which is 2,777 sales order line items per second.
Disk Size and Disk Input/Output
Data persistent layers and logging data is stored in disk. The size of the disks depends on the type of store proposed.
The second factor is the required I/O performance required to ensure that your system runs with an acceptable data throughput and the required storage system latency.
Frontend Network Load
Always neglected, this is a critical element to ensure good performance of your SAP HANA platform. The network focuses on the network bandwidth, which is measured in gigabits per second (Gbps). If you’re planning to use cloud services, the cost of the network and bandwidth required to connect with your cloud provider is an important factor when selecting your cloud vendor.
The sizing has three main models: user-based sizing model, throughput-based sizing model, and customer performance test model.
Sizing Models
The user-based sizing model is based on the total number of estimated end users that work in the system. The process is simple but inefficient because it doesn’t provide the throughput that the counted users produce.
A more detail-orientated method is the throughout-based sizing model. Following this model, you base your sizing estimates on assumptions of activity estimated per each user. The quality of your analysis depends directly on the quality and detail of the assumptions and data provided by the model.
The customer performance test model relies on the ability of your organization to use actual historical data, sourced from your current systems, and test assumptions to find the parameters to size your future system. This model is more accurate that the two mentioned before, with the disadvantages of cost and time that your organization needs to complete the model.
The sizing of your systems is a joint effort among your organizational technical team, SAP, and the hardware vendor or cloud vendor.
Sizing Tools
SAP offers the following sizing tools: SAP Quick Sizer tool, sizing decision tree, guidelines, and specific SAP notes.
The SAP Quick Sizer tool supports sizing based on user-based sizing and throughput-based sizing. The questionnaire provided by SAP calculates the memory requirements and CPU requirements to define an estimated sizing result. The tool is available online to SAP Customers and SAP Partners.
The sizing guidelines depend on the SAP S/4HANA architecture, which can be a scale-out or scale-up architecture. The scale-out architecture increases the database memory size in your system landscape, and it’s based on the installation of multiple servers. It consists of one master node and three slave nodes. (For details, refer to the SAP S/4HANA on scale-out sizing guideline provided by SAP.) The scale-up architecture, on the other hand, is based on a single server. (Refer to the SAP Note 1872170 for the specific sizing guideline for SAP S/4HANA scale-up architectures.)
Sizing Types
The sizing types most commonly available depend on the type of SAP S/4HANA implementation that you’re performing, that is, either a greenfield implementation or a conversion of your current SAP Business Suite legacy system.
Greenfield Implementation Sizing
For an SAP S/4HANA greenfield implementation, a holistic analysis is required of all the different components that define the system sizing and performance requirements. For this, SAP provides the Quick Sizer tool, as mentioned previously.
Data aging is an important factor to consider in the data calculations for reducing the memory footprint of your SAP HANA system. It relies on the concept of managing current data (hot data), which resides in the main memory of SAP HANA. It also defines your historical data (cold data), which is moved and stored on disk, reducing the risk of affecting the performance of the SAP HANA system. Quick Sizer also contains data aging logic to estimate the required memory aging period and logic for the disk to estimate the archiving period. Your Technical team also can use guidelines with specific formulas to get a more detail sizing approach.
The SAP S/4HANA embedded analytics functionality covered in Chapter 9 is an important sizing requirement to take into consideration to ensure the correct CPU performance.
System Conversion Sizing
If you’re converting a legacy SAP Business Suite system to a target SAP S/4HANA system, you can use an SAP sizing report, which is executed in your source system and is at least in the SAP BASIS 620 or higher version.
This report estimates the memory consumption of the database. In terms of the new SAP S/4HANA system, it takes into consideration all different factors that will take place after the system conversion. It considers, for example, the estimated distribution of tables to the in-memory row and column store, the compression ratios, and the differences for secondary indexes.
SAP Note 1872170 refers to the SAP Business Suite on SAP HANA sizing report.
10.4.4 Technical Conversion Realization
After you’ve completed the activities listed in the prepare phase, you can move to the realization phase and start the SUM tool execution.
Software Update Manager
As mentioned earlier, SUM is the technical tool used for the system conversion to SAP S/4HANA. Transactions SPDD/SPAU adjustments are carried out during the SUM execution as the tool prompts you to make the adjustments.
Application-specific follow-on activities are executed after the SUM execution is complete. After the technical system conversion is complete, you need to manually perform the finance Customizing and data migration activities through the IMG (Transaction SPRO). SAP has provided the list of activities to be carried out. It’s important to note that you should perform these activities sequentially and not skip any applicable steps. Don’t perform any activities, such as posting SAP documents in the system, until these steps are complete.