Welcome to the short presentation providing a quick overview of available migration part options for SAP ABAP Systems to SAP HANA. I have worked in the SAP Product Management in the area of System Provisioning. I have also worked on on-demand offerings such as running the applications on the SAP HANA Enterprise Cloud. This post focuses on on-premise offerings. This is our standard disclaimer which also applies for this presentation off course.
Let’s begin with a rough overview of the available migration options. For us, you could install a new SAP HANA System next to your existing system landscape. It’s so called Greenfield approach meaning to gain first experienced with in memory computing without actually touching your existing applications or which is more interesting in our terms for installing an existing as key solution tool this new SAP HANA System.
The second option would be the Classical Migration. Here you would perform an upgrade of your existing SAP System to a release supported by SAP HANA before you would then perform a Classical System copy to exchange the traditional database with SAP HANA.
And finally the third option, the One-Step Upgrade and migration with the so called Database Migration Option. Here we had to go to combine all the required activities into one step so it can perform one process with one tool which resides as one downtime.
On the next slides we will outline the different options in detail, let’s begin off course with a new installation for transformation. Here you could address required changes to your existing SAP landscape with the SAP Landscape Transformation Software. For example, you could transform your landscape by performing a shell creation and cutting out certain organizational units of your existing landscapes and bringing those to SAP HANA. Off course you would focus here on those business units which offer the most benefit for migration to SAP HANA gain first experience and afterwards you could perform a stepwise migration but also bring the other parts to SAP HANA if desired.
Or another option would be that the consolidated existing systems to reduce the total number of SAP Systems in your landscape. For example, if you have two SAP ERP Systems running on a traditional database you could use this offering to combine those two systems into one SAP ERP System running on SAP HANA. These software offerings are complimented by corresponding transformation services.
And offer the flexibility to move only parts of your business to SAP HANA and also provide the opportunity to correct design issues like combining two systems into one. Although, depending on the actual scope of this project those transformation projects could become complex, you could address this complexity for example, by just ensuring services. If you are interested in this offering there is more information on the SAP Service marketplace on the following address.
Let’s come to the second option, The Classical Migration option. Here, you would perform an upgrade of your SAP Systems to a release supported by SAP HANA before you would perform a classical heterogeneous system copy with Software Provisioning Manager.You could either perform a migration in place meaning you would only exchange the traditional database with SAP HANA or you could perform an OSTB Migration meaning you could also for example move your application service to a different hardware platform.
The result would be that you end up with a newly identical system which implies minimal impact on the functional teams and type of clear separation of concerns meaning you would first run an upgrade project, verify that everything works fine and then you would perform a migration project. Nevertheless this approach typically you require some extended downtime depending on the size of your database and you also require several downtime windows depending off course on the scope.
If you think for example you have to perform a database upgrade as the database release does not support the SAP version you require. This could mean that you in the end need up to three different downtime phases one for the database update, one for the SAP System upgrade, and one for the Classical Migration. And also, the inclusion of the upgrade you fall back to the original state would only be possible via a restore. Let’s take a very short look at the different phases of this Classical Migration.
First you would have a Prepare Phase then the Upgrade Phase and finally the Migration Phase. During the Preparation Phase you would for example perform a dual-stack split, these dual-stack setups are not supported by SAP HANA. Or if you are still running a menu input SAP System you could perform the Unicode conversion in this phase. Optionally, you could also combine this Unicode conversion if required at all or is it during later in Migration Phase but if you want to have a clear separation concerns you could optionally do it as Preparation Phase. The second step would be your plan the upgrade of you SAP System to at least support by SAP HANA by using the Maintenance Optimizer in SAP Solution Manager, creating the stack XML file, downloading or required file which would then be used by the Software Update Manager to actually perform the upgrade.
And finally, you would use Software Provisioning Manager to create a database independent export of the data in your traditional database and use this exported data to setup the SAP HANA accordingly. Depending off course after this procedure you have to perform a typically classical post system copy activities like for any SAP System copy. If you are interested in this you can find more information in the SAP Community Network. For example, we have a page for the Maintenance and we have also page for System Copy Migration.
We are constantly working to improve this classical system copy procedure especially for the Migration use case and Migration to SAP HANA. For example, we have a best practice guide available that outlines optimization of best practices for example in terms of table and packet splitting. This guide is also available on the corresponding page.
Finally, our third option the one step upgrade and migration with the Database Migration Option. So, here again our goal was to bring all relevant steps into one tool and one process. Which I think done is some kind of big-bang approach. And this is exactly what the database migration option offers. So, we have brought all the required activities into one process which is then available its option in the Software Update Manager. And we see a lot of benefits from this approach. So, first of all manual efforts and risks are reduced. Also they are lower prerequisites in terms of SAP and database start releases. So, where we had to consider database updates in the Classical Migration this could be optimized for this procedure and for example, if your database platform would require license cost for it’s higher database release this is also something that we need to apply for this Database Migration Option. Also, in case you require a fallback only intermediate efforts would be required as the previous database would still be in place and you could reactivate it if required. Also depending on your scenario you could optimize the downtime and you would only have one downtime phase.
Let’s take a short look at the process here as well. So, would have your Classical SAP System stay connected to the traditional database and now would get SAP as appliance in the landscape, you would perform or start to process by performing to prepare phase of the upgrade and executing the upgrade until the downtime phase would start. So, this is all still done in the uptime of your SAP System. And in parallel you could prepare your SAP HANA System for the procedure. Then you would switch to database connection in the Downtime Phase and perform the actual migration meaning you would migrate an application data, finalize the upgrade and then be ready to start the SAP HANA based system. And as you can see you would have not only changed the database from traditional to SAP HANA but would also have performed the upgrade of you SAP System and would only have this one single downtime phase including also one regression testing phase required. So, if you are interested in this procedure you can find more information.
There is a block in the SAP Community Network and we have two SAP notes one for SAP Netweaver Business Warehouse, and one for the SAP Business Suite that provides more information here. In addition to the different option they are also, you also get a standard recommendation so that you can decide what fits best your requirements. Our general recommendation is to use the Database Migration Option. It has become the standard procedure for migrations to SAP HANA offering a simplified migration with minimized over project cost and risk. As a reasonable alternative to this general recommendation we see the Classical Migration. So, if the Database Migration Option should not fit your requirements for any needs for example if you are going to multiple roll-outs and not a big-bang approach you could consider to use the Classical Migration of the software Provisioning Manager optimized especially also for migration to SAP HANA.
And in case as possible our exception if there are further migration procedures for special use cases such as system consolidation if you went to consolidate two systems into two or if you want to only perform a stepwise or part migration to SAP HANA of SAP System. Use this standard recommendation a starting point for your individual assessment. So, off course it depends on your requirements or if you’re SAP Partner under requirements of your customer to really chose the right option. We plan to provide further information about choosing the right option in our end-to-end implantation guides which are available in the SAP HANA portal under the following addresses.
In addition to the software offerings we have two service offerings especially also for the migration to SAP HANA. On one side we have the SAP Rapid Deployment Solutions and they offer a lot, a whole bunch of different options especially for SAP HANA Migration use cases. If you are interested in this you can find more information on this page on the SAP Service Marketplace. And there is a holistic approach offering from our SAP Active Global Support that makes migration to SAP HANA easy and more reliable and faster. For more information please contact your local HES Contact person. With this I want to summarize what we have discussed today and give some key messages.
First of all, Database Migration Option has become the standard SAP HANA Migration Option, you can profit from one tool within optimize migration procedure to SAP HANA with only one downtime phase. In case of special requirements such as in terms of landscape transformation we are offering additional options to bring your SAP Systems to SAP HANA. And those are complimented by service offerings that allow a rapid and risk mitigated migration to the SAP HANA landscape. With this I want to thank you for your interest in this topic. On this page, feel free to leave a comment with any questions below. Thank you and good-bye.