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?
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.
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.
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 be deleted. 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?
There's no hiding the fact that this is an involved task. Almost every HANA-readiness project we've been a part of has required fixes for tens of thousands of incompatible code instances. Usually, it's a case of months, or even years, rather than weeks.
Unfortunately, it’s impossible to say exactly how much time any individual instance of incompatible ABAP code will take 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
In our experience, the majority of issues take an hour or less to fix, but when you’re trying to plan a HANA-readiness project containing tens of thousands of issues, loose estimations will result in widely inaccurate forecasts.
For example, if you have 20,000 issues to fix but the estimation for each issue is out by just 15 minutes, it will result in your forecast being incorrect by over 150 working days.
The only way to gain an accurate estimation of how long it'll take to fix your custom code and get HANA-ready is to go through and assess each issue individually – a time-consuming but ultimately worthwhile process to better plan the project.
How Much Time is Needed to Manage a HANA-Readiness Project?
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 that need to be adapted.
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 to guarantee it's free from incompatibility issues.
Migrating to S/4HANA 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.
Any HANA-readiness project is extremely time-consuming and each one will take a different length of time – making it difficult to stick to pre-agreed budgets. However, using a tool like Gekkobrain can help reduce the pressure by automating some time-intensive tasks.
Although you’ll still need to manually adapt any incompatible custom code, Gekkobrain provides a clear list of code items that need fixing and an estimate of how long it’ll take, as well as giving you the tools needed to effectively and efficiently manage the project.
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 or click below to learn more about cleaning up your ABAP code for SAP HANA.