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:

Classical_Migration_Overview.jpg

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.

Upgrade.jpg

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:

Migrate.jpg

  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 System Copy and Migration page, providing general information for the system copy with software provisioning manager.
  • 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:

Best_Practice_Guide.jpg

Downtime-Minimization Options

Downtime.jpg

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
    • For more information, see SAP Note 1678565 (SMP login required)
  • Optimization options for the migration part:
    • Optimize the export + import with table and package splitting, integrated into the standard migration procedure of software provisioning manager – for more information, see the Best Practice Guide – Classical Migration of SAP NetWeaver AS ABAP to SAP HANA
    • 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 Additional_Hardware_for_Migration.jpg
    • 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
    • For more information, see the document Easier Migration to SAP BW powered by SAP HANA
  • If classical approaches outlined above should not suffice to achieve your downtime requirements or if you should face special requirements, consider SAP consulting offerings (available on request), as described in:
To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

    1. Boris Zarske Post author

      Hello!

      Yes, this is integrated in Software Provisioning Manager, the feature is described in the system copy guide for SAP HANA in section Database Instance Export on Additional Hosts:

      “You can do this by choosing Database Instance Export on Additional Host in the installer after starting the Database Instance Export.”

      Best regards,

      Boris

      (0) 
    1. Boris Zarske Post author

      Hi Maria,

      Sure, this supports the migration from any supported source database to SAP HANA. Also, the Database Migration Option of SUM would support Microsoft SQL Server as source database, so you would have choice what to take, depending on your boundary conditions (while our standard recommendation is to use DMO).

      Best regards,

      Boris

      (0) 
  1. Suryanarayana Bommisetty

    “You perform an export of your traditional source database in a database-independent format”

    Hi Boris,

    you have mentioned that export dump is database independent but actually when we d do exportsource system we will get a option for target database selection .. so we need choose according to target database.. can you explain me is it correct or is there anything only for hana export dump will database independent?

    (0) 
    1. Boris Zarske Post author

      Hi Suryanarayana,

      What I meant with this sentence is that the actual data inside the database is exported in a format that can be used to be imported into any target database – so, it is the database contents that gets stored in a database-independent format. Nevertheless, in addition to the database contents, also further data is compiled into the overall export (such as Kernel files) or processed (such as metafiles concerning target database sizes), which are database-dependent. Therefore, the procedure requests the target database, so that it can compute and compile the right metadata for the desired target database. Therefore, you should not reuse an export created for another target database, but repeat the export accordingly, so that also the metadata will fit.

      Best regards,
      Boris

      (1) 
  2. Alan Dsilva

    HI Boris, excellent blog – thanks for sharing.

     

    I have a question regarding such a migration from a Oracle based Java system (PO) to HANA.

    What happens to entity based tables that are created using the SAP NWDS Dictionary perspective.

    Are these tables ported to the HANA db automatically during the process along with its data content ? or are there other steps to be performed to make the same data tables and content available in the HANA migrated system

     

    thanks in advance,

    Alan

     

    (0) 
  3. Stefan Jakobi

    Dear Mr. Dsilva,

    thank you for your questions about the migration of tables created with NWDS Dictionary to HANA.

    Tables created using the SAP NWDS Dictionary will be handled by heterogeneous system copies. So, to our knowledge, they should be transferred automatically with the SAP HANA migration.

    However please keep in mind that the following constrains remain:

    • … for system copy:
      • Do:
        • Save configuration data and runtime data in the Java database only.
        • Follow the Open SQL standard.
        • Make sure that all communication runs through the database pool.

    These remarks can also be found in the System Copy Guide under 1.5 Constrains:

    e.g.:

    https://websmp201.sap-ag.de/~sapidb/011000358700000770342013E

    And of course it is always recommended to make a test migration first and verify the correct functionality in the test migration.

     

    Best Regards

    Stefan Jakobi

    Product Management

    Cloud and Lifecycle Management

     

    (0) 

Leave a Reply