Unlocking Success – ASUG Members’ Recommendations for Custom Code Migration to SAP S/4HANA

Hi everyone, thank you so much for joining us today. I’m Marissa Gilbert, Research Director here at ASUG. Welcome to today’s webcast, Unlocking Success: ASUG members’ recommendations for custom code migration to SAP S/4HANA. Before we jump in, just a few reminders for you. Today’s webcast is being recorded and all registrants will receive an email with a link to the recording and the slides after the session today. If you have any questions during the webcast, please feel free to type in your questions using the Q&A box on your screen. As time permits, we will get to as many of those questions as possible during the session today or we can answer them while we’re talking if they’re in the moment. And of course, please take our survey about your experience at the end of the webcast. In the event you cannot remain on, the survey will also be included in that post-event email. I am thrilled to be joined today by Arndt Hoffmann, Chief Customer Officer at smartShift. Welcome, Arndt. How are you?

Introduction by Arndt Hoffmann

Hello Marissa. Good to be back here on our little series of webinars. Yeah, so great to see you. Do you mind, in case we have some new folks that join us for webcast #2, can you share a little bit about you and a little bit about smartShift before we dig into custom code?

Absolutely. I’m Chief Customer Officer of smartShift, part of the team since we started in 2002 and had multiple roles since smartShift. I’ve been in the SAP space since 1995, so pretty much close to my 30th year in the SAP ecosystem. Well, as I said, we started in 2002 and since then we are focusing on helping customers to transform and modernize their SAP systems with one specific focus. This focus is custom coding, custom applications, and how to transform and modernize them. We are doing that in a very specific way. smartShift always thinks of utilizing automation to actually do this heavy lifting and this job of transforming custom applications, and we are doing this, as I said, with automation and patented automation.

We have been in the market for a very long time and have done more than 3,500 projects in this space. Recently, we’ve mostly been doing S/4HANA transformations, helping customers adapt their customizations to S/4 standards, modernizing them, and helping them bring them to new clean core standards. That’s what we are doing day in and day out, and we are doing this research now for the second year with you guys. Our interest in this research is to better understand how our customers are taking in this space, what they actually need, what works well for them and what not, and how they think about new trends like Clean Core. That is why we are doing this great work here together and we are getting these good results to better understand our customers.

Key Insights from the Research Study

Thanks Arndt, you are absolutely the expert today. So excited to have you here as we share some of the research findings of our collaborative research together, but Arndt is really going to bring that deep expertise and understanding to some of our findings and experiences from ASUG members.

As Arndt mentioned, this is our second year of research to evaluate how SAP customers experience custom code migrations and SAP S/4HANA adoption at their organization. This year’s research was fielded in January and February. We had 174 ASUG members participate in this survey. Let’s give you a quick overview of the highlights. As we’ve mentioned, we’ve already had a session in May. We have one last session coming up in June. We’ll share those QR codes at the very end. If you missed either of those or are looking forward to the final one, you can register for that.

Here are the overall research highlights from the project that we conducted. Custom code is a business necessity for almost all SAP customers with reliance and challenges increasing when migrating custom code to S/4HANA. Balancing clean core ideals with business realities is a top priority. We’re going to get into clean core in that last webcast that we have coming up. Future movers to SAP S/4HANA plan to use automation but underestimate code migration challenges. We’ll talk a little bit about that today, but really what we’re going to dive into today is the key to optimizing custom code migrations: taking the time to bridge knowledge gaps, focus on change management, and work with the right people.

Let’s set the stage here so everyone knows where they are on their S/4 journeys. 42% of ASUG members are fully or partially migrated to SAP S/4HANA, though 57% will be moving within the next seven months to more than two years from now. The top challenge experienced as part of that move to S/4 is too many customizations within old instances. While custom code imposes a lot of challenges, 95% of organizations surveyed build and run custom ABAP code to extend SAP software applications.

That percentage is not on the slide, but just also came from our research and demonstrates that SAP customers just can’t walk away from their custom code. It really is central to supporting the business. Custom code is not a nice-to-have; it’s an essential part of making a system work for their organization.

Strategies for Migrating Custom Code to S/4HANA

Let’s dive into some of the new information and data that we have here for you all today. We wanted to better understand organizations’ strategies for migrating their custom code to SAP S/4HANA. We discovered some uncertainties regarding those strategies, with an equal split between those belonging to organizations with strategies (38%) and those who are unsure or unaware (40%). But 16% of organizations are working on their strategy and 6% do not have a strategy at all.

To me, it looks like maybe organizations struggle with building a strategy for their custom code. Why is it so challenging and why is it necessary to have a strategy?

Well, maybe let’s start with the second part of the question. Why is a strategy necessary? When you look at these transformation projects, there are a couple of key areas. You need to always think about your business processes and data. As we have seen from the research, custom code and custom processes are always an area of concern and something which is on your critical path. If you don’t look into that in detail and you don’t master it, you might be in trouble during the actual transformation. Therefore, there’s definitely a necessity to build a detailed plan but also a comprehensive plan.

