Posted by: Mohammad

1. Overview

The HANA Platform "despite the fact that it has been available in the SAP offer for a long time and is exceptionally encouraging" is simply beginning in business. The arrangement is as yet being produced and the principal movement activities are occurring under the supervision of SAP specialists. Their part is to give proposals and experience with respect to the approach to arranging the work and forms of the tools to be utilized during the update and system migration.

For the reasons of system migration to HANA, SAP likewise gives a free service that encourages the recognition of support areas and impact on the change of execution of the system which has as of now been installed on the HANA Platform. The administration is known as the Business Situation Proposal for Suite on HANA and includes the investigation of a properly arranged explanation of the utilization and execution of transactions in the client's system.

Because of these creative arrangements, we prescribe a careful investigation of the extent of the work and accessible documentation given by the system manufacturer preceding beginning a migration project. During an investigation of the extent of activities it is important to check toward the starting:

• versions of segments utilized as a part of the system

• differences in the working of systems for target versions of segments

• technical devices utilized for update and migration

• available specialized and system documentation

• Current system setup and significant reports on the system's operation.

The whole undertaking is led as per SAP standards and best practices created by the Project Management Institute, which forces elevated expectations of behavior and guarantees higher security and upgrades the odds of the venture being effective and successful.

The undertaking of system migration to a HANA database is not a confounded venture in the event that we get ready legitimately for it. It can be isolated into four stages:

• Preparation

• Migration

• Steps after migration

• Optimization

Preparation

• The planning procedure ought to start with figuring out what equipment will be expected to migrate to the HANA database. The equipment for HANA is conveyed by confirmed SAP partners, for example, Dell, Fujitsu, HP, IBM, CISCO, as prepared to-utilize servers (SAP HANA Appliance) including introduced HANA software.

• The equipment estimating includes the determination of the measure of RAM required for the HANA database. Alternate parameters (CPU, circles, and so forth.) are suitably chosen relying upon the measure of memory held by the HANA platform, and don't need to be indicated.

Migration

• The procedure of the SAP system database movement to the SAP HANA platform is altogether not the same as the migration between different platforms (in SAP, this sort of venture is known as an OS/DB migration).

• Disentangling to some degree, the movement process comprises in the export of a source database and the import of substance consequently got to a target database (for our situation HANA). Likewise, with different databases, when migrating to the HANA Platform, we can likewise utilize arrangements, for example, a parallel import and fare utilizing the TCP/IP association. Now and again, this will permit us to lessen the time necessary for migration.

The migration process for most SAP systems will must be performed in two stages:

1. Upgrading the system to the version necessary by SAP HANA
2. Migration of the database to the HANA Platform.

On account of BW systems, we have to redesign the system to version 7.3 SP5 or higher; at exactly that point the best possible migration can begin. On account of ERP systems, we need to redesign the systems to ERP 6.0 EHP 7 or EHP 6 for HANA, nonetheless we suggest utilizing the most recent accessible EHP (right now EHP7).

In the most recent adaptation of Entirety 1.0 SP9, it is conceivable to perform an upgrade and migration in a single stride to a restricted degree. This capacity is called DMO (Database Migration Options) and can be a fascinating option for systems working 24 hours a day to decrease system inaccessibility.

Steps after migration

After the migration has been finished and the system has been dispatched on the HANA Platform, it is important to redo the system itself and the related environment. Along these lines, the accompanying activities ought to be arranged:

• standard specialized steps after the migration (as with different platforms),

• technical joining steps checking the correspondence with different systems,

• integration of base alteration of backups, upgrade of system data in solution manager, overhaul of SLD, observing, and so forth.

• application tests "testing of the executed business process" the very procedure of migration to the HANA Platform does not acquaint any progressions with the business layer of the system, however the important overhaul of the system (e.g. EHP7 establishment) requires testing.

• Going Live OS/DB Movement Check Service "the second session of the system check after the relocation" proposals from the report ought to be executed in the system.

