Alper Somuncu outlines a roadmap to make your transition to SAP’s in-memory platform seamless.
SAP HANA is the most important technology innovation from SAP in the last decade and almost all SAP products released after SAP HANA have an extensive ability to integrate into this platform.
SAP HANA is not just a traditional database; it is an in-memory data platform deployable on premise or in the cloud, and empowers you to accelerate business processes, deliver more business intelligence with advanced innovations and capabilities to run your business faster and simplify your IT environment.
“HANA is attached to everything we have.” Bill McDermott, CEO, SAP.
When implemented properly, SAP HANA delivers outstanding results in terms of performance, integration capabilities, analytic intelligence, data processing and improves ROI of your SAP landscape with faster time to value. This article is designed to help you plan and execute a successful technical migration to SAP HANA platform and aimed to provide a high-level overview of the most important, yet often overlooked steps, with a focus to reduce the risk of your organization’s journey to SAP HANA.
STEP 1: CORRECTLY SIZE YOUR HANA LANDSCAPE
Sizing your SAP HANA landscape is a vital and fundamental step when creating your technical project plan and helps you realize the maximum benefit from your investment while reducing long-term total cost of ownership. Inadequate and over-provisioned sizing could lead excess capacity and bloated hardware while under-provisioning can cause unexpected delays that will increase the cost of operational performance.
For the most part, sizing of SAP HANA database is based on the main memory which is determined by the amount of the actual data stored in memory. Since the data is compressed in HANA and the compression results depends on the used scenario, it is not easy to guess the amount of memory needed for sure. Therefore, the memory sizing for SAP HANA should be performed using SAP Quick Sizer tool, relevant SAP notes and SAP sizing reports.
Correct sizing of SAP HANA consists of three main steps:
- Memory sizing for static and dynamic data
- Disk sizing for persistence storage
- CPU sizing for transactions, queries and calculations
STEP 2: CHOOSE THE RIGHT PLATFORM AND MIGRATION STRATEGY
You can migrate to SAP HANA quickly and seamlessly by choosing the right platform that best fits your business needs, budget, and resources. SAP HANA can be deployed on premise for maximum control and reduced risk, or in the cloud for increased flexibility, scalability and faster time to value.
With on premise deployment; you can choose a certified SAP HANA appliance from one of SAP’s hardware partners. The preconfigured appliance with preinstalled software (by the hardware vendor) will help you harness the real-time power of SAP HANA in-memory platform – behind your own firewall. With the preconfigured approach, you will get the solution validated by both SAP and hardware vendor. On the other hand, SAP HANA Tailored Data Center Integration (TDI) provides you more flexibility. You can significantly reduce infrastructure costs and simplify your SAP HANA integration by leveraging existing hardware and operations in your own data center.
There are variety of cloud deployment scenarios. SAP also has its own private cloud offering called SAP HANA Enterprise Cloud. It includes an SAP HANA software license, underlying cloud infrastructure, and SAP-managed services. Public cloud, IaaS offerings allow you to bring your own SAP HANA license to run on third-party public cloud providers: Amazon Web Services, Google Cloud Platform, IBM Bluemix Cloud Platform and Microsoft Azure.
After you decide your HANA deployment scenario, you need to select the most effective migration strategy to reduce any unforeseen problems and eliminate longer system downtime during the technical migration so you can realize faster time to value.
Classical migration is the first and mostly used (so far!) approach for OS/DB migration which is basically a heterogeneous system copy using classical migration tools such as SWPM, R3load and Migration Monitor. If your system does not require any version update to run on SAP HANA, and you only need to perform the actual migration; for instance, you are migrating your Business Suite or BW system to SAP HANA as it is without any additional component requirement; classical migration approach would probably be the best way.
Another option is Database Migration Option (DMO) of SUM which combines system update, technical migration and unicode conversion (if required) with an optimized migration procedure from ABAP-based SAP system running on anyDB to SAP HANA. DMO of SUM offers simplified migration steps (hence less error-proneness), reduced manual effort compared to classical migration, and only one business downtime period which can also be optimized depending on the scenario. Source database is consistent with this approach, continues to run and it is not modified therefore it can be reactivated with only medium effort in case of a fall-back. So, even though it’s a new method, it is a completely safe option.
If you have lots of technical issues with your existing system and would like to proceed with greenfield approach with selective data migration for SAP HANA; then it might be better to perform a fresh installation on SAP HANA. This option can also be an efficient approach for companies that has mostly standard SAP processes and planning to move S/4HANA Cloud with relatively smaller data foot print.
STEP 3: CLEANSE YOUR DATA
SAP HANA offers a lot of advanced analytics and opportunity to optimize your business operations by analysing large amounts of data, in real time. It runs faster than all traditional databases we know so far, but you know what is better?
Run it even faster with reduced cost!
Data cleansing is one of the critical activities you must perform before bringing your SAP systems into HANA and unfortunately it is also the most overlooked step. There are three most important benefits from cleansing your data:
- Reduced data foot print will also reduce your infrastructure, hardware and SAP HANA licensing costs
- Reduced data size allows you to perform the technical migration with reduced business downtime
- By keeping only quality and necessary data in your system, SAP HANA performs even better after the technical migration
The figure above provides guidance for a proper data cleansing process. Keep in mind that the activities listed here may change, depending on your business needs and internal processes. You must ensure you are applying the most suitable data cleansing method for your own business. It is generally OK to remove technical data, application logs and system logs. You can always archive your aged business data to reduce the size of your database.
STEP 4: APPLY HIGH IMPLEMENTATION STANDARDS
It is generally a bad idea to cut corners during a technical migration project, and you need to allocate the time to get it right. Do not to take shortcuts during this phase of the project and focus on keeping high standards in your activities. You need to be methodical and understand all required activities from planning to cutover.
Your technical team should have plenty of experience and understanding of technical migration guidelines, relevant SAP notes and best practices. If things go wrong while performing the technical migration, you will be better prepared and less likely to miss the solution.
Make sure your source systems are ready for their journey to SAP HANA. Even though your source system version is supported for the migration, it is better to be on the latest release. SAP delivers latest fixes and solutions to common problems with every release and support package. Make sure your system has these in place before starting a migration project.
Don’t take unnecessary risks especially when migrating your database. You will never have too many backups; therefore, make sure you have full backups and archive logs to allow regular restore points. Eliminate common risks to ensure a smooth technical migration.
As J.R.R. Tolkien said: “Short cuts make long delays.”
If you want your project to be a success, then do not take shortcuts and always keep high standards.
STEP 5: DO A PROOF OF CONCEPT
You need to perform a ‘Proof of Concept’ in a sandpit environment first, so you can “validate” your migration process to an SAP HANA platform. You can do this by copying your SAP Production system to create an SAP Sandpit environment and perform the actual migration on this system first.
This is a crucial step for any technical migration process and I can assure you that the cost of duplicating the environment is well worth it, because;
- It gives you an idea of how long it takes
- You can identify possible issues in the sandpit system and reduce the project risk
- It facilitates business to realize the power of SAP HANA
- It helps you make important decisions in your project plan and improve overall project productivity
- You will have more testing and validation time in a non-critical environment
- It provides a sense of momentum throughout project
As Aristotle once said: “For the things we have to learn before we can do them, we learn by doing them.”
WHAT NEXT?
If you have gotten this far, you are now ready to start planning your technical migration to the SAP HANA platform.
Implement these five steps; you will not experience any unexpected issues and your technical migration process should go smoothly.
I wish you a successful transition into the new SAP HANA platform.
Alper Somuncu is a certified SAP technical architect and SAP OS/DB migration Specialist. His special interest areas include SAP HANA technical architecture, SAP HANA platform options, system performance and technical operations. Additionally, Somuncu delivers official SAP HANA training: SAP HANA Installation and Administration (HA200), SAP HANA Security (HA240) and Migration to SAP HANA (HA250). Somuncu is the managing director of Effectise Pty Ltd, a dynamic SAP consultancy helping businesses succeed with SAP HANA.
