In 2010 SAP released SAP HANA, a new proprietary database that isn’t so much an improved solution but a complete paradigm shift in how databases operate. HANA is quickly becoming a must-have asset for competitive businesses but, as with any new technology there are risks – so, here are six of the common risks you’ll face.
1. Problematic ABAP Code Causing System Crashes
Anybody familiar with SAP HANA knows that its revolutionary approach to data storage, management and analysis requires a new way of writing ABAP code.
Due to HANA’s unique functionality, any custom code written specifically to interact with other databases is now obsolete and could potentially interfere with your systems.
When migrating to SAP HANA, you’ll need to perform a thorough check of your code-base to identify troublesome code, including:
- Any instances of code that rely on database-specific features, for example, native SQL statements or the use of DB hints in Open SQL statements
- Any instances of code that rely on implicit sorting done by the database
- Any instances of code that relate to cluster or pool tables
- Any instances of code that aren’t written using new best-practices for SAP HANA
While some instances of incompatible custom ABAP code will simply result in significant performance degradation, others will cause fatal system crashes. Unfortunately, over the years your developers have probably written hundreds of thousands of lines of custom code, meaning a big chunk of your existing code-base could be incompatible with SAP HANA.
So it’s vital you clean up your custom code before migration, a process that’s also known as a HANA-readiness project.
2. Wasting Time and Effort by Creating a Much Bigger HANA-Readiness Project
Trawling through your entire code base to find every scrap of HANA-incompatible code can feel like an overwhelming task. With potentially tens of thousands of issues that need to be identified and fixed, it’s a thoroughly time-intensive job.
However, approximately 60% of all code is not actually used in the productive environment. If code isn’t being used, there’s no need to migrate it to SAP HANA, which means it can be excluded from your HANA-readiness project – instantly reducing it’s size and effort.
Turning on the Usage Procedure Logging (UPL) feature in your active environment can identify code that isn’t actually used by your systems and can, therefore, safely be deleted. Best of all, it doesn’t put any strain on your system, so there is no reason not to enable UPL right now, even if your HANA-readiness project hasn’t started.
3. Incorrectly “Fixing” Problematic Code
Once you’ve identified the problematic code issues that are essential to your systems, there’s still the task of researching the problem, looking up the new best-practice for rewriting the code and then making the appropriate fixes.
In our experience, most issues take an hour or less to fix, but rushing through your HANA-readiness project will only result in mistakes being made and lead to incompatible code being migrated.
Our latest update introduced automatic-fix functionality, which actually adapts your priority 1 (issues that cause critical system failures) ABAP code incompatibilities automatically – as well as some priority 2 issues (those that severly impair performance).
With this new functionality you’ll only need to focus on fixing the remaining priority 2 issues, saving you significant time and effort.
4. Miscalculating the Time and Effort Required to Get HANA-Ready
As anybody who works in finance will you tell you, businesses live and die by their budgets. Unfortunately, HANA-readiness projects are notoriously hard to budget for because every individual instance of incompatible ABAP code will take a different amount of time to fix – with myriad factors at play, including:
- The complexity of the issue
- The level of integration with other lines of code
- The skill of the programmer
Despite successfully identifying instances of problematic code, SAP Code Inspector can’t tell how much time effort is needed to fix the issues, and so most businesses tend to estimate, resulting in wildly inaccurate forecasts.
For example, most fixes take an hour or less. But across 20,000 issues, if each estimation is out by just 10 minutes, your forecast will be incorrect by over 100 working days.
5. Creating New HANA-Incompatible ABAP Code
Getting your code-base HANA-ready is a labour-intensive task but it could take even longer if you aren’t monitoring the new code being written to guarantee it’s free from incompatibility issues.
You can avoid this risk by teaching your developers SAP’s new best-practices for developing ABAP code for HANA or by testing regularly for HANA-incompatibility issues. One technique for ensuring all new code is HANA-ready is to check at the point where you release a development task for testing.
6. Hana-Readiness Project Becoming Unmanageable
With so many issues requiring a fix, it can be hard to keep track of your progress and HANA-readiness projects can quickly become sprawling and disparate messes. At any moment you may be left asking yourself:
- Which developer is working on which fixes?
- Is all new or adapted code HANA-compatible?
- How long it’ll take for my systems to be HANA-ready?
- Which issues are critical fixes and are they being prioritized?
- Which code items have been fixed, which are being worked on and which are unresolved?
Finding a project management tool to help handle the workload can be difficult. Spreadsheets are unwieldy and most traditional tools aren’t made for so many issues – so we developed Gekkobrain to manage SAP HANA migrations.
Gekkobrain helps identify issues of HANA-incompatible code, predicts the time needed for fixes and filters out redundant code to eliminate up to 90% of the effort required.
Still unsure about moving to SAP HANA? Book a demo and let us help you find out what it will take.