Migration of SAP Systems to SAP HANA
Introduction
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:
- 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.
- 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.
- 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:
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.
Excellent material! Thanks for sharing.
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 🙂
Hello Richard,
Great, thansk a lot for sharing - would be great if you could also post your hints as comment for the DMO document (Database Migration Option (DMO) of SUM - Introduction).
Thanks again,
Boris
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,
Ronald
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,
Boris
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,
Boris
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.
Regards
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,
Boris
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,
Boris
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
Hi Xiaoming Yang,
That would be kind, if you could provide feedback, thanks a lot 🙂 !
Best regards,
Boris
Hi
This strategy would also apply for SAP All in One Solution?
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,
Boris
Hello Rodolfo,
Sorry for the late final confirmation, but it took me some time to get a corresponding statement from the SAP Business All-in-One solution that confirmed our assumption above. So, yes, the approach should also apply for this solution.
Best regards,
Boris
Thanks Boris
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
Regards
Krishna
Nice information Boris. Really appreciate it.
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.
Thanks,
Nicholas Chang
Hi Nicholas,
DMO combines update/upgrade and migration and does not work without update/upgrade, a stack.xml is required to start the procedure. Do you have a source for these rumors?
Thanks, Boris
Hi Boris Rubarth
Thanks again for your reply and confirmation, very much appreciate. I simply heard it from one of the vendor workshop.
However, we can utilize DMO parallel r3load migration (export/import) via pipe by generate a stack.xml with just updating a single level of ST-PI, for eg?
Thanks again,
Nicholas Chang
Hi Nicholas,
see answer in your cross-posting:
http://scn.sap.com/community/it-management/alm/software-logistics/blog/2015/12/15/optimizing-dmo-performance#comment-639367
Regards, Boris
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.
Alex
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
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.
Regards
Alex
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,
Boris
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 http://scn.sap.com/community/it-management/alm/software-logistics/blog/2014/03/20/dmo-comparing-pipe-and-file-mode-for-r3load ?
Maybe your question fits better into that context?
Kind regards,
Ronald
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 ?
What is your result using the decision matrix shown above for your project?
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).
Thanks for info!!
Can we use DMO incase of the change of Operating system(Windows2008->Linux) ? Can you please suggest references guides/blogs.
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?
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,
Boris
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 http://scn.sap.com/docs/DOC-10271 and are available on request via mds@sap.com.
Kind regards,
Ronald
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 : de@akkob.com
Thanks
Dev.
Can migration from 4.6c to HANA possible in 1 step or
better to go to ECC6 first and then HANA ?
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,
Boris
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.
Thanks
Warren
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
Regards,
Sameer
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.
Thanks
Saurabh
Boris,
Can we copy SAP ERP ECC 6 - Oracle database in ECC6 - HANA database.
Also share with me the step
Regards,
Irfan
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,
Boris
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.
Regards,
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: https://blogs.sap.com/2016/05/04/simplified-upgrade-and-migration-to-sap-solution-manager-72/
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,
Boris
Thanks Boris for the Reply
Hello Boris,
I have a question, are you sure that the scenario below is possible using SUM DMO?
Coming from SAP Solution Manager 7.2 ABAP Stack SPS 7 on Oracle, SUM DMO usage is possible and released for SP updates (SPS 16) 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.
I can' find a document/a guide describing the procedure for Abap stack.
Thank you for your help.
Best regards,
Zobair
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,
Elke
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,
Boris
Vielen Dank, Boris!
Dear Boris,
source-system (classic central instance, DB + PAS on same host:
OS:Â Â Â SUSE Linux Enterprise Server
DB:Â Â Â Oracle Database 12c 12.1.0.2.0 - 64bit
SAP:Â EHP7 FOR SAP ERP 6.0
is it possible to update the system to EHP8 with DMO to HANA2 on the SAME linux host?
Thanks in advance + best regards
Thomas
Dear Thomas,
I have reached out to our DMO experts from development and according to their understanding, this would be a "normal" DMO run from Oracle to SAP HANA, where it would not be relevant for DMO if the target database would reside on the same Linux host - at least, as long as you have enough hardware resources to have all on the same host. From tool side, there should be no restrictions in that direction. Therefore, this should be possible.
Best regards,
Boris
Hello Boris,
We need migrate our BW Netweaver 7.5 ( MSSQLServer - Windows) on Hana 2.0 Linux RedHat.
Target system in distributed mode : 1 VM Linux for Hana 2.0, 1VM Linux for ASCS/PAS
We need keep the current version of BW/Netweaver (no upgrade)
What's the best way to migrate BW 7.5 on any DB to Hana 2.0, and without update ?
1/ SWPM classic method, system copy - export/import
2/ SUM DMO without update and SWPM system copy to reinstall ASCS/PAS on Linux
3/ SUM DMO without update + system move
Thanks in advance.
Regards,
Roby
Hello Roby,
I talked to my colleagues from DMO and they would consider this scenario foremost a system move, where also the app server would move to another host. For this, you could combine "DMO with system move" with "DMO without system update" (for target SAP HANA), what the colleagues would consider the easiest approach - this would be option 3/ in your list above.
As OS of source and target would differ, please take special care for the details („Restricions: With regard to operating systems“) of the corresponding section "c) DMO with System Move: Requirements and Restrictions“ in the DMO SAP Note. As you would have to use SUM 2.0, so latest SAP Note would be 3126581 „Database Migration Option (DMO) of SUM 2.0 SP14“.
I wish you great success with your procedure!
Best regards,
Boris
Hi Boris,
Many thanks for your quick feedback. We'll check the last SAPnote for the SUM/DMO 2.0
Best regards,
Roby