Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert

This document provides an overview of the classical migration procedure of an existing SAP system based on SAP NetWeaver to SAP HANA, including latest improvements, best practices and downtime-optimization options. For ABAP-based SAP systems, there are further options in addition to the classical migration, as outlined on the Migration of SAP Systems to SAP HANA overview page.

Migration Process Overview

For the classical migration procedure, the activities outlined in this section are required, which are valid both for ABAP-based and for Java-based SAP systems.

The following figure provides an overview of the migration process and the activities included:

First, you have to prepare your system for SAP HANA:

    • If you should have an optional dual-stack system, you have to perform a dual-stack split.
    • If you should have a non-Unicode system, you have to perform a Unicode conversion:
        • The Unicode conversion procedure is similar to a system copy procedure as offered by software provisioning manager.

        • Optionally, you can combine it with the database migration procedure, as outlined below.

Then, you have to bring your existing SAP system to a release supported by SAP HANA - for more information, see the Product Availability Matrix (SMP login required). For this, you perform a classical update with the Software Update Manager - for more information, see the Software Maintenance page. If required, this might imply the update of your operating system and database version (for example, if the current database version does not support the target release of the maintenance activity of your SAP system).

Finally, you perform a heterogeneous system copy of your SAP system with the software provisioning manager:

  1. As the procedure is constantly improved especially for the migration to SAP HANA (see corresponding section on this page below), you always download the latest version of software provisioning manager from the Software Logistics Toolset page in SAP Help Portal.
  2. You perform an export of your traditional source database in a database-independent format.
  3. You create your target system on SAP HANA by using the database load exported in the previous step.
  4. You perform post-migration activites as described in the system copy documentation (also available on the Software Logistics Toolset page).

For more information, see:

    • This overview presentation, providing a more detailed overview of the classical migration procedure to SAP HANA.
    • The sections below on this page that provide best practices and an overview of the downtime-minimization options for the classical migration procedure.

Best Practices and Improvements

The classical migration to SAP HANA is constantly improved especially for ABAP-based systems, as we see most of the demand here (for example, due to the size of ABAP-based SAP systems and the role they play in customer system landscapes). Therefore, see the following best practice information and improvements are made available for the migration of ABAP-based SAP systems to SAP HANA:

    • Find general expert and best practice information in the Best Practice Guide - Classical Migration of SAP NetWeaver AS ABAP to SAP HANA to ease and accelerate your procedure. Besides an overview of involved tools and important information, the focus lies on best practice information, such as about table and package splitting. Also, an example is provided for the optimization of the runtime of a test system migration.
    • Get detail information in blogs and documents from Stefan Seemann about latest corrections and improvements of software provisioning manager especially for the migration to SAP HANA:
        • For software provisioning manager 1.0 SP3 PL6, see this blog, describing many improvements

        • For software provisioning manager 1.0 SP4 PL4, see this document, describing a new SAP HANA client installation option

Downtime-Minimization Options

In general, to optimize the runtime of the classical migration to SAP HANA, we strongly recommend to perform several test runs, where you can try different optimization methods and gain further experience concerning parametrization and handling of the available options.

Below, you can find a rough overview of some of the available approaches:

    • If you want to migrate a non-Unicode system to SAP HANA, consider to combine the Unicode conversion either with the upgrade (for more information, see SAP Note 928729) or with the database migration
    • Optimiziation of the upgrade part: use downtime-minimized capabilities for the upgrade with Software Update Manager
        • Implies the usage of an additional shadow database with record & replay

        • Available as of Software Update Manager 1.0 SP7

        • Applicable for the upgrade as part of the classical migration procedure as outlined above

    • Optimization options for the migration part:

        • Consider to use parallel export and import, also as offered by the standard migration procedure of software provisioning manager - for more information, see the system copy guide

        • Consider to use additional application servers for the export

        • Consider to use an SAP HANA standby node for the import

        • After a migration (test) run, analyze occurred runtimes and try to identify bottlenecks and further optimization options (such as number of R3load jobs and table splitting)
    • Especially for SAP Business Warehouse (SAP BW), you can complement the migration procedures by a downtime-minimized approach:
        • Idea is to create a parallel shadow system of your SAP BW system via homogeneous system copy, on which all required changes (upgrade, migration, ...) are performed

        • This is supported by automated post-copy configuration and an automated cloning of the delta queues in the SAP BW source systems, making sure that the copied system results in a consistent state, although the production SAP BW system can continue to work

        • This way, the production SAP BW system only faces a reduced downtime (for the export of the homogeneous system copy), while there is no technical downtime for the SAP BW source systems