As preparation for a lecture about the available migration path options to SAP HANA, my colleague Volker Zirkel and myself gathered several aspects for the planning of a migration project to SAP HANA. It's not a complete list, some parts might seem trivial, aspects and recommendations are gathered from different documents and colleagues (thanks to everybody that supported us here!), but I wanted to share them with you via this blog nevertheless, and if it is only that you can cross-check your individual project plan :smile: .
SAP started by providing SAP HANA as appliance - there, you get integrated SAP software components (including the SAP HANA database, real-time replication services, data services, data and lifecycle management, and SAP HANA studio) running optimized on hardware delivered by our hardware partners. The benefits should be clear - you profit from a fast implementation (due to the pre-installed software) and support is fully provided by SAP.
Nevertheless, there might be situations where you would like to have a little bit more flexibility, so SAP decided to offer an alternative approach, named SAP HANA tailored data center integration that brings back some freedom of choice regarding your SAP HANA hardware landscape. For more information, see:
With SAP HANA, several aspects come into play - be it bare metal topics like network and storage, OS, DB, and, of course, the applications running on top of the SAP HANA platform. Therefore, build cross-functional teams right from the start already for planning the implementation of SAP HANA, as you have to come up with ideas concerning such diverse topics like appliance shipment, wiring + setup process, user management, adapting your development process, and operations concept for this platform.
First, get an overview of the available deployment options and corresponding recommendations from SAP:
Then, based on the available options, define your overall target landscape:
Besides all the boundary conditions to consider, choose your migration procedure (such as database migration option of Software Update Manager or the classical migration procedure with software provisioning manager), as outlined in the Migration of SAP Systems to SAP HANA page.
When migrating to SAP HANA, your main questions concerning your custom code will most probably be:
And this would exactly be the priorization of a standard migration project (although it might completely look differently for a proof-of-concept, of course :smile: ).
For this, SAP is offering improved and new tools, so my recommendation is that you take a look at the Best Practice Guide – Considerations for Custom ABAP Code During a Migration to SAP HANA. As you can perform investigations and also first adaptions of your custom code already on the source platform way before the actual migration, plan these activities early.
Test management affects all phases of a migration project - this is also true for a migration to SAP HANA. Be it the decision about testing tools and test planning in the preparation phase, the actual test execution and issue resolving during the migration project, or the later regression tests, like after the deployment of future SAP HANA revisions after the successful migration. To get an overview how SAP Solution Manager enables test management also for this special use case, see the guide Best Practice: Test Management for SAP Business Suite on SAP HANA Migration Projects.
Finally, plan several cycles in your migration project, so:
Again, I am aware that this is only a short glimpse at some of the relevant aspects, but as it was quite some effort to gather all these topics and links (and again a big THANK YOU to all contributors that supported us), I hope it is of some use for you.
All the best for your project planning :smile: ,
Boris
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
13 | |
10 | |
10 | |
7 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |