Getting your systems HANA-ready can seem like a unsurmountable task, with most organizations needing to identify and amend thousands upon thousands of problematic lines of code – but follow these tips and it’s much less of an odyssey.
The release of S/4HANA gave SAP customers a clear pathway to their digital transformation goals, but to deliver the expanded functionality, S/4HANA needs to be operating on top of the SAP HANA database.
S/4HANA’s reliance on new architecture and data models renders some instances of custom code incompatible, further complicating an already lengthy database migration. The only solution includes combing your entire database to identify lines of problematic code and manually adapting them for S/4HANA.
Unsurprisingly, the prospect of an extensive database migration project intimidates many organizations, but there’s no need to delay your S/4HANA migration any longer! Here are 5 tips to help prepare your custom code and migrate to S/4HANA quicker:
1. Purge Unneeded Code
Unsurprisingly, cross-referencing 400+ S/4HANA simplification items against every line of code in your database results in a long list of issues that require adapting before they can function effectively in S/4HANA.
But not every line of code in your systems needs to be migrated to S/4HANA, just the parts you actually use.
By turning on the Usage Procedure Logging (UPL) feature, you’ll track the use of any development objects in your productive systems and find any disposable lines of code – which obviously don’t need to be fixed.
Simply eliminating the expendable code in advance of your migration can save you significant time and money, without negatively affecting performance. In fact, cleaning up your database this way will increase your systems’ efficiency.
2. Project Management is Like the Harry Potter Prophecy, You Need a “Chosen One”!
Keeping track of your HANA-readiness project can be tricky, especially when a team is working through potentially hundreds of thousands of incompatible code instances.
Choosing one magical individual to be in control of assigning tasks and monitoring progress is a great way to approach project management, especially in the absence of any effective tool from SAP.
Selecting a “chosen one” might seem counter-productive when you have a whole team of people you trust to manage themselves. However, choosing just one person to oversee the project is the best way to ensure jobs aren’t duplicated and don’t fall through the cracks.
3. Stop Producing Problematic Code
There’s nothing quite like the crushing disappointment of gearing up to celebrate the conclusion of your HANA-readiness project, only to discover your team has created a litany of new incompatible code.
If you only take away one thing from this, it should be that your efforts to prepare your database for S/4HANA migration will be for naught if your programmers don’t also adapt the way they write new code.
Migrating to S/4HANA is tricky enough without creating more work for yourselves, so ensure all your programmers understand and adopt best-practices for writing code for HANA.
4. Look Outside of the SAP Stack
SAP have unquestionably developed great tools to identify S/4HANA-incompatible code but there’s still plenty SAP’s tools can’t do. Much of it is vital to effectively planning and managing your HANA-readiness project, including:
- Estimating the time needed to adapt all incompatible code
- Helping you forecast the resources needed
- Reducing the size of the project by eliminating obsolete code
- Assigning project tasks to your team
- Recognizing and notifying you when incompatible code is created
- Monitoring yourr progress
For tools to help you do any of the above, you need to look outside the SAP stack. When we were managing our S/4HANA migration, we discovered we needed lots more functionality and developed a new solution – Gekkobrain.
We created our tool principally to quickly and accurately estimate the time needed for fixes, but we soon discovered we needed more control and added extra functionality, including the ability to assign tasks and perform progress scans.
5. Don’t Run the Software Update Manager Until You’re Ready
Every S/4HANA migration is unique. Each organization starts with a different system configuration and has different goals – so there is no one right way to go through the process.
The final step however, will always be running the System Update Manager (SUM), which updates your system with the S/4HANA software, migrates your database to HANA and converts your data to the new S/4HANA data structure.
What’s great is the SUM does all of this without you needing to do anything, unless it identifies an instance of incompatible code. If this happens, the SUM halts the conversion until the code is adapted for HANA.
This is a huge incentive to be HANA-ready when you run the SUM, so you can essentially automate the process. Using a tool like Gekkobrain not only provides a list of code items that need to be adapted for HANA but also an estimate of how long the fixes will take.
Following these 5 tips could help turn your organization’s quest to get S/HANA-ready into a much less time-consuming journey. Using Gekkobrain to help you migrate can also result in significant savings and to find out just how much money you could save, book a free appointment today.