Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Vienna. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is an Appian and Pegasystems iBPM Low-code and RPA Value Added Service Partner. You can reach him at [email protected]
SAP HANA is the highly acclaimed technology innovation in recent years and nearly all SAP products introduced subsequent to SAP HANA have the capability to integrate with this platform. Far from being a conventional database, SAP HANA…
- Accelerates business processes
- Delivers greater business intelligence via advanced capabilities that simplify the IT environment
- Deploys its in-memory data platform on-site or in the cloud
When correctly implemented, SAP HANA conveys outstanding results and performance, analytic intelligence, integration capabilities, data processing, and improved ROI.
We have a great blog on this called The ABAP Developer Road Map to SAP HANA, it is definitely worth a read – especially if your a developer.
Business Suite on HANA (sometimes called SAP Suite on HANA) is the starting point for companies migrating SAP ECC solutions to the HANA platform. No application layer changes are required. It does not provide data simplification. Again, last month’s blog called What is SAP Suite on Hana (SoH) can fill you in on everything you need to know.
When correctly implemented, SAP HANA conveys outstanding results and performance, analytic intelligence, integration capabilities, data processing, and improved ROIs of the SAP landscape with swift time-to-value. Planning and executing a successful transition to the SAP HANA platform is crucial, and this article provides a detailed overview of ten tips that will help mitigate risks during your business’s migration to SAP HANA.
Right-sizing the SAP HANA landscape is a fundamental and indispensable step to developing your technical project plan. In addition, this first step will help you achieve the maximum benefit from your capital investment while keeping long-term cost of ownership at its lowest possible level. Both over-provisioned and inadequate sizing may result in excess capacity and hardware while inadequate sizing may result in delays that increase the costs associated with operational performance.
In general, the size of the SAP HANA database is based upon the main memory, and you determine this by the quantity of actual data stored in the memory. This may not be easy to estimate since data is compressed in SAP HANA, and the compression outcome depends upon the used scenario. You should use the SAP Quick Sizer tool, SAP sizing reports, and relevant SAP notes for appropriate memory sizing.
Right sizing SAP HANA comprises three steps:
- Memory sizing for dynamic and static data
- Disc sizing for retained data (persistence storage)
- CPU sizing for queries, transactions, and calculations
Sizing is an iterative process to translate business requirements into hardware requirements, and is usually performed early in the project. Find out more about sizing fundamentals and the tools available to help optimize your total cost of ownership in this document.
This video shows you how to translate your business requirements into hardware requirements to support your SAP HANA deployment and where to find additional sizing information.
Selecting the correct platform to fit your specific business needs, resources, and budget will enable you to migrate to SAP HANA seamlessly and quickly. SAP HANA may be deployed in the cloud for greater scalability, flexibility, and quicker time-to-value, or it may be deployed on-site for optimal control and minimized risks.
You will find an array of cloud deployment strategies. SAP offers SAP HANA Enterprise Cloud, which is its own cloud platform. It comes with the SAP HANA software license, SAP managed services, and the foundational cloud infrastructure. Commercial cloud IaaS providers will permit you to use your SAP HANA license with their offerings. These providers can include Microsoft Azure, IBM Bluemix Cloud Platform, Google Cloud Platform, and Amazon Web Services.
With on-site deployment, you select a certified SAP HANA apparatus from a SAP hardware partner. The apparatus will come with preinstalled software that will enable your business to fully utilize the real-time power that the SAP HANA in-memory platform provides. With the preconfigured method, both the hardware vendor and SAP will validate the solution. Another approach, the SAP HANA Tailored Data Center Integration, offers you greater flexibility. In addition, you may streamline the SAP HANA integration and minimize infrastructure investment by leveraging your existing operations and hardware in your data center.
Once you have selected your HANA deployment method, you will need to develop a migration strategy to minimize any unforeseen risks and reduce system downtime during the actual migration to realize quicker time-to-value.
A conventional migration is the most commonly used method for OS/DB migration, which is essentially a system copy using conventional tools such as Migration Monitor, R3load, or SWPM. The conventional, or classical, approach may be the best method is your system requires no version updates to operate on SAP HANA and you need only to execute the actual migration.
Other options may include the Database Migration Option of Software Update Manager (SUM), which combines Unicode conversion (if needed), technical migration, and system update with an optimized migration process from an ABAP-based SAP system to SAP HANA. The DMO of SUM provides streamlined migration steps, economized manual effort, and a single downtime period.
If your existing system produces many technical issues and the greenfield method with selective data migration seems appropriate, then you may wish to conduct a new installation of SAP HANA. This can be an efficient option for businesses that have standard SAP processes and expect to S/4HANA for a reduced data foot print.
SAP HANA provides you with advanced analytics and optimized business operations by analyzing large quantities of data in real-time. Therefore, data cleansing represents a crucial task prior to transitioning your SAP systems to HANA. This step is frequently overlooked. You will reap three major benefits from data cleansing:
- By migrating only necessary, quality data, SAP HANA will perform better subsequent to the technical migration
- Reduced data size will facilitate a reduced downtime during actual migration
- Smaller data foot print lessens your need for hardware, infrastructure, and SAP HANA licensing expenses
In general, you can remove application logs, technical data, and system logs, and you can archive aged business data to minimize the database size.
It may be tempting to cut costs by cutting corners during an actual migration endeavor; however, this is not the phase in which to achieve lower expenses. In fact, a very methodical approach is necessary to keep your focus on exemplary standards throughout activities from planning to cutover.
Your project team should have considerable practical experience and knowledge of technical migration processes, best practices (use the SAP Best Practice Explorer), and relevant SAP notes. If problems occur during the actual migration, your team will be better prepared and more likely to identify an appropriate solution quickly.
Ensure that your source systems are prepared for the migration to SAP HANA. While your source system version may be supported for the move, it is generally best to have the latest release. You receive the latest SAP fixes and solutions to routine problems with each release package. Ensure you have these in place prior to migration commencement.
Avoid unnecessary risks when migrating your database. Repeated backups are highly recommended, so ensure full backups and archive logs for regular restore points. Risk mitigation will help ensure a smooth migration. In short, eschew shortcuts and maintain the highest standards.
It is essential to conduct a proof of concept in a sandbox environment to validate and verify the migration process to SAP HANA. You perform this by copying your production system to construct a SAP sandbox environment. You conduct the technical migration on this sandbox environment first. This is an important step in the process. While it may result in some additional expenses to duplicate the environment, the benefits include:
- A reasonable estimate of how long the process will take
- Identification of potential problems and the ability to correct prior to implementation
- Full utilization of SAP HANA capabilities
- Facilitation of better decision making and improvement of overall project yield
- Increased validation and testing time in a non-critical environment
These tips will help ensure the smoothest, most efficient technical migration to SAP HANA. In addition, keep these other issues in mind as you plan your migration strategy.
SAP began offering SAP HANA as an appliance with integrate software components, such as real-time replication services, the SAP HANA database, data and life cycle management, data services, and the SAP HANA studio. These were optimized on hardware provided by SAP hardware partners. You benefit from quick implementation from the preinstalled software and support provided by SAP.
However, if you have circumstances that require a higher degree of flexibility, SAP developed an alternative approach. The SAP HANA tailored data center integration offers a greater freedom of choice in constructing your SAP HANA hardware landscape.
You will be addressing multiple aspects to SAP HANA during an actual migration. These include OS, DB, network and storage, and applications that run on the SAP HANA platform. You will need a knowledgeable, cross-functional project team from the outset for planning and executing the SAP HANA migration. They will need knowledge on a wide array of topics such as wiring and setup process, appliance shipment, adapting the development process, user management, and operations on this platform.
When you migrate to SAP HANA, your primary questions to address regarding your custom code will most likely include:
- How do we prevent functional regression?
- How do we ensure that custom code runs as well as before the move?
- How will SAP HANA benefit the custom code to boost performance?
- Which new business processes will SAP HANA enable with new custom code?
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. You can also use tools like smartShift, which takes the custom code from your existing system and applies a set of algorithms to automatically remediate your custom code – reducing the cost, and human error.
SAP offers new, improved tools and a new guide that covers considerations for custom code during a technical migration to SAP HANA. You can plan investigation and adaptation activities early to ensure proper performance of custom code.
Finally, take some time to plan the various cycles within the migration project. This will allow you to:
- Become familiar with the procedures and optimize them based upon your specific needs and boundary conditions by conducting test runs with the database content and realistic hardware you need.
- Allows you to develop, refine, and validate your own specific plan and its impact of migartion
- Allows you to conduct and validate simple code optimizations and mandatory code adaptation early in the project
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.