Obviously, there are a couple of basic questions you should ask. How many customizations do I have? Are they used or are they not used in my system? What is the change impact moving with them to S/4HANA? What are the simplification items which apply to me? But there’s also more stuff around this whole area. For example, I would like to understand how much technical debt I have accumulated over the years with my customizations. How would I handle dual maintenance during the project? Can I freeze on my ECC system? What do I think about a clean core? How do I build a long-term strategy towards a clean core?

This whole area is pretty complicated, and building a detailed and especially comprehensive plan is not that easy. The problem is usually our customers are doing this for the first or second time, so they are not that experienced. Usually, you go to your partner of choice, your system integrator of choice, and ask what you would do here. The typical answer is, ‘Let me run some SAP standard tools and then I will bring a pass offshore about developers and they will fix it.’ And I think that’s not the right answer. You need to build a strategy which is super detailed and needs to understand all these facets, how to handle dual maintenance, how to build a long-term strategy towards clean core and then implement that. I know this is a company which has been doing this for 20 years. We have comprehensive answers around that. So my advice would be to talk to the experts when it comes to building this strategy.

We did follow up with the respondents who selected that 38% that have a detailed strategy and we wanted to better understand the key elements of their strategy. It really is about thoroughly reviewing their custom code to be removed or standardized before migrations. You mentioned that optimizing tools, SAP or SIS, you mentioned that one and internal training and upskilling as well. I think that’s an important one that we see as being as critical across the board when it comes to all types of projects. But certainly in this area too.

Is there anything missing from this list that you haven’t already touched on? Arndt, that you think that organizations should prioritize their strategies?

Yeah, as I said, maybe let’s mention two areas. I already talked a little about this whole dual maintenance strategy for their projects. What I mean with that is during your S/4HANA transformation, at a certain point of time, you build your new S/4HANA landscape. You implement your new S/4HANA development system. Starting with this point of time, everything which goes on in your ECC system needs to be retrofitted or dual maintained into the S/4HANA landscape. The only alternative is imposing a system freeze on ECC and I can promise you your business is not going to like it. You are doing an S/4HANA transformation which is not the most exciting project in the world. And then on top, you ask them for assistance. Therefore, definitely look at what are the requirements, how much change do you still have in ECC, how much change do you want to allow, and then how to build a strategy around that. I would also recommend building a strategy around that which is supported by automation, which helps to automate this process in a big way.

The second part is definitely this whole idea about clean core. We will have another webinar based on that, but this whole custom code strategy is not only about how I can take my code and make it somehow work on S/4, but there are important customizations which I want to retain and maintain also in the future. How do I take them? How do I clean up the technical debt which I have accumulated in these codes over the years? How do I address security issues, performance issues? How do I make them cloud-ready? And how do I plan to bring them to these new clean core standards? That should be a big part of this plan and it will also help you to communicate that to your IT leadership to have a valid plan to make the system better maintainable and upgradable in the future.

Participants of our survey did know that we were collaborating with smartShift and one of the participants mentioned leveraging smartShift. They’re not even going to bother with their strategy. They’re just relying on you. Other mentions include plans to review all custom code and remove any unused core prior to migrating, and for used code, follow SAP recommendations. It’s similar to what we’ve been talking about but definitely leveraging smartShift is a very smart idea.

Let’s get a little bit more advice. These are from ASUG members who’ve migrated or will be migrating their custom code to S/4. They were eager to share their recommendations to make everyone’s path easier moving forward. Universally, the amount of time it takes to communicate the necessity of reducing custom code, reviewing and documenting all processes, engaging with the right people, and accurately defining the scope to organizations were highly stressed as sort of tips and tricks to make the process easier.

Recommendations for Successful Migration

The top piece of advice from ASUG members is to push your organization to reduce custom code and to stick to standard wherever possible. Continue to push the organization to standardize and be flexible to change the internal processes if needed to develop the product with little or no customization. Configure the system in such a way that standard reporting provides the data needed for reporting, eliminating the need for custom reports. It’s really about reducing the customizations wherever possible. Is this easy or difficult for organizations to tackle? Sometimes you read these and think it can’t be that hard. What are some of the challenges that come up for organizations?

If it was that easy, everyone would do it. The typical SAP systems we find in the market are 10-20 years old. They have 2.7 million lines of custom code built. These systems are highly customized. We understand that not all custom code is needed, but some portions are essential for our customers. There’s industry-specific functionality not covered by SAP standard and stuff which helps to build some competitive advantage. Therefore, the idea of going back to standard and reducing custom code is good, but the idea of having a system without custom code is not going to happen. So, I would propose a more pragmatic approach. Take some of the technical information of the system on usage. Identify which objects are used. Take these objects out of the system and see how you can modernize them so that they don’t impose this pain you have right now with your customizations. A lot of this pain comes from the way they have been implemented at a certain point of time. With the clean core and the opportunities SAP is giving us with the new extensibility models, there’s ways of addressing these pains to make your system upgradable even with a lot of customizations.

