Relevant Aspects for Planning a Migration Project to SAP HANA
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 🙂 .
Integration of SAP HANA into Your Data Center
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:
- Blog from Alfred Brosig: Take Your Choice: How to Integrate SAP HANA as Smoothly as Possible Into Your Data Center
- Blog from Florian Müller: Now It’s Up to You to Perform The SAP HANA Installation!
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.
Check Supported Platforms, Releases, Add-Ons, and Possible Restrictions
- Make sure your product is released on SAP HANA and restrictions do not apply – see the Product Availability Matrix (PAM) for your product (SMP login required)
- Not all add-ons and third-party products are currently supported, so check early. Current SAP Notes that provide corresponding information at the time of writing this blog (SMP login required):
- SAP strongly recommends that all other partner add-on products need to be certified for SAP HANA – for more information, see the Partner Information Center.
Sizing of SAP HANA
- See SAP Note 1514966 (SAP HANA: Sizing SAP In-Memory Database)
- See http://service.sap.com/sizing (SMP login required) –> Sizing guidelines –> SAP In-Memory Computing
- ABAP sizing reports for migration to SAP HANA:
Define Your Overall Target Landscape
First, get an overview of the available deployment options and corresponding recommendations from SAP:
- Such as virtualization, multiple components on one system (MCOS) and on one database (MCOD), and the option to run SAP HANA and SAP NetWeaver on one server
- For more information, see for example (SMP login required):
- SAP Note 1826100 (Multiple applications SAP Business Suite powered by SAP HANA)
- SAP Note 1661202 (Support for multiple applications on SAP HANA)
- SAP Note 1681092 (Multiple SAP HANA databases on one SAP HANA system)
- SAP Note 1788665 (SAP HANA running on VMware vSphere VMs)
- SAP Note 1953429 (SAP HANA and SAP NetWeaver AS ABAP on one Server)
Then, based on the available options, define your overall target landscape:
- Such as, if you want to put development and QA system on one SAP HANA system
- Scale-up (scale vertically by increasing size of hardware) versus scale-out (scale horizontally by adding nodes)
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.
Further General Aspects
- Technical Operations Manual and Administration Guides
- SAP HANA in Data Centers, covering topics like:
- Platform & Appliance methodology (Installation & Update)
- Backup & Recovery (System Copy)
- High Availability
- Disaster Recovery
- Monitoring & Administration
- Security & Auditing
- Trigger SAP HANA hardware provisioning in time – lead times can be four to six weeks
- Plan for up-skilling of your database administrators
- Ensure SAP Solution Manager availability for your SAP HANA landscape
- Standard maintenance processes apply also for your applications running on SAP HANA like for any other SAP system.
- Optionally, you can profit from further features and possibilities when running on a higher SAP Solution Manager release, like in the areas of SAP HANA monitoring and CTS+ integration with SAP Solution Manager 7.1 SPS05 or higher.
Aspects for SAP Business Warehouse
- Consider the usage of near-line storage to reduce your database size to be migrated
- Perform housekeeping tasks before the migration to reduce your data volume
- If not already done, migrate SAP Business Warehouse authorizations to the new BI analysis authorization concept (as of SAP NetWeaver 7.0)
- See SAP Note 1729988 (SMP login required) for an automatic prerequisites check for SAP Business Warehouse systems
- For more information, see the SAP BW Application Lifecycle Management page
Custom Code Transition
When migrating to SAP HANA, your main questions concerning your custom code will most probably be:
- How can I avoid functional regression? Everything should work as before…
- How can I make sure that my custom code runs with good performance, at least as before?
- How can my custom code benefit most from SAP HANA, so that performance is boosted?
- What totally new business processes get enabled by SAP HANA that I could realize by new custom code?
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 🙂 ).
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.
Overall Project Plan
Finally, plan several cycles in your migration project, so:
- That you can familiarize with the migration procedure and optimize it based on your individual requirements and boundary conditions by performing several test runs with the right grade of realistic hardware and database content you require.
- That you can create, refine and validate your individual migration cookbook.
- That you can perform and validate mandatory code adaptions and simple code optimizations early in the project.
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 🙂 ,