Skip to Content

Migration of SAP Systems to SAP HANA


This document provides a starting point for the planning of your migration procedure of SAP systems to SAP HANA in an on-premise landscape. Beginning with an overview of available migration path options, we provide a general recommendation and further aspects and guidance how to identify the best procedure for your requirements. Take these aspects into the discussion with your cross-functional teams and use them as basis for an individual assessment based on the boundary conditions you are facing.



Overview of Migration Path Options

ABAP-Based SAP Systems

For the migration of ABAP-based SAP systems to SAP HANA, several migration path options are offered:


  1. In case you want to change your existing solution landscape in the course of a migration project, there are several transformation offerings from SAP Landscape Transformation, where you install a new system for the transformation, such as performing a step-wise or partly migration of an SAP system or the consolidation of several systems into one system running on SAP HANA.
  2. The classical migration of SAP systems to SAP HANA (that is, the heterogeneous system copy using the classical migration tools software provisioning manager 1.0 and R3load) is using reliable and established procedures for exchanging the database of an existing system – it is constantly improved especially for the migration to SAP HANA.
  3. To further smooth the way to SAP HANA, SAP is providing a one-step procedure that combines system update and database migration for the migration to SAP HANA. This is provided with the database migration option (DMO) of Software Update Manager (SUM).


The options are outlined in an overview video. Spend 15 minutes to get a quick-start to the available migration options to SAP HANA for SAP ABAP systems:
Overview of SAP HANA Migration Options
Slides used during this video are also available as separate SCN document here.


In addition, see the corresponding End-to-End Implementation Roadmap guides that also outline available migration path options.


Java-Based SAP Systems

For Java-based SAP systems, the classical migration is available, as outlined above.





How to Choose the Right Option for You?

1. See the Standard Recommendation from SAP

Use the following recommendations as starting point for an individual assessment – that is, take the recommendation and relevant aspects into the discussion with your cross-functional teams and use them as basis for an individual assessment based on the boundary conditions you are facing.


For ABAP-based SAP systems, the following recommendation applies:


  • The general recommedation is to use the database migration option of SUM, as it has become our standard procedure for migrations to SAP HANA – with it, you can profit from a simplified migration to SAP HANA, performed by one tool, with minimized overall project cost and only one downtime window.
  • As reasonable alternative to our standard recommendation, in case the database migration option of SUM does not fit your requirements, consider to use the classical migration procedure with software provisioning manager, which is also continuously improved especially for the migration to SAP HANA. Reasons might be that the database migration option of SUM does not support your source release or if you prefer a separation of concerns over a big bang approach as offered by DMO of SUM.
  • As possible exception, there are further migration procedures for special use cases, such as the consolidation of SAP systems in the course of the migration project or the step-wise migration to SAP HANA, as oultined above.


For Java-based SAP systems, use the classical migration approach (and skip step 2 below).


2. Individually Assess Your Situation

Based on the standard recommendation from SAP, find the best option depending on your individual requirements and the boundary conditions you are facing. To support you in this process, SAP provides a decision matrix in the End-to-End Implementation Roadmap for SAP NetWeaver AS ABAP guide (SMP login required), which is intended to highlight important aspects for your decision on the right migration procedure, including these key considerations (see the guide for the lastest version of the matrix) – the matrix is also described in this blog:



  • What is the release and Support Package level of your existing SAP system? Is an update mandatory or desired as part of the migration procedure?
  • Is your existing SAP system already Unicode?
  • Do you plan any landscape changes – such as changing the SAPSID of your SAP system or the hardware of your application server – as part of the migration or do you rather prefer an in-place migration?
  • Do you plan the migration of your complete system or a partial migration?
  • Are your operating system and your database versions supported according to the Product Availability Matrix (PAM) of the target release or are corresponding updates required?
  • Do you expect a significant downtime due to a large database volume?

All these aspects are reflected in the matrix, which is intended as a starting point for your individual assessment as outlined above.


Further Aspects

In this blog, several relevant aspects for planning a migration project to SAP HANA are gathered – such as prerequisites, sizing, deployment options, custom code, test management, and project plans.