Review and Analyze Custom Code

The second piece of advice from ASUG members is to take time to review your custom code, analyze, document all processes, and ensure accurate testing before migrating. Begin by understanding the business processes that will be affected by the migration. Identify critical business functions and prioritize them to minimize disruption. Make absolutely sure you need the code when moving forward. Migrating old code to S/4 is a rather large challenge. If you migrate unneeded code, you’re increasing your footprint for no reason, and that’s a lot of wasted effort.

To make this process go more smoothly, I recommend not trying to boil the ocean. I’ve seen many projects start as Greenfield projects with big consulting teams doing fit-gap workshops all day and night. Sometimes, this phase of the design phase was actually a year or longer, producing hundreds of pages of PowerPoint. In the end, finding out that still a lot of old processes which were implemented over time and utilizing customizations were better than what is found in the standard. So, don’t make it a science project. Think of smarter ways of doing certain things. You can make your life much easier with automation. With automation, you have the opportunity to enhance the quality of your transformation and also reduce the pain you create in these projects. This will reduce test efforts, test involvement, business involvement, and stuff like that. So, it’s not always the best use of time to try to figure out every final detail but sometimes it’s better to be a little bit more agile. Just transform a system, get to a system, and then figure certain things out on a real prototype.

Plan Early and Have a Strategy

The third piece of advice is to plan early and have a strategy. Give yourself a long runway and don’t underestimate the scope of the project. Time is always of the essence. Is planning early a luxury for some organizations or are they going to lose out if they don’t start now, especially as the 2027 deadline approaches?

Definitely, when you look at the consulting market, it is going to be critical to start sooner rather than later. We’ve talked about the essence of having a good plan. There are certain things you should start preparing because they are prerequisites for your S/4HANA transformation, like in the finance and controlling area, customer-vendor integration, and stuff like that. For custom code, I often get the question: should I prepare and do certain things beforehand? If you have the time to do that, let’s do it, but be aware that this also creates an additional project and testing effort in your organization. My recommendation is to be pragmatic, utilize automation, and embed it as much as possible into your actual S/4HANA transformation. Combine the S/4HANA transformation with getting unused custom code out of your system. Utilize the same test event. Utilize automation to automate the dual maintenance so that you don’t have a system freeze. That combines everything in one project and one test event, and you don’t utilize your business for two or three projects upfront.

Work with the Right People

The last piece of advice, and maybe the most important, is to work with the right people. smartShift received an unaided mention in this response question. Why smartShift? Why are you the right people to work with?

The difference working with smartShift is our approach is automation-centric. We don’t limit ourselves with manual labor and what is available from a resource perspective. Everything we do is automation-centric, which can have an impact on your transformation. There are certain things you can’t do manually, we will do with automation. But we also know our limits. smartShift will utilize automation to do the heavy technical lifting in these projects but also leave time and effort for our customers in areas where you need a brain and you need to understand functionality. It’s not that we come in, press the magic button, and all problems are solved. We know our limits. We take a big chunk out of these projects utilizing automation and leave the space for you as a customer to address innovation, new features, and new functionality.

It is also important that SAP customers utilize these projects to upskill their own people. We might come in and solve a big problem, but later on, systems need to be maintained. Therefore, your developers and internal teams need to be upskilled to understand the new available technologies and the new clean core extensibility concepts. So, they start from day one, once you’re on your S/4HANA system, implementing in a different way and not adding additional technical debt to the system.

Questions and Answers

If you want to learn more, we will follow this up in the post-event email. We have a couple of questions, so Arndt, this is going to be a speed round. Can you expand on what you mean by using automation for migration? Possibly provide some specific examples.

When I talk about automation for migration, I’m always talking about custom code migration and modernization. We can help you address HANA and S/4HANA compatibility issues in the code, fix performance problems, security problems, bring the code to the latest standards, naming conventions, and stuff like that. Do that highly automated and in a super-fast time frame, three to five weeks for any given system in the world, and at a super high quality with pretty much zero error in the transformation.

What’s the definition for custom code? Any customer-developed programs with ABAP on the ABAP platform even leveraging SAP-provided standard enhancement options to implement bells and whistles for customer-specific scenarios or real implicit modifications to SAP’s core using SAP access keys which change the way it was originally designed to work?

Our definition of custom code is super comprehensive. It’s not only the ABAP report here or there, but it is everything which has ABAP in it. Also, all these old-style user exits you’ll find, forms, scripts, and stuff like that. That is the scope we take into our projects. The only thing we don’t do is stuff where you really need to write new code because SAP has deprecated certain functionality in foreign trade and you need to re-implement the process.