Sunsetting SAP data: What are your options?

In this blog series, we’ll be looking at the end of the life cycle of data and, in some cases, systems. I’m aiming to impart experience and knowledge to help you plan a dignified and peaceful end for your SAP^® systems and data, rather than a more grizzly demise with blood on the server room floor and people in floods of tears (we’ve all been in projects like that at some point in our IT careers, hopefully minus the blood at least).

The top 5 reasons for systems becoming display-only

Why do you need to sunset systems or data?

Let’s start by looking at how the need to sunset systems, or data, arises. There are a few business events which can lead to a system becoming ‘display only’. This could be, for example, a system which was running a business that has been divested, and the entire system copied and handed over to the buyer. Financial and legislative requirements mean that the selling company still has to keep data for a number of years after the transaction.

Or it could be a business that has been acquired. Perhaps it was an SAP system or some other ERP system that is installed on-premise. In merging the business processes, it was decided to reimplement processes on the buying companies’ existing systems, but only the open items were taken across. All historical transactions ‒ which might be required for compliance or reference ‒ are kept in the ‘mothballed’ system.

It could even be as a result of leaving SAP for another technology. While many organisations are modernising their SAP investments, some will inevitably fall away and move to smaller industry-specific vendors. Or it could be organisations which are making the move to S/4HANA, but have decided to do so via a new implementation, rather than dragging their teenage, or older, SAP system through yet another upgrade.

All of these examples, and there may well be others, lead us to the same destination ‒ an SAP system, or several, which only has the purpose of allowing display access to the data for a much smaller number of users.

Accessing the data you need from SAP ERP

At first glance, it may seem ridiculous to keep an entire gold-standard ERP system up and running for a handful of users to display data only. But when you start to look at extracting the necessary data for compliance and future queries, you open a Pandora’s box on an extremely complicated and deep data model.

A typical SAP system has over 30,000 application data tables. One simple transaction code in SAP can touch 50, 60, 70 or more underlying tables, with the linkages between those tables not always straightforward. And in many cases, there are dependencies on other types of data. When I look at a Sales Order, am I looking at the delivery address of the Customer Master, or was there a specific bespoke address added for this one order? Both are possible.

When I view that Sales Order, I might need to integrate multiple line items which are in different tables. Each item may (or may not) reference Material Masters which are stored in a completely different set of data. And when investigating a query on the Sales Order, I might also need the preceding or subsequent documents; Delivery, Contract, Billing Document etc. So, unless the user is going to be happy opening a CSV file and looking for order 40231100 and then opening another CSV to check items 10, 20 and 30 in order to see Material 801-110 was sold to Customer A3000 at Address 34677, we are going to need something much more developed to enable access to the meaning of the data, not just the raw data.

And it goes much further. Across the application data tables there will be references to customising values. Will it be sufficient to see if this data relates to plant 3000, or do we need to know from a customising table what the description on that plant actually is? Or the data may contain fields which have domain value ranges assigned to them. The user might need to know what 01, 02 and 03 actually mean, not just the codes. The customising in SAP is an additional 50,000 tables, but which ones are used by our system? Which ones contain default data SAP ships that we don’t need?

Many organisations begin this journey of investigating how to just ‘download the data from SAP’ and see enough of the data model to realise the futility of the exercise and stop there. This is often influenced by a simplistic view of the costs of keeping the system running as display only, which underestimates the true cost going forward.

Maintaining display-only systems

The first step in turning a system to be display only is to limit authorisations to only display transactions. All interfaces will already have been moved to the transacting system, but it makes sense to also review the communications systems ‒ ALE, IDoc, email and so on ‒ to ensure messages cannot be sent out accidentally. Licence-wise, we don’t need SAP support on the system anymore, so it doesn’t matter if that has lapsed. Occasionally, we might need to restart the system for operating system patches so there might be a small skills’ requirement on SAP Basis knowledge for that.

Then there is the disk and compute costs, or hardware in old-school terms. If it is on-premise, then it’s likely the existing servers will be able to see out their days providing this display-only system. That doesn’t sound too bad, does it? Let’s stick with that, and everyone’s happy. The users can access the data the way they like, and we don’t need a tricky project trying to extract the data.

But now let’s jump forward two or three years in the life of this system and this has occurred:

• The key users who leveraged SAP have all left. The finance department users are now familiar with XXX solution for running the business and have no idea (or desire to learn) how to run an SAP GUI transaction code and interpret the archaic-looking screens (game of PONG anyone?). And the IT department has no idea how to get the SAP GUI onto their desktop machines.

• The IT director is pursuing a ‘cloud-only’ approach and the server room is being sold off as part of a real-estate transaction. Someone needs to get this system into Azure/AWS/GCP. Will the migration and management tools of that cloud platform work with this old operating system?

OR

• The data centre is now running entirely virtualised servers. We managed to migrate the server ‘as is’ to a virtual machine, but now the solution that manages all of the virtual machines is being upgraded and cannot support Windows 2012. We will have to upgrade the SAP host server. Ah, but the database version in use only goes up to Windows 2012, so we must upgrade the database. But then we need to patch the SAP system to work with newer operating system and database versions. Does anyone remember how to patch SAP? Hang on, we stopped paying maintenance so we can’t download the patches.

Suddenly, the path of least resistance a few years ago is like hitting a brick wall today.

Sunsetting part of a system

The eagle-eyed among you (and the dedicated, since you’ve got this far through the blog), will have noticed that at the start I interchanged ‘system’ and ‘data’ a lot but then focused on system sunsetting. This is the more common use case for sunsetting but, with the increased importance of data privacy of late, there can be situations where data should be sunset, even if the system will continue.

For example, an SAP system with HCM transitioning to SuccessFactors Employee Central. Will the historical employee data be removed from the system at a later date? Five years later, when an external provider is given access to a sandbox for a new project, will anyone consider that employee data is lying around unchanged for half a decade? I know my date of birth and social security number haven’t changed in the last five years. That data is as precious now as the day the business processes moved off the SAP system. But this can throw the same challenge ‒ we have to have historical pay information for those employees for compliance reasons. So, where could we put it where it’s accessible to the few who need it, in a secure, user-friendly system, such that we can remove it from a system that has been long since forgotten by the HR department?

This could equally apply to customer data that has transitioned to SAP Cloud for Customer but still resides in the on-premise SAP system as that transforms into the digital core.