7 Pitfalls to Avoid in Your S/4 HANA Upgrade

by Rick Kromkamp

So, you took the plunge a couple of years ago, and migrated to or implemented S/4 HANA, and you’re now thinking about an upgrade. Maybe you’ve got financial consolidations in group reporting on the horizon, or you’d like to take advantage of predictive MRP, or one of the other countless enhancements that SAP has rolled out in recent years. Or maybe it’s been a few years, and you just want to get current on support packs and security updates.

Regardless of your motivation for upgrading, before diving in here are a few things that you want to consider:


A dual landscape is always recommended if you can afford it. Sure, the costs are a little higher, but the impact to the business is minimized as the development freeze time is reduced. Having a dual landscape minimizes risks to your existing production landscape, should anything go wrong during the upgrade in your non-production environments. It also provides greater flexibility in your landscape, should you wish to make system changes going forward.


(!!!Danger, Will Robinson!!!): If you are not aware that SAP no longer prevents customers from modifying their standard objects by requiring an access key, then you’ve probably made changes to standard SAP, and there’s probably a good chance that you have at least a few instances of changes being made directly to these objects, without the use of an SAP approved user exit, BADI or enhancement point. If that’s the case, then you’ve got some work to do before you start upgrading. All of these objects need to be updated, or you will lose your changes. Further to this, either before, or after your upgrade, you probably want to look at your authorization concept and lock these objects down.


Use the latest version of SUM, which is 2.0. Traditionally, we have always used SUM 1.0 for ECC upgrades, but nowadays, in the world of S/4 HANA, it’s SUM 2.0 all the way. SUM 2.0 has been the standard for SAP upgrades for single stack systems since NetWeaver release 7.5. Also related, no matter how many SAP upgrades you have done over the years, take the time to read the latest SAP implementation guide for SUM. SAP has a few new steps when upgrading S/4 HANA, and you don’t want to miss those.


During every S/4 Migration, SAP will generate the same list of custom code objects that need to be analyzed. To prevent the same objects from showing up during the next upgrade, use the pseudo-comments that SAP recommends for code issues that the tool provides, where changes are not actually needed. In a recent upgrade, SAP provided hundreds of potential issues, for which only 10% needed any change. The other 90% required a quick pseudo-comment, to prevent the issue from being raised again in future.


Make sure that all your app servers are completely shut down prior to starting your upgrade downtime phase. Do not count on SUM to take care of this step for you. This may go without saying for some, but it is something that clients often get stuck on during the production upgrade, as many clients only have app servers in production.


Pay VERY close attention to passively deleted objects. SAP can, and will, remove objects that you need in production if you are not careful. During a recent upgrade, a client had implemented numerous changes to objects in a custom namespace without a repair license specified, or in another scenario, had custom packages without a software component specified. In both scenarios, the SUM tool looked at these objects as being standard SAP, and since they didn’t belong in the new release, they were passively deleted. Go through any of your custom namespaces and development classes prior to your upgrade . Regardless, treat the passively deleted object list with extreme caution.


Again, this may be old hat to some, but be prepared for issues post-go-live. We typically treat the first two weeks after go-live as an extension of UAT, keeping the project team on standby, and maintaining an issue tracker to log any issues that are raised. No matter how good your user acceptance testing phase is, you will uncover new issues in production, and you will want your team on high alert to resolve any issues immediately.

Every SAP upgrade is different and comes with different challenges. Having been through countless upgrades over the years, I can firmly say that no two upgrades are ever the same. That said, if you focus on the lessons learned above, you will be better prepared for the task ahead.

About the author: Rick Kromkamp

Rick is a Business Intelligence evangelist and practitioner in the art of data modelling.