For many customers, SAP HANA minimum system requirements are a step or two away, requiring an application upgrade, hardware upgrade, and possibly even Unicode conversion. What are techniques and strategies to make the steps a reality and help establish a solid footing for moving toward an SAP HANA platform?
Read the transcript of the discussion with Basis & SAP Administration 2017 speaker Deb Donohoe and her colleague Christian Baessler to learn about on preparing for an SAP HANA upgrade. Get expert advice on choosing an upgrade path, planning tools, unicode conversion and more. Questions included:
- What are the specific ABAP syntax statements that become obsolete with SAP Business Suite on SAP HANA? SAP S/4HANA?
- From a client perspective, is it possible to only upgrade a portion of the client’s SAP modules or does the entire suite have to be upgraded?
- Are there any advanced SAP HANA migration techniques to reduce total migration downtimes?
- What is the Basis effort required to perform the SAP HANA upgrade from the SAP ECC EHP 6 system?
If you haven't already, subscribe to SAPinsider Online for free today!
Meet the panelist:
Deb Donohoe, Enowa
Deb is a Sr. SAP Technology Consultant with Enowa providing focus in Basis Administration, Security Administration, and Solution Manager. With over 20 years in IT and more than half working specifically in the SAP space, she has a broad understanding of technology concepts as well as business processes and corporate cultures. Deb’s roles have included day to day administration of networks, servers, databases, SAP systems, SAP security, Network security, as well as team lead or participant in new installs, upgrades, rollouts, and migrations. She’s been fortunate to work on SAP NetWeaver ABAP and JAVA stacks, Solution Manager, R3/ERP/ECC, BW/BI, EP, PI/XI SLD, BSI Tax Factory, Vertex, RWD, MS Server, MSSQL, Oracle, Linux, and HANA. Deb holds a M.S. degree in Computer Information Systems and a B.S. degree in Computer Science, Cum Laude as well as ITIL, CNA, and A+ certifications.
Matthew Shea: Welcome to today’s Q&A on preparing for an SAP HANA migration. Thank you everyone for joining us today. It is my pleasure to welcome Enowa’s Deb Donohoe and Christian Baessler! Thank you for taking the time today to answer questions on choosing an upgrade path, planning tools, Unicode conversion, and more. We already have several questions posted. Please enter your questions into the module below.
Deb Donohoe: Good morning, I am Deb Donohoe from Enowa and I am happy to be here with you. I hope we are able to provide some helpful information for you today.
Comment From Guest: You can now upgrade from SAP ECC 6 EHP 6 directly to SAP Business Suite on SAP HANA. Does this mean that at the end of the project you can be on SAP ECC 6 EHP 6 on SAP HANA? Or is this just the starting point and at the end of the project you are on SAP ECC 6 EHP 7 or 8 on SAP HANA?
Deb Donohoe: Hi. That will depend on if you incorporate an upgrade to EHP 7 or 8 during the migration to SAP HANA. Depending on the size of your database and other factors it may make more sense to do in two steps. Either upgrading EHP first or migrating to the SAP HANA DB and then doing the other. The most important thing is to ensure that your kernel is Unicode if not already. It is mandatory for SAP HANA and EHP 8.
Comment From Fabrizio: Hi, is it mandatory to update our system SAP ECC 6.0 to a specific SP before the SAP HANA migration?
Christian Baessler: Hi, this is Christian Baessler. My background is Basis, System Architecture. I have been performing migrations of SAP Business Suite to SAP HANA since early on. To answer your question, there are generally two main approaches to migrate to SAP Business Suite on SAP HANA:
a) Classic heterogeneous system migration:
With that approach, basically the underlying DB platform is switched, e.g., from a source system running on Oracle to target on SAP HANA. That requires that the SAP system is on an SAP HANA supported release. For SAP ECC the support started with EHP 6, but preferably EHP 7 or EHP 8. (EHP 6 works, but there need to be more notes applied and — at least in older SUM versions — it was a slightly different procedure. Myself, I have not done an EHP 6 procedure the past year as option b) is now the standard.)
b) DMO option:
This option combines an upgrade and a migration to SAP HANA (or SAP Adaptive Server Enterprise) in one major step. One of the advantages is that the source release can be relatively old. (I believe as old as 4.6C for SAP ECC and SAP R/3 — you would need to double check if it’s relevant.)
In summary: If you choose DMO (recommended for most cases) your source release does not need to be on a specific “ECC” release.
Comment From Jeff.Walberg: What are the specific ABAP syntax statements that become obsolete with SAP Business Suite on SAP HANA? SAP S/4HANA? Can you upgrade to SAP Business Suite on SAP HANA from SAP ECC 6 EHP 6? If yes, at the end of the project can you really still be on SAP ECC 6 EHP 6 on SAP HANA? Or is this just a starting point and at the end of the project you are on SAP ECC 6 EHP 7 or 8 on SAP HANA?
Christian Baessler: Several questions — I’ll try to split these:
a) Specific ABAP syntax: I will answer that in a couple of minutes in a different thread.
b) See my last response to Fabrizio’s question. Using DMO you can upgrade from pretty much any SAP ECC source (or even R/3) to the latest and greatest. With heterogenous database migration (classic) you need to be at least on EHP 6.
c) Can you still be on EHP 6? Not with DMO: the target is at least EHP 7 from what I recall. But if the source is EHP 6 you can choose a “heterogenous system copy” method which will not change anything on your SAP release level.
That is the technical perspective. From a project/added value perspective, as an SAP HANA migration without changing the SAP release requires major testing (lots of things might be changed — interfaces, z-code, but even SAP code you want to test) it might make sense to do a migration upgrade at the same time. The testing effort is more or less the same.
Comment From Abul: What are the steps and guidelines for a FICO consultant to migrate to the SAP S/4HANA on-premise platform from EHP 8 (pre- and post-check)?
Deb Donohoe: Hi Abul, that is a little out of scope for us, here we are focusing on the technical changes. That being said, you can review the simplification list in SAP Solution Manager maintenance planner for SAP S/4HANA migration and that should give you some guidance.
Comment From Guest: What are the specific ABAP syntax changes that become obsolete with SAP HANA that work on SAP ECC 6?
Christian Baessler: ABAP syntax becomes obsolete usually due to a newer SAP release — not due to a newer or different underlying database. This assumes that your code complies 100 percent with the ABAP requirements of your current/target release. But whose code does comply 100 percent...? In real life, code has been written a long time ago and still lives in your system and does its job in the current database. There are situations where “dirty” coding works perfectly fine in your current environment, while it will produce a different result on the target dataset (or newer DB release). In a couple of our recent SAP HANA migration projects that was the case. (The issue was the source platform DB was implicitly sorting based on the primary key, while SAP HANA does not guarantee that). According to ABAP standard implicit sorting cannot be assumed (but a lot of developers assume it, as it has been working for decades). Thorough code review (of z-/y-code) is strongly recommended together with a thorough (!) testing of z-code on the target platform
Comment From K. Mason: Is there specific testing that should be planned for during a Unicode conversion?
Deb Donohoe: Hi, the normal testing for any system change or upgrade should be included in the project plan. However, an important target for testing during Unicode conversion is the interfaces, especially EDI, as it is usually impacted.
Comment From Manish: Can we use distribution monitor when we do classical migration to SAP HANA?
Christian Baessler: I think you can. I have not done it myself in an SAP HANA migration project, but in Unicode conversions. As it is a fairly similar base process I would assume so (and it would be helpful). I do need to research that more.
Comment From Alex: From a developer’s perspective, what are some of the biggest coding differences we’ll need to learn once we’re on the SAP HANA DB?
Deb Donohoe: Hi, can you take a look at Christian’s answer re: specific ABAP syntax changes and see if that helps?
Comment From Priscilla Wynn-Brown: How long does it take to upgrade from SAP ECC 6.0 EHP 7 to SAP HANA for a database size of 8GB using the DMO option?
Christian Baessler: I assume your SAP ECC system has more than 8GB... (If so, you might want to share how you accomplished that. ;-) ) I guess you mean 8TB? Compressed/not compressed? With all honesty, it depends on several things and a good estimate is hard to give till you know the details. A few factors:
1) Hardware (Disk, CPU, network speed) of source and target
2) Chosen approach (heterogeneous migration/DMO)
3) The database content itself: some tables are relatively fast to export, some others are very CPU intense (cluster/pool tables). (Usually the biggest time consumers are the cluster and pool tables, so it depends strongly on the size of these tables.)
I assume the real topic behind is: How much downtime do we need to request from the business for a migration? General rules:
1) The bigger the system, the more downtime you need for any approach.
2) The more downtime you have, the less effort for preparation, special procedures, etc. you need to lower the needed downtime.
3) There are parameters and so on which take relatively little effort (and low cost) and reduce the downtime pretty impressively (easy catches). Once you hit a certain spot, further reduction of downtime comes with a higher price tag. It would be unserious to make a guess for migration downtime without any additional information on the above listed factors.
Comment From Manish: Are there any advanced SAP HANA migration techniques to reduce total migration downtimes?
Deb Donohoe: Hi Manish, because an SAP HANA migration is really a database export and import, the key technique for reducing downtime is the management of the data. If archiving is not already in place, that is a good place to start. Reducing the overall database size to what is relevant and required will reduce the downtime. Additionally, you should review the processor allocation and performance and increase those if applicable. The export and import activities are CPU intensive so more resources will help. Table-splitting is also an important step to take advantage of or maximize CPU utilization. Exercising multiple test runs will help determine the point at which the export and import are executing the most efficiently.
Comment From Priscilla Wynn-Brown: What are some benchmarks taken in regard to the time it takes to upgrade from SAP ECC 6.0 EHP 7 to SAP S/4HANA with an Oracle database size of 10GB?
Christian Baessler: A recent migration (classic, heterogenous system migration) for a 5GB uncompressed Oracle DB had 24 hours’ downtime completely, while only 50 percent of the time was used for the data migration. The other 50 percent of the time was backup before/after, testing, and other activity. This timing was relatively “comfortable.” As mentioned in a previous answer, this strongly depends on many factors of your system. Real numbers you get when you execute an export/import (or DMO) the first time. Also, then you get a good idea where the bottlenecks for your individual environment are and if/how you can address it to reduce downtime.
Comment From Tim: Hello, what do you recommend as ways to minimize the downtime window for an upgrade to SAP HANA from Oracle? We want to keep the downtime window as short as possible.
Deb Donohoe: Hi Tim, please see my answer to Manish and let us know if that satisfies your question or if you have additional questions.
Matthew Shea: Thank you everyone for asking such great questions today. We have time for a few more posts before we wrap up the Q&A at 12:00.
Comment From Laurence: We are planning a migration of SAP ECC, SAP BW, and SAP SCM to SAP HANA. One of our assumptions is that it is not recommended to transport fixes/changes from an SAP HANA development system to an Oracle PRD system (therefore requiring SAP HANA and Oracle development and QA systems to coexist during the migration project). Is that assumption correct?
Christian Baessler: I assume you migrate just the database and do not upgrade/patch the SAP system? If so, theoretically it does not matter on what database the DEV SAP system is running on and what PRD is running on. Transports (and the content of the transports) mainly depend on the SAP release, not on the underlying DB or OS. Having said that, there are exceptions to this rule. For example, code which is DB native code, code writing/reading from OS, and so on. But for the majority (I would say 99.5 percent) of content in transports you could come from source Oracle to target SAP HANA (or any other combination). It depends on the risk tolerance and the willingness to pay for an n+1 landscape during the migration if that approach is suitable.
Comment From Albert: We do use SAP SRM-SAP MDM which is using a small Oracle Database. What do you recommend for such a product? Is it SAP HANA compatible?
Christian Baessler: Albert, I don’t have an answer to your question out of my head. If you’re interested we can follow up. Will you participate in the Amsterdam show in June? If so, we can discuss it there.
Comment From DMarquis Allen: From a client perspective, is it possible to only upgrade a portion of the client’s SAP modules or does the entire suite have to be upgraded? Another way of asking this question: does it make sense to only upgrade more “business critical” modules before upgrading the entire suite?
Deb Donohoe: Hi DMarquis, while technically it may be possible to upgrade specific components of an SAP product (SAP ECC, SAP CRM, SAP BW, etc.) it is never advisable to do that. The only components that can be updated independently are add-ons (such as ST-PI or ST-A/PI which are used by SAP Solution Manager) or a third party, but be careful to ensure the system requirements are met and satisfied. SAP releases the product (suite) upgrade or Support Package Stacks as a complete set and the best practice is to include the entirety. That set is tested, validated, and supported.
Christian Baessler: Often it makes sense to upgrade/migrate to SAP HANA, e.g., only BW, while you keep your SAP SRM system on the old platform. After all, SAP HANA hardware does not come from a discounter... So if your budget is limited you might want to migrate to SAP HANA only the most (read-) performance critical SAP system and keep the others on a more affordable platform. Same applies for upgrades. However, there are certain dependencies between components and you don’t want to be too far apart in the generations. Within one system, as Deb stated, it’s more or less an all or nothing. Not necessarily from a technical perspective, but more from a project organizational aspect — if you “patch” one component within your SAP ECC system you probably need to test a bunch of other components as well due to dependencies, interfaces, shared master data, etc. If you test it’s a perfect opportunity to patch these components as well.
Comment From Alex: Christian’s answer tells me that most code will work “as is” when moving to the SAP HANA DB with a few exceptions. I’m wondering what performance advantages we can leverage in our everyday code? Should SELECT statements be written differently to get the most of the SAP HANA DB? Things like this. Thanks.
Christian Baessler: Alex, you are correct in your summary. However, only testing shows. Don’t skip the testing during such a project. Only that will ensure that it works on the target platform. SAP HANA comes with its own programming technique to take full advantage of SAP HANA’s performance potentials. This is a topic for another discussion. Most customers choose to migrate first to SAP Business Suite on SAP HANA and leave the code — if possible — unchanged, and then later, when the migration project is finished, start improving the code on an individual base.
Comment From Ravindra: What is the Basis effort required to perform the SAP HANA upgrade from the SAP ECC EHP 6 system?
Christian Baessler: Hi Ravindra, I’m not sure if I fully understand what you are trying to accomplish. I assume that you want to migrate to SAP HANA and upgrade during the same downtime? It would be too much to explain and draw a full project plan here. Generally said, the effort is a combined upgrade and migration. The main benefit to do this in one major step, e.g., with DMO approach, will be the need for only one testing effort (whatever is involved, e.g., your past upgrades) instead of twice.
Comment From Tim: Hello Deb, yes, your answer to Manish was helpful, but I am looking to see if you have more specific recommendations on table splitting, SWPM parameter changes, and testing strategies. Also, how many test runs have you done before Go-Live in previous migrations?
Deb Donohoe: Hi Tim, it really depends, unfortunately, on your environment. If the database is small and you have a decent downtime window available, less effort and test runs are required. If you have a 10TB database and only a 10-hour downtime, that is trickier and will require more exhaustive test runs. You can look in DBACOCKPIT to determine the largest tables and those are the ones you will target during the splits. There are some considerations with cluster tables as well, too much to go into here. So in addition to archiving, I did not mention also ensuring the technical tables and housekeeping of those is in place and that they are not excessively large. The last I did was on a 3TB database and it took 5 test runs to get the optimum settings for the table splits. It is also important to have the hardware for the test runs be identical to the production hardware. This will give the most accurate predictions for the go-live.
Comment From DMarquis Allen: Last question from me: Have there been any reports of failures or unexpected behavior during an SAP HANA migration? If so, is there any documentation that covers common pitfalls to avoid or techniques/strategies to remediate?
Christian Baessler: Well, simply said: yes. If it would be that straightforward a lot of people would be out of business. The straightforward, out-of-the-box systems usually work without major issues. But I have hardly seen a system which is 100 percent out of the box — at least not in the SAP world. Therefore, we recommend performing your upgrade/migration in a Sandbox environment, hoping to discover and remediate all the things which do not work in your case. If you hit an issue resolve it with Google, OSS, or your own experience. I have not seen a complete “list” or anything like that describing all pitfalls. Not for SAP HANA migrations nor for any other task in the SAP world. :-(
Matthew Shea: Thank you to Deb and Christian for your time and for your insightful answers. Deb will be presenting 3 sessions at Basis & SAP Administration 2017:
• The basics of Basis administration 101: Architecture, monitoring, troubleshooting, and more!
• SAP upgrade and Unicode conversion: A step toward SAP HANA
• The Basis administrator’s critical role in SAP system security
You can review the Q&A chat replay at any time, and I will alert you by email when the transcript of today’s discussion is posted.