It’s no exaggeration to say the most time-consuming aspect of getting your systems HANA-ready is fixing any incompatible ABAP code – but how long does it take to adapt your custom code for SAP HANA? Gekkobrain’s software eliminates around 90% of the manual work, so if you had to venture into this yourself, it would be very time consuming to say the least. The projects we have completed range from anywhere from 3 weeks to 3 calendar months, so without out algorithm and automation, it would have been up to 10 times that!

Why fix ABAP for HANA?

The launch of SAP HANA in 2010 represented a paradigm shift in data storage and management. Instead of making calculations at the application-level, HANA performs those processes in the database to provide new levels of speed, power and analytic functionality.

Unsurprisingly, this new approach necessitates some changes to the way systems are programmed. For any organization that seeks the highest level of performance from SAP HANA, this presents a stumbling-block because many existing code bases are littered with instances of custom ABAP code incompatible with HANA.

Get a fixed price quote for a complete HANA DB migration

In a live environment, some instances will result in impaired performance, but other, more serious HANA-incompatible code could trigger critical system failures. Adapting this code to interact more healthily with HANA alleviates the issue but how long will it take to clean up your entire code base?

How Long Does it Take to Identify Incompatible ABAP Code?

When adopting SAP HANA, you’ll need to prepare for the fundamental characteristics of your database to change, and before go-live, you’ll need to perform a thorough check of your custom code to identify:

• 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

Trawling through your entire code base to find every scrap of incompatible custom ABAP code can feel like an overwhelming task – and we’re not going to lie, it’s a time-intensive job.

Obviously, the time it takes to comb through your systems will ultimately depend on both how large your code base is and how much custom code you’ve written. In fact it’s not a task of finding issues that’s complicated, because SAP Code Inspector will do that for you. The real magic lies in finding the right issues to fix. so you don’t end up fixing unnecessary code requiring unnecessary testing.

GEKKOBRAIN TIP

Turning on Usage Procedure Logging (UPL) in your productive environment can identify code that isn’t actually used by your systems and can therefore be marked as decomissioning candidate. This can result in a large reduction to the length and cost of your HANA-readiness project.

How Much Effort is Required to Adjust Incompatible ABAP Code?

Without the right tools, this is a daunting task. Almost every HANA-readiness project we’ve been a part of has required fixes for tens of thousands of incompatible code instances. Without the right software and approach, it’s a case of months, or even years, rather than weeks. Add unnecessary internal testing resources to this, and you get the picture.

The first thing we do, when we take on a new customer, is to run a HANA readiness analysis, which results in a report telling us exactly how much code can be fixed automatically and how much manual work resides. As we also filter away unused code or code with little or no impact, we also save our customers a lot of resource for testing.

How Much Time is Needed to Manage a HANA-Readiness Project, If You Do it it Yourself?

Staying on top of your HANA-readiness project can feel like a full-time job in itself. Just keeping track of which code items have been fixed, which are currently being worked on, and which are still unresolved isn’t easy when there are tens of thousands of issues of varying complexity and importance that need to be evaluated or fixed. And some will be false positives, so that should be vetted out too, so you don’t have to test code that didn’t have to be changed.

In addition to this, you’ll need to find time to prioritize critical bugs, assign tasks to your HANA-readiness team, keep an eye on how far through sprints they are and ensure all fixes comply with best-practice.

And unless you want to pile extra work onto everyone’s plate, you’ll need to find a way of monitoring any new code that’s written during the process to guarantee it’s free from incompatibility issues.

Migrating to HANA is tricky enough without creating extra work through poor project management, so ensuring plenty of time is allocated for someone to supervise your HANA-readiness is vital – but obviously, the right amount will vary for every project.

What Difference Does Gekkobrain make?

Since we filter away everything that doesn’t have an impact, all false positives and unnused code, and then fix on average 95% of the rest, we cut the project down by more than 90%. On top of this, we cut down the amount of programs, you need to test internally afterwards with more than 80% om average (some issues are in the same programs). So, using a tool like Gekkobrain can help reduce the pressure by cutting down the workload and automating the most time-intensive tasks. And if you work with us or our partners, we actually give you a fixed price quotation for migration, and we handle the entire project for you.

Click here to find out more about how Gekkobrain makes it easy to gain the insights needed for more informed discussions about your HANA-readiness project.

If you want a proposal from us for taking care of the entire HANA DB migration with fixed price and time, please feel free to contact us.