Optimization

• Exploiting the capability of SAP HANA depends to a great extent in transit in which we handle information. On account of the HANA database the preparing ought to be moved towards the database. This implies we ought to execute whatever number operations as would be prudent at the database level and diminish the handling in the application layer.

• As soon as the system is as of now up and running on another platform, the time has come to start its improvement. Albeit quickly after the migration numerous exchanges and reports will run quicker than on the past platform, it merits analyzing in more detail what is occurring in the system.

2. Risks

Dangers included are simply colossal. Here are a few pointers:

1. Choose your usage accomplice with extraordinary care and comprehension.
2. Choose an Execution group, that has information and are intelligent.
3. Choose your own group painstakingly who could gel with Execution group and are adequately engaged to take business choices/give inputs, generally the issues of non-collaboration, postponed/no reactions and doubt could snowball into significant acceleration affecting venture courses of events.
4. Follow a solidified/closed down Business Blueprint like a Bible and maintain a strategic distance from some other changes (which are deviations from the concurred scope adding up to Change Ask)
5. All of us don't care for change, yet acknowledge it. Clients, who are continuously working at a specific software without stopping for even a minute, for a considerable length of time, will undoubtedly feel on edge while moving to SAP. Along these lines, might it be trepidation of learning (or whatever other), it should be tended to appropriately, much before the Go-Live.
6. If the undertaking size and multifaceted nature is immense, arrangement of a different team for data migration, right in the early phase of task would accord due focus on this subject. Associations need to address the issues of data duplication/data clean up/data acceptance (as such, data messaging) else if such information is migrated to SAP, it turns into an instance of 'refuse in, junk out'. Vendors group needs to give a point of interest migration arrangement demonstrating how they will transfer different master/transactions, utilizing which technique/innovation, in which succession, cutover date and so on. To resolve every one of the issues, a demo run of data migration is an unquestionable requirement.
7. Unless legitimately arranged, information lives generally (and just) in the heads of people (vendor resources as well as business groups) or in their scratch pad & PCs. In this way, when these people leave, you're in a bad position. Along these lines, ensure a decent and inflexible documentation system.
8. You need somebody (from your side) to work intimately with the vendor team, to screen advance nearly consistently, to search for the chinks/warnings at each stage, in short - to take after what has been secured in before focuses. In either case, guarantee the right senior stakeholders are included in the Project Steering Committee. Sense of self administration is one more fragile assignment you have to handle competently. Guarantee the Controlling Panel meets at preplanned interims and issues are tabled/tended to.

3. Knowledge Exchange

Here are some best practices to handle Documentation Issues:

1. Designate somebody as Documentation Lead. His brief will be straightforward, guarantee due documentation of each procedure, in each period of the undertaking. Arrangement for his reinforcement asset as well.
2. Store it on a common drive/system/cloud with due access component.
3. If the undertaking is big (thumb principle - If the quantity of SAP clients is more than 300 it is a Major venture), pick a decent documentation tool and guarantee it is utilized
4. Ensure vendor team is documenting and putting away it on the assigned spot
5. Arrange one Documentation Review to discover the holes
6. As an absolute minimum, a SAP execution undertaking's should incorporate these documents (names might vary yet substance would remain):

• Project Charter

• Project Plan

• Business Blueprint

• Business Process Procedure

