SAP Hana Migration
SAP Hana Migration is the method of converting to SAP HANA from any database you use today with SAP. After It can be difficult to migrate from one operating system or database to another.Many variables fall into practice, varying from company requirements to approach, skills sets in the IT department, problems of data formatting, and so on.Especially SAP Hana Migration can be a massive boost. This article provides some perspectives and proposed measures to migrate information from SAP HANA.
After the migration, SAP HANA will be your primary database to support your SAP landscape.One element that challenges SAP HANA migration is how HANA handles the information itself.SAP HANA is designed as a database for columns.
Traditional RDBMS systems on the other hand are row-based. SAP HANA is also an in-memory database, storing data for improved performance in solid state memory (RAM). This difference can make the migration more difficult.
SAP ECC Migration to HANA
Step by Step Process
Working with many customers who operate their enterprise on SAP, we have developed an efficient, step-by-step method for moving SAP ECC to SAP HANA. Migration specifics differ depending on distinctive elements of the SAP landscape and company of each client.In particular, however, it has been shown that the following measures perform well:
1.Perfectly Size Your SAP HANA Landscape:
It’s critical to scope your resources thoroughly for SAP HANA.The distinctive data structure of the platform allows it quicker than its rivals.Its speed is appears with unpredictable, complicated analytical queries specifically.A columnar database allows you to store only the corresponding rows of information.At the same time, a columnar database changes your resource requirements.
A conventional database adds query indicators to its information, which starts up search at the cost of a bigger data impression. SAP HANA, on the other hand, shrinks the information footprint but needs comparatively large CPU and storage funds.
Because of these limitations, you do not want the ability of the database to be under- or over-provided.The best approach is to evaluate the quantity of memory required and schedule from there for your main data set.You’re supposed to want to set the memory limit for static and dynamic data as well as the “persistence storage” file size specifications.These metrics should match with the work loads of the database with the CPU you provide.The SAP Quick Sizer instrument and measuring reports can assist.
2. Fixing custom code
Custom code complicates the process of SAP HANA migration. Older schemes appear to have both custom code and obsolete procedures of data modeling. These are poorly adapted for SAP HANA. Before you move, you need to fix these problems.
3.Choosing a platform
By choosing the appropriate platform that suits your company requirements, plan, and resources, you can migrate rapidly and seamlessly to SAP HANA. For maximum control and decreased risk, SAP HANA can be implemented on premise or in the cloud for enhanced efficiency, scalability and quicker cost time.With on-site deployment ; you can choose from one of SAP’s hardware providers a licensed SAP HANA appliance. The pre-configured appliance with pre-installed software (by the hardware vendor) will assist you exploit the SAP HANA in-memory platform’s real-time authority behind your own firewall.
4. Assessing a migrants approach
You have options about how you do the actual migration.You can use instruments such as SWPM, R3load and Migration Monitor to do the regular system replication strategy.If your scheme does not require an update to operate on SAP HANA and you only need to conduct the real migration ; for example, you are moving your Business Suite or BW scheme to SAP HANA as it is without any additional element specification ; classical migration strategy might be the best route.
Another alternative is Database Migration Option (DMO) of SUM(SAP Software Update Manager) combining system update, technical migration and unicode transformation (if necessary) with an optimized migration from an ABAP-based SAP scheme operating on any DB to SAP HANA.DMO of SUM provides streamlined migration measures (thus less error-proneness), decreased manual work relative to classic migration, and only one business downtime that can also be optimized based on the situation.
A database migration offers a wonderful pretext for cleaning up data.Based on master data collections, you can deduct and normalize information.You can adjust fields to new standard mappings for data types like nine-digit zip codes etc. Cleansing produces advantages such as decreased data foot printing, which reduces the cost of your infrastructure.
Cleansing your data offers three major benefits:
- Lowered data footprint will also decrease infrastructure, hardware and licensing costs for SAP HANA
- Decreased data size enables you to carry out technical migration with decreased downtime for business
- SAP HANA works even faster after the technical migration by maintaining only the quantity and required data in your system.
6.Do a Proof of concept(POC)
Testing your migration in a Proof of Concept (PoC) is a nice idea before pulling the trigger on complete migration.A PoC allows you to validate the method of migration.In your Sandbox setting, you can conduct a POC to identify problems that could adversely influence the initial migration.
This is a vital step for any method of technical migration and I can guarantee you that it is worth it because the cost of duplicating the environment :
- It provides you an insight into how long it takes
- You can locate possible issues in the sandpit system and decrease project risk
- It makes company easier to recognize SAP HANA’s strength
- It enables you create significant choices about your project schedule and enhance the general efficiency of your project
- In a non-critical setting, you will have more testing and validation moment
- It gives entire project a feeling of momentum