Security initiatives can accelerate an S/4HANA migration

An S/4HANA migration may be a long, complicated, costly project, but soon, it will also be a necessary one.

As the 2027 deadline approaches when SAP will end support for legacy systems, SAP organizations should be looking for ways to reduce the cost and time it takes for a migration, including how to integrate security measures like vulnerability testing early in the migration process, according to Juan Pablo Perez-Etchegoyen, CTO at Onapsis, a Boston-based firm that provides cybersecurity services and products for SAP, Oracle and Salesforce systems.

"We found that not only does including security as part of the SAP Activate methodology not delay these projects," he said, referencing SAP's six-year-old project management methodology for implementation, "but it accelerates them, because you no longer have to inject the different security teams into the project to do the security validations and go back and forth prior to go-live."

In this Q&A, Perez-Etchegoyen discusses some of the reasons why S/4HANA projects are complex and how including security measures at the beginning can accelerate projects and reduce costs.

What are some issues that SAP customers need to consider first as they prepare for an S/4HANA migration?

Juan Pablo
Perez-Etchegoyen

Juan Pablo Perez-Etchegoyen: First, you have to consider the context of SAP applications, which are built on top of dozens of years of code and functionality going back to SAP R/3 and NetWeaver on the underlying framework. An S/4HANA migration resurfaces a lot of the technical details, technical concepts and technical components of that code history.

SAP customers don't typically deploy SAP as a standard solution; they heavily customize it. When SAP developed S/4HANA, one of those changes that it had was starting to [move away from] a lot of the older concepts, like getting rid of some tables and getting rid of SAP GUI and other UI technologies. When you have to move into S/4HANA, you'll have to migrate the transactions and code that work today but may potentially have problems in the new technology. You need to take this opportunity to adapt your business, get rid of old code and functions that have been accumulating over years and are not used or have limited use.

An S/4HANA migration is complex, time-consuming and can be expensive. What are some of the ways customers can mitigate this?

Perez-Etchegoyen: It takes significant planning, for sure. SAP has the SAP Activate methodology, which is designed to help customers transition from their legacy system to the new technology. Activate, which is not just for S/4HANA but can also be used for a cloud migration, gives you a framework that you can use to understand each step of the way -- planning, preparation, execution -- with very well-documented and detailed steps on how to transition.

You mentioned security can be an accelerator in an S/4HANA migration. How does including security benefit the project?

Perez-Etchegoyen: Security is really about understanding and managing risks. What happened historically is that security was appended into the project as an added-in component or just before go-live, they might have decided to do a penetration test of the application to get the green light. This means there were risks of a delay or you might go live with significant security risks. But when you include security at the beginning of the project, which is called the shift-left approach, you bring in security validation at the moment when code is created instead of at the moment when code is deployed or tested. This means you can prevent those risks from becoming a reality or prevent those risks from leaving the development environment so they don't materialize in production.

An S/4HANA migration to the cloud involves a lot of different components, and it could imply a lot of risks, especially if customers are not risk aware. Fixing a vulnerability when the system is in production is significantly more costly and more disruptive than fixing [a vulnerability] when the developer is actually working on it.

S/4HANA projects are designed to modernize and simplify the ERP system and get rid of customizations. Does this inherently make a system more secure because you have fewer vulnerabilities?

Perez-Etchegoyen: When you bring in new technologies, you expect them to be more secure from the get-go. However, new technologies also come with new risks because they are complex and involve new concepts, and you need to understand those new risks and concepts. For example, it's not the same when you expose an ECC user to an SAP GUI than when you open up an SAP Fiori HTTP server and expose users to Fiori applications. The components will be completely different, the authorization concepts are completely different, so these are concepts that organizations need to understand. But on the other side, getting rid of old code is always a good opportunity to get rid of problems. 

Who should be responsible for security in an S/4HANA migration project?

Perez-Etchegoyen: It's important to involve IT security teams as soon as possible because, typically, IT security teams will have the broader picture of the security controls that you have in your organization. They understand what the boundaries are, what the interfaces are, what the landscape looks like, what the infrastructure is and the security products being used. So bringing in IT security can help ensure that the security is aligned and you understand what security controls you need to implement specifically for SAP technologies. Because of the transformation and investment that's required, an S/4HANA migration typically has high support from the CIO or sometimes the CEO, and it's also important to get the CISO on board and [grant] visibility into these projects.

Jim O'Donnell is a TechTarget news writer who covers ERP and other enterprise applications for SearchSAP and SearchERP.