• Test cases (Unit testing/Integration testing/User Acceptance testing/regression testing (if significant)

• Data Migration Plan

• List of custom articles with one-line explanation

• Functional details

• Technical details

• User roles (authorization matrix)

• SAP Patches/OSS Notes executed (when and why)

4. Basic checks for SAP BW on HANA Movement

1. If you want to migrate BW system to HANA and you need to perform feasibility check with a specific end goal to get comprehension of loading procedure and performance improvements then you can arrange this remote service from SAP.
2. SAP HANA requires Unicode. You have to perform Unicode transformation before migration to HANA or consolidate movement with Unicode conversions.

5. Migration Best Practices

1. Prior to begin the migration, perform housekeeping undertakings to erase undesirable information from database which will diminish downtime for migration.
2. Use Table splitting for bigger tables.
3. Please dependably utilize most recent kernels, R3load and R3ta devices for export/import procedure to dodge blunders.
4. With SWPM 1.0 SP3 PL6, assortment of new choices is accessible in SWPM where you can pick distinctive export choices like sort the export in view of size or run time or rehash export without running R3szchk once more.
5. There are many new improvements that are released in report SMIGR_CREATE_DDL for HANA. Presently, you can perform Table Classification (this is required for appropriation and apportioning of BW tables in a scale out environment), Estimate Table Size and Row store list.
6. Distribution monitor is not discharged for SAP HANA.
7. It may happen that after migration to HANA, some ABAP Code execution is bad and significantly slower than past database. This may be on the grounds that improvement is not done in ABAP according to suggestions.
8. SAP has released report that can help you to locate the potential Data suppliers that can be resigned when utilizing HANA.
9. SAP has as of late discharged BW on HANA Movement cockpit where you can perform all errands like measuring, DDL generation, Checklist tools, ABAP Optimization and data cube conversion and so forth. This is great cockpit and less complex our undertakings for Pre/Post migration exercises.

6. Post Migration checks/exercises

1. In request to check consistency of tables after movement to HANA, please utilize report RSDU_TABLE_CONSISTENCY.
2. In a few cases, you will confront issue where customers are not ready to interface with SAP HANA scale out hubs. This may be because of how scale out architecture is designed.
3. In SAP Netweaver 7.4 release, De-grouping of tables while migration to HANA database is bolstered.
4. Properly check similarity of 3.x data flow with BW on HANA.
5. It is possible to transport Information cubes from source systems (non-HANA database) to BW on HANA systems yet there are a few requirements to it.
6. Post migration, it is asked to execute essential SAP notes before productive use of your system.

7. HANA Revision Upgrade

1. If you want to update SAP HANA to SP6 then please take note of that SUM for SAP HANA will be supplanted by SAP HANA Lifecycle administrator (HLM). You can in any case use SUM in HANA SP6 however its usefulness will be extremely restricted.
2. For more previous versions i.e. till SAP HANA SP5, you can arrange SUM for SAP HANA.

8. Execution Improvement

1. Assess the memory utilization of a SAP HANA system.
2. If you are encountering moderate execution of HANA database, please check whether it is a result of CPU or not.
3. Row store memory is a considerable measure greater than real data size since row store tables develop by allocating a 64 MB section, furthermore, shrivels by same. On the off chance that you have erased lots of information from row store tables and afterward a great deal of sparse segments is available. Besides, keeping in mind the end goal to free up the space, reorganization will be essential.
4. If you need to recognize issues identified with primary keys and unique constraints.
5. In case you discover that a few tables are not divided or distributed accurately over many HANA nodes.
6. In request to enhance select statement for all entries.
7. In request to enhance performance on HANA, it is vital that data is only accessed once in a while or no longer ought to be stacked into main memory.
8. If you are confronting memory related issues or getting cautions for memory utilization in HANA.

This is not the last rundown of all activities to do migration to SAP HANA and you have to allude to system copy guides, SAP release notes and SCN and so on for detail process.

9. Vendor Experiences

HANA (Usage/Migration) scene can be of 2 sorts:

• Side-Car Implementation- Where half of the SAP scene remains focused on non-HANA, while other half gets relocated to HANA.

• HANA direct implementation- Where the whole scene gets migrated to SAP HANA in a solitary go.

Our experience so far demonstrates that HANA is an extraordinary option than the classic database and has gigantic potential not just as a database. Late experience picked up between the migration project being executed now for one of our clients demonstrates that running the ERP system on the HANA platform conveys substantial execution advantages after migration, and further streamlining can multiply them.

Back to Main Page