The initial situation
When starting your migration to S/4HANA, your initial checks will get you the list of applications which are not compatible with S/4HANA. Some of them have new releases compatible with S/4HANA, others don’t.
The challenge
One of the technical issues is that, even for SAP certified third-party solutions, uninstalling a third-party solution was not possible up to about 3 years ago, as it had been never a requirement of SAP. More recently, uninstalling became possible by using OSS notes such as 1883223 as a template for partners and 2011192 for SAP delivered add-ons. New add-ons should be uninstallable as a prerequisite for being SAP certified.
Depending on the software vendor, you may be provided with deinstallation packages as part of the maintenance, and this may require a valid maintenance contract. Another option could be to purchase the S/4HANA compatible release and install it this later, and then you will have the option to remove the old code.
You may also do it yourself, by manually creating transports with delete objects but this is not recommended and may not even work for all objects. The difficulty of implementation, uncertainty over efficiency, and poor results of this method are some of the reasons why SAP implemented a deinstallation functionality into SAINT for third-party add-ons.
When third-party solutions have been adapted to your needs, this may become more complex because the vendor may not know of all objects or may have to create a custom deinstallation package.
All in all, in the end, customers will end up paying for this: new product, renewed contract, deinstall assistance or internal team time. The truth is that additional costs are due to the fact that removing third-party code was never expected to be necessary.
And there is a good reason for this.
The reason is that software may be audited. It may be for internal, external, tax, legal, or data privacy reasons. To pick one as an example, auditing data generated with software without having the code used to create is not feasible. While auditors are not obliged to audit the code, they could request to see it too in case they found it necessary to validate the data.
At TJC, we generate tax data: FEC, SAF-T, SII and special tax authority & auditors requests. When upgrading, SAP keeps trace of code evolutions in ABAP by the change and transport management systems. This allows a clear and seamless record of which code was present in the system at any given time.
The risk
But moving to S/4HANA is different: the code is lost and only available in ECC versions. And this was not planned. When the ECC system is removed from the landscape, the code is no longer available, but the tax files that were generated still exist. As the code is no longer available to demonstrate how the original data tax package was created, the files are no longer accepted in most countries as they become untrustworthy.
This may end up in a very uncomfortable situation for your company, it can become costly in terms of fines, penalties, and brand reputation. Bear in mind that this also applies if code was generated using SAP standard software. Once the system is gone, the code is no longer available and so the same logic applies.
The solution
So, yes, uninstalling third-party software comes at a price and may put the company at risk. The same is true for custom code. A safe approach is to include system decommissioning in your move to S/4 HANA. If you haven’t plan for it, it makes sense from a risk management point of view to seek assistance when removing third-party tools.
If have questions about the subject, just get in touch with us.
Because your data matters.
Thierry JULIEN, CEO and Founder of TJC Group
See the other CEO corner’s article.