You must be Logged on to comment or reply to a post.
  • Couple of hints from migration of - ECC, CRM and SCM (with live-cache) in Q3 2013:

    - we used DMO - you need SolMan for DMO to be able to generate SP-stacks for the upgrade part

    - DMO needs to be configured accordingly to utilize all resources of direct migration

    - DMO - is still sensitive about proper r3* kernel programs patch levels (r3load, ...) and during migration it creates 'shadow copy' of your system - if DMO get's stuck - look for OSS Notes and make sure you update the right instance if required

    - 1st 2-3 steps (check, prepare, ...) took us much longer then the last steps (execute, post-migration) .. don't panic if it's your case, it just takes time to make sure system is consistently migrated, the physical DB migration to HANA is then pretty much light-speed

    - be careful with SAP Partner ABAP-addons - cluster tables need to be registered  with SAP in order for DMO to know them and convert them to HANA - if it is not the case ... some manual workaround might be needed after the system is migrated

    - make sure you have the right installation keys and licenses provided when starting the DMO otherwise your post-migration steps can have issues (due to locked securestore ... i.e.)

    That's pretty much all I remember 🙂

  • Hi Boris,

    unfortunately, this list is not complete.It doesn't mention CU&UC as a valid option (see SAP note 928729) and it doesn't contain the reference to the incremental approach (see SAP note 693168) that is relevant for all customers who can't afford a system outage of 6+ hours or even several days. The downtime of all approaches described above are dependent on the size of the application data whereas with MDS / NZDT we can already decouple the downtime from the database size since the majority ofthe data is already migrated during the uptime.

    Kind regards,


    • Hi Ronald,

      Thanks for your remarks, but I guess these would rather apply to the list of "Downtime-Minimization Options" on the Classical Migration to SAP HANA page in SCN.

      But also there, Unicode conversion is not handled in detail - we list the option to combine the database migration with the Unicode conversion, but I agree that we should then also list the CU&UC option, so I just added it there 🙂 .

      Concerning IMIG: as this is offered as downtime minimization service (and no longer as tool approach), we decided not to list it, as we wanted to focus on the standard procedures, not on service offerings. This also applies to NZDT, where we listed "only" the corresponding functionalities that were integrated into the standard maintenance procedure as offered by SUM. We had some of these aspects (such as NZDT and further service offerings, such as RDS packages and the services from AGS) covered in our SAP TechEd session in 2013 (ITM212 - How to Migrate ABAP-Based SAP Systems to SAP HANA), but decided to focus here on the standard procedures.

      So, I would see the information provided here and on the referenced DMO and classical migration pages as a good starting point, even if certain aspects are not covered (such as service offerings).

      But if you should know a good overview of these downtime-minimization offerings and services, I would be glad to link it from here. Or we add this aspect to the list of offerings and just list the service offerings there - I will drop you a line to discuss this option.

      Thanks again + best regards,


      • Hi all,

        With the support of Ronald and colleagues, we now added also the SLO offerings used for the transformation of existing systems (such as via partial migration) into the decision matrix. Thanks again for bringing this topic up!

        Best regards,


  • Hi Boris

    Thanks for your sharing!

    Now we're discussing a migration from ecc on RDB to Hana and

    we hesitate to decide which migration path is better for our client.

    On the chapter [2. Individually Assess Your Situation]  you shared the following Document and I confirmed it.

    End-to-End Implementation Roadmap for SAP NetWeaver AS ABAP

    But I cannot find any links to the  lastest version of the matrix about [How To Choose the Best Option],

    could you kindly tell me where I may get the lastest matrix info?

    Thanks in advance.


    • Hi Xiaoming Yang,

      The latest version would always be published in the End-to-End Implementation Roadmap guide, so the guide already contains the latest version. If you should miss something there, please let me know. We plan to review the matrix in the next weeks (also as preparation for SAP TechEd 2015).

      Best regards,


      • Hi Boris

        Thank you for your quick response!

        I just thought that there might be a more detailed matrix somewhere for more various patterns of source SAP system. As our source SAP system has a different EHP level against the patterns which were listed in the matrix.

        Now I understand that the lastest version of the matrix was already contained in the guide. So there isn't a more detailed matrix for more patterns of source SAP system is it?

        Best Regards

        • Hi Xiaoming Yang,

          Now I see your point - the releases listed in the matrix were only examples to make the overall concept more tangible. It is not intended as a tool that will list all supported start releases and map those to the available tools. Rather, it is meant to give some guidance about what aspects to cover and about the different options we generally see. So, for your specific case, you should check if your start release is supported by DMO and if yes, you could check your boundary conditions and get a good starting point for discussion inside your project team. Again, the matrix is not intended to give a final strict guidance from SAP, it is rather meant to provide a starting point for your individual discussion in your migration project team. Hope this clarifies things a little bit.

          Best regards,

          • Hi Boris

            Thanks for your kind answering! Now I understand the positioning about your matrix.

            We appreciate your precious advice and I think it would be helpful for our discussion.

            If any useful sharing, I'd like to give you a feedback

            Best Regards

    • Hello Rodolfo,

      In principle, this should also apply for SAP Business All-in-One solutions, as those comprise SAP ERP, SAP NetWeaver and SAP Best Practices, but I will cross-check again if there are any special aspects to consider.

      Best regards,


  • Hello,

    So much information to say migration from SAP instance (like ECC or CRM etc. ) to HANA via SUM DMO.

    We have applications like Hybris and Ariba, can someone please guide on how to go about the Migration to HANA please



  • Hi Boris Rubarth & Boris Zarske

    recently heard that we can use DMO to migrate anydb to HANA for HANA ready Product Version instead of using classical migration, just want to clarify how true is this...

    Is it possible to use DMO to migrate HANA ready Product Version (eg: EHP7 on oracle) by skipping the updating/upgrading part?

    Is this currently under SAP development or SAP DMO roadmap in near future?

    Hope to hear from you soon.


    Nicholas Chang

  • Good afternoon Boris / all,

    I have a requirement to move to HANA from DB2/ERP6 EhP7 SPS05 UC and I am still unsure of the best path to follow? I assume that as I am @Ehp7SPS05 I can generate a stack.xml to take me to SPS10 and use DMO which may reduce downtime.

    However if I follow Classical approach (heterogeneous system copy) then I have no need to upgrade the application which means functional testing should be minimal compared to a update project which means a simpler project.

    Are you able to offer any advice that I can use to make the best / safest decision?

    Any experiences would be appreciated.


    • Dear Alex,

      Well, you mainly listed the relevant aspects already yourself, similiar to what aspects you would be pointed to by the decision matrix listed above - if you are fine with staying on SPS05, the classical migration would be a valid option, as no upgrade would have to be included in the overall procedure. If you rather want to include the update to a higher SPS, DMO would be the recommended way to go. Looking only at this isolated use case, it would really come down to this question of the desired target SPS release (besides such aspects as how your experience level with SUM or the classical migration procedure looks like).

      But maybe this would only be the first system in a series of planned migrations. Then, you should also consider the requirements for your overall system landscape - if there should be systems that are to be migrated midterm and that would imply an update, gaining first experience with DMO already today could then also be reasonable and would result in a homogeneous migration approach for your overall system landscape.

      Does this make sense?

      Best regards,


      • Boris,

        Many thanks for your prompt reply and yes all makes sense.

        I just wanted to check my logic and then make an informed decision.



  • Hi Boris

    Good Morning... and thanks for your nice write up.

    I have case of ERP system with HANA ready version (ecc6 ehp7) and as per your decision matrix (Sec 2) Classical migration is best possible option as we don’t have any upgrade requirement. However from minimum downtime perspective which option DMO (need to consider single level of ST-PI upgrade to generate xml file) or Classical do you recommend? 

    Basically I like to know, In terms of Export-import time (considering the same hardware and number of R3load), which tool is more efficient .i.e DMO or SWPM (Socket)?

    Regards / Pallab

    • Dear Pallab,

      On tool level, the export/import is performed in both approaches using R3load, so no major difference should occur there, if optimized parameters are used. The difference is rather on a higher level: while DMO offers an automated procedure (having expert knowledge included) that automatically optimizes parameters such as table splitting based on the durations file, optimizations have to be identified and performed manually with the classical procedure. If you are an expert or consider corresponding best practices, the actual technical export/import times should be comparable according to my experience.

      Best regards,


      • Hi Pallab,

        In addition to what Boris wrote, from my perspective the main differences between the SWPM socket mode and DMO pipe are the following:

        - With SWPM you can distribute the R3load processes on two servers, however, there is a network in between these servers that may become the bottleneck. With DMO memory pipes are used as all R3load processes run on the same server.

        - With SWPM there is a straightforward procedure in place to resume the export/import of a failed package while the migration is still running. With DMO the failed package will only be picked up after all of the other packages have been processed. Boris Zarske: are you aware of any improvement in this area?

        - With SWPM the technical downtime consists of the export/import time, with DMO upgrade downtime has to be added.

        Do you already know the blog ?

        Maybe your question fits better into that context?

        Kind regards,

        • Hello Ronald,

          concerning the "picking up of failed packages". There might be something on the way and it might be available with future SUM DMO Versions.

          I would recommend to check the following Link on a frequent basis ( Short history of DMO ) as well as the specific SUM DMO release Notes about updates on this.

          Regards André

  • What will be best way to migrate ECC on SQL Server to ECC EHP7 Hana DB

    Is still classical migration works ?

    Is there any specific approach for moving data from sql to HANA ?

      • Yes, observed the matrix but I did not find any database except Maxdb .Does it mean that any source db(with required level) can migrate to HANA using SWPM/DMO ?

        • SAP Max DB is listed under "example scenario", so it is only meant as representation for any source database. So, the covered procedures all apply for the full list of source databases supported by SAP (certain "local" restrictions might apply, but those would then be described in the corresponding documentation of the desired option).

          • Such a scenario would require two steps to be executed sequentially: 1. Run SUM DMO on your Windows 2008 application server, 2. Install a new PAS on Linux. I assume that you are already familiar with SAP note 2161397, section I.

  • Thanks all for your valuable comments , for example for below scenario .

    1. Found that , no option to use DMO directly since it's datacenter migration

    2.  i can't directly use the Classical migration , where SAP upgrade to minimum EHP6 is required before going for Classical migration (2 step approach)

    3. Is there anyway to use directly DMO to perform upgrade+Migraton in one step ?

    Looking at the options i have below option

    1. export and improt to the new data center(heterogeneous to linux)

    2. DMO for upgrade+hana migration

    is there any best way to reduce the downtime?

    Source (DataCenter A) Target (Datacenter B)
    ECC6.0 ECC6.0 EHP7
    Oracle Aix HANA/Linux
    • Dear Veeramalla,

      As you already wrote, DMO is not supported for migrations across data centers, as stated in SAP Note 2198483. Instead of performing two migrations (1. to datacenter, 2. to SAP HANA), I would rather try to optimize the classical approach, as outlined in Classical Migration to SAP HANA --> section "Downtime-Minimization Options". For example, you could use downtime-minimized capabilities of the upgrade procedure and use the best practice guide to optimize the heterogeneous system copy. This should outweight the second database load you would have to perform for the move to the second data center in addition to the savings you would gain by using the DMO procedure.

      Best regards,


      • Hi Veeramalla,

        if downtime reduction is your main objective you may have a look at SAP note 693168. SAP Consulting offers a service that reduces the technical outage for the upgrade, the data center relocation and the HANA migration to usually well below 12 hours. Details on the procedure are described in the document and are available on request via

        Kind regards,


  • anyone got migration plans? mainly showing the tasks involved in migrating from HANA to CLOUD? any model would do, as a sample document sequential set of tasks would help to get some idea. Appreciate if someone can share any sample migration plan doc.

    you may send it to my email id :



    • It depends on your source database platform. If it's not DB4 you can use SUM DMO for a one-step upgrade and migration. See e.g. SAP note 2198483.

      If you split the project into two separate ones you will have to double your functional test efforts. Usually this is related to high costs that can be avoided.

  • When you say "SAP HANA" are you saying SAP Business Suite for HANA. I am getting confused as there are now so many resources talking about this HANA migration.  For example side-car, LOB, company code, etc.  Are we able to try and combine all this SCN blogs/resources into one blog?

    See below, what is the difference between "transition" and "migration".


    • Hi Warren,

      As you already stated, we distinguish between "migration" (which means a change of the OS/DB platform, required for example to exchange anyDB for SAP Buisiness Suite or SAP Buseinss Warehouse or SAP NetWeaver) and "transition" (of which the database migration to SAP HANA is a part of, but which requires more, as also business logic/table structures/... get changed, as SAP S/4HANA and SAP BW/4HANA are own product lines). At SAP TechEd, we have session ITM200 that provides an overall picture (migration paths to SAP HANA for SAP Buisiness Suite + transition paths to SAP S/4HANA). After SAP TechEd, I will try to trigger the creation of an overall overview based on our corresponding material.

      So, thanks for this proposal!

      Best regards,


      • Thanks Boris!  So transition is meant more for S/4HANA with a migration.  Where the "migration" is to only move ECC6 on anyDB to SAP Business Suite for HANA.



  • Hello Boris,

    We are planning to perform migration of Bank Analyzer 9.0 on Oracle 12c using SUM DMO to HANA DB, It would be great if you could help in getting all documents that needs to be referred to perform this migration. Thanks in advance


  • Hello All,


    I have to perform a upgrade and migration of BW system into Hana 2.0 SPS1,which is currenlty in iseries server (DB being DB4_53 and os is (iOS 5.3) using DMO. Can you please help to know is there any specific document/guideline to be followed for this activity.Because for Iseries severs i am unable to find any help for it.




    • Dear Irfan,

      The blog above is outlining the options you have to move from anyDB to SAP HANA - this also applies for SAP ECC 6.0 running on Oracle. As stated above, DMO is our standard recommendation, please find corresponding links to further information above.

      Best regards,

  • Dear Boris,

    We need to migrate existing solution manager[7.2 and ABAP & Java running on different servers, Linux ] to HANA DB. So could you please suggest if the DMO option with DB Migration is feasible for both ABAP and Java Stack?

    Or else do we need to go with classical approach - hetrogenous System copy option.

    Sanath Kumar

    • Dear Sanath,

      For the move from SAP Solution Manager 7.1 to SAP Solution Manager 7.2 on SAP HANA, we offer a special procedure using DMO outlined in the following blog:

      For your requested scenario (coming from SAP Solution Manager 7.2), I cross-checked with our SUM colleagues and (in contrast to my initial statement) they confirmed that DMO usage is also possible and released for SP updates inside the SAP Solution Manager 7.2 track, that is for the path of the ABAP stack from SAP Solution Manager 7.2 on anyDB to SAP Solution Manager 7.2 on SAP HANA.

      For the Java stack of your SAP Solution Manager 7.2, there is no DMO procedure in place, so a heterogeneous system copy using Software Provisioning Manager would be the right approach.

      Best regards,


    Hi Boris,

    I'm fear to make hay of something.

    I want to make a heterogeneous systemcopy from Linux / Oracle - SAP ERP 6.0 EHP7 to Linux / HANA without any Upgrade.

    The source system is NON Unicode.

    It is mandantory to use DMO Migration tool, because we have an NON Unicode source System?

    Or can we do the Migration by using the SWPM tools?


    Many thanks for your reply!

    Best regards,



    • Hi Elke,

      No, DMO would not be mandatory, as you can also combine the classical migration with Software Provisioning Manager with a Unicode conversion. Please consider the information provided in the system copy guide, such as that you should be aware that R3load requires significantly more CPU time with a combined Unicode conversion, resulting in a reduced number of configurable R3load jobs (for example, see the system copy guide for UNIX/ABAP towards SAP HANA, section "Unicode conversion").

      Best regards,