Comprehensive Guide to HANA Migration
SAP HANA is one of the most notable technology innovations in many years, and nearly all SAP products introduced subsequent to SAP HANA have the capabilities to integrate with the platform.
Rather than being a conventional database, SAP HANA is an in-memory data platform that deploys either on-site or in the cloud. The platform enables you to accelerate your business processes while gaining greater business intelligence. The highly sophisticated capabilities and innovations operate your company much more efficiently in your IT environment.
When the platform is implemented correctly, SAP HANA has proven itself to deliver greater results in analytic intelligence, performance, data processing, and better ROI with faster time-to-value.
Planning and executing a successful migration to SAP HANA depends upon a comprehensive understanding of the overall process and careful monitoring during the five main stages of a migration:
- Sizing the landscape correctly
- Selecting the right migration strategy
- Cleansing the date
- Creating a benchmark to ensure ROI
- Implementing High Standards
1. Sizing the Landscape Correctly
Sizing the SAP HANA landscape is a critical and foundational step when developing your technical project plan. This step will help ensure that you derive the optimum benefit from your investment while minimizing the long-term, total cost of ownership. Over- or under-sizing the landscape can result in excess capacity and hardware; under-sizing can result in unforeseen delays and unanticipated additional expenses.
Essentially, sizing the SAP HANA database is premised on the main memory. This is established by the quantity of actual data in the memory storage. Data in SAP HANA is compressed, hence the compression results must be considered within the used scenario. You should avoid making an estimate, rather determine the memory sizing for HANA using the relevant SAP notes, SAP Quick Sizer tool, and SAP sizing reports.
Sizing the SAP HANA landscape correctly is comprised of three steps:
- Memory sizing for both dynamic and static data
- Disc sizing used for persistence storage
- CPU sizing for calculations, queries, and transactions
The main memory is a crucial resource to take into account when sizing a HANA certified appliance. The SAP Master Guide offers a foundation of information for sizing-related topics. The Sizing SAP HANA data contained within the guide offers direction for sizing your SAP HANA system.
2. Selecting the Right Platform and Developing Your Migration Strategy
Your migration to SAP HANA will be much smoother when you select the right platform to best suit your specific business needs, resources, and budget. An SAP HANA deployment can be on-site for optimum control and minimized risks, or in the cloud for greater flexibility, scalability, and a quicker time-to-value.
An array of cloud deployment scenarios exist. SAP offers SAP HANA Enterprise Cloud that comes with the underlying cloud infrastructure, the SAP HANA software license, and managed services. Public IaaS providers accept your SAP HANA license to run over third-party cloud providers, such as Microsoft Azure, IBM Bluemix Cloud Platform, Google Cloud Platform, and Amazon Web Services.
After selecting your deployment landscape, you will need to develop an effective migration strategy to minimize potential disruptions and decrease the system downtime during the practical migration. This will allow you to accomplish a faster time-to-value.
With an on-site deployment, you may opt for a certified SAP HANA appliance from an SAP hardware partner. The appliance will be preconfigured with preinstalled software by the vendor, and it will help you exploit the real-time capacity of the HANA in-memory platform from behind your business’s firewall. Using this method, your solution will be validated by the hardware vendor and SAP. Alternatively, the SAP Tailored Data Center Integration offers additional flexibility. You can streamline the SAP HANA integration and cap infrastructure costs by utilizing your own hardware and operations.
A classical migration is typically the most common method for an OS/DB migration, which is essentially a heterogeneous system copy derived through classical migration tools like Migration Monitor, R3load, or SWPM. If you need to only conduct the migration, and if your system requires no version updating, a classical migration may be best. This may be in circumstances such as migrating a BW to HANA with no additional component requirements.
DMO of SUM
An alternative method is the Database Migration Option (DMO) of Software Update Manager (SUM). This joins together a system update, Unicode conversion, and technical migration with an optimum migration process from ABAP-based SAP system to HANA. DMO of SUM provides streamlined migration phases, thereby reducing the potential for errors. You will have only one downtime period with less manual effort in contrast to a classical migration. Source database will be consistent with this method, as it will continue to run without modification, which means it can be reactivated easily in fallback circumstances.
If your business faces many complex technical issues with its existing systems, you may wish to proceed with a greenfield method and perform a selective data migration to HANA. If so, a better approach may be a fresh installation of HANA. This option offers an efficient method for companies that have standard SAP business processes and plan to move S/4HANA with a smaller data footprint.
3. Creating Key Benchmarks for Continued Success
HANA has brought a new paradigm to enterprise-level computing. However, with robust capabilities, companies need accurate methods of benchmarking to ensure the highest ROI possible. Some vendors make grand claims, or some benchmarks fail to provide insight or context into the actual value.
In the past, limitations of a database created separate worlds of OLAP, OLTP, unstructured data management systems, and event-processing. The benchmarks mirrored the separate silos. Each silo had its own benchmark category. Now HANA overcomes these divides to provide a more useful, insightful, and accurate benchmark.
Benchmarks are best when they measure core features that are long-lived and typically quite complex. They must integrate innovation rapidly, in real-time, and bring value without disruption.
More accurately, a value in decision-making is derived through the capability to make those critical decisions within the correct time-frame. With Avantra and HANA, we believe benchmarks go beyond measuring speed; they must measure value as well. Thus, benchmarking at the migration stage sets your company up for the highest ROI possible, and you continue to see measurable, definable results.
You can look at five key areas that comprise benefits and costs. We seek to optimize each of these areas:
- Going deep – unrestricted query complexity
- Going wide – unrestricted data variety and volume
- Within the window of opportunity – rapid response
- In real-time – utilizes the most recent data
- No pre-processing data – data preparation
Your company depends on industry-based benchmarks to analyze the viability of new software and hardware. This requires more than measuring the speed of various activities. Essentially, with Avantra, the benchmarks measure accurate real-world performance and reflect the true value that you can realistically expect from the deployment.
4. Cleansing the Data
Your next step in the HANA migration process is to cleanse your data. This is a crucial activity to perform prior to moving your SAP systems into HANA. You will derive three primary benefits from cleansing the data:
- A smaller data footprint can also reduce the infrastructure, hardware, and licensing costs
- A decreased data size enables you to conduct the technical migration with a decreased business downtime
- By eliminating old, redundant, and non-relevant data, your SAP HANA will operate at higher levels of efficiency
Depending upon your internal processes and business needs, you must ensure an appropriate data cleansing method. You may archive aged data to lessen the size of the database.
This is also the time to review your data quality management process. In general, you should adopt six steps in maintaining quality data within your database. This will help ensure the smoothest move to HANA possible.
- Identify your data assets to clarify where data storage exists within the organization, how it moves, and how users consume it. This will give you deeper insight into the systems and tables containing the data.
- Define the following: data policies, standards
andquality requirements. This will assist you with setting objectives for your data quality management strategy. This may also be an opportunity to define common business terminology to create a glossary to prevent misunderstandings and miscommunication.
- Assess the data quality that currently exists based upon your defined parameters and validation methods you previously set. Use quantifiable analysis to apply to data quality for a streamlined data cleansing process.
- Perform a thorough analysis to identify the root cause of bad data, and identify the negative influence bad data produces further downstream in your systems such as the data warehouse staging area. This analysis into bad or
low qualitydata is crucial to understanding where it is stored and subsequently moved to the data warehouse through ETL.
- Improve data quality by pre-defining the appropriate data cleansing strategy. After identifying the root cause of bad data, decide on when, where, and how to take action. This can include setting a data quality firewall for applications and systems to prevent the entry of new data that fails to meet requirements, which can be
real-timeentry of data by users, transactional data, batch loading of external data, or customer self-service.
- Monitor data quality continually. Apply data validation rules on a regular basis to obtain historical trend analysis and identify changes in data quality over the long-term. This will assist you in quantifying the benefits of data cleansing by demonstrating quality data scores statistically. Be prepared to be proactive with any slight dip in data quality scores to ensure continued satisfaction from employees, suppliers, and customers.
5. Implementing High Standards
With the technical migration imminent, you must ensure that your source systems are prepared appropriately. You may be enticed to cut corners during this phase of the project; however, it is imperative to keep the team’s focus on the highest standards for a smooth migration. You must have full comprehension of the required activities and be meticulously disciplined from planning to completion.
In addition, you must ensure that your technical team has extensive experience with the technical migration guidelines – and they must understand those instructions, relevant SAP notes, and best practices. If you experience any disruptions during the execution of the technical migrations, your team will be appropriately prepared and more likely to quickly identify the solution.
Confirm Source System Preparation
You must confirm that your source systems are prepared for the journey to SAP HANA. While your existing source system version may support the migration, it is generally best to have the latest release. You receive the most current solutions and fixes to common issues each time SAP releases a new version and support package. Ensure that your system has these in position prior to commencing the migration.
In this phase, it is particularly critical to avoid unnecessary risks during the database migration. Perform regular and frequent backups. You will have archive logs and full backups to establish regular restore points. Identifying common risks and having solutions prepared will help enable a smooth technical migration.
Once the source system is prepared, a set of monitoring standards should be put in place. As few as possible major development changes should be in occurring at this stage, and thus the system should be in a fairly stead state. It’s important to narrow in on specific resource consumption and performance metrics to make sure no other variables are in play prior to the migration.
Confirm Target System Preparatio
There are a significant amount of system hardening checks and specific monitoring of finite detail that needs to occur to verify your company’s policies are being adhered to. At the end of a HANA migration, before the system is handed off to the business, these checks need to be verified as to not run into any security and compliance violations. Prebuilding these checks in a third-party monitoring tool can automate these checks. This remove any chance of human error in this verification steps and cuts down on the amount of downtime before the business can use their new HANA system.
Proof of Concept
An SAP proof of concept (POC) is a wise step to take prior to the commitment of a major transformation. HANA is a highly customized system, so essentially you have no demo model to try. The POC allows you to test and experience HANA, experience performance improvements, see features such as real-time reporting, and conduct end-to-end benchmarking. This will verify that your SAP migration will positively impact operational performance, which is crucial to gaining additional organizational buy-in, especially if your company culture is risk or change-averse. Rather than saying “the solution will reduce load time by 90%,” you can actually demonstrate that an application will load within seconds rather than minutes.
Evaluate Post Migration Performance
Even before the migration begins, it’s important to start thinking about what kind of hyper care support will be needed in the days immediately after the migration. Even with great testing completed prior, there is always room for the unexpected to occur directly after the migration to HANA. This will probably be the first time that the entire business will be using the system, a test that probably could not have been completed during the trial migrations. This means unexpected performance issues and we need to hold true to the monitoring high standards that have been put in place. It’s also critical to cross reference the benchmarking that was done prior to ensure performance is better than in the source system.