Sunsetting SAP data: What are your options?

February 24, 2022
Written by Paul Hammersley

As Senior Vice-President of the ALM Products at EPI-USE Labs, Paul Hammersley's portfolio includes test data management, landscape optimisation, and archiving. He has been a remarkable technical force in the SAP arena for over 20 years, and has extensive hands-on experience of implementing Data Sync Manager (DSM) and helping clients to manage data across the breadth of their SAP landscapes.

20220221_Archive_Central_-_blog_header_-_V1

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

20220218_Archive_Central_-_Graphic_6 (1)

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.

 

New call-to-action

 

 

Explore Popular Tags

Test Data Management SAP S/4HANA Data Sync Manager SAP S/4HANA Migrations SAP migration Archive Central Data Sync Manager (DSM) Object Sync SAP test data management DSM Data Secure News Transformation s/4HANA technology Brownfield SAP data Automation Client Sync Cloud Cloud Migration Decommissioning EPI-USE Labs ERP Insider Managed Services SAP Landscape SAP environment SAP systems data copy data scrambling data testing Data Archiving Digital tranformation Greenfield S/4 S/4 system landscape S4HANA SAP Cloud Deployment SAP RISE SAP S/4HANA Assessment SAP SuccessFactors SAP TDMS SAP data privacy & security SLO Sandbox Sunsetting legacy data Upgrade cloud hosting quality of test data sap testing ALM Accurate test data Agile Archive Cloud Solutions DSM solution Data Privacy Data Security DevOps Display only Governance, Risk Management and Compliance (GRC) Hybrid Lean secure SAP Legacy PRISM Production system Rise with SAP SAP Landscape Transformation SAP Road maps SAP SuccessFactors Employee Central Payroll SAP certified solution SAP client copy SAP data migration SAP data privacy and compliance SAP system copy SAP test system landscapes Selective Data Transition (SDT) Sunsetting System Analysis TDM Video Webinar cloud environment landscape transformation ABAP Acquisition BW, Big data and IA C/4HANA CRM experience Control Center Controller Copy and mask test data Croatia Croatian kuna to euro conversion Customized service DSM Readiness Assessment DSM for HCM DSM5 Data access Data agility Data footprint Data masking Data minimisation Data privacy compliance Data privacy regulations Data visibility Design Thinking EC ECATT EPI-USE Employee Central Europe Eurozone Event Flexible framework GDPR Hybrid SAP SuccessFactors environment Hybrid SAP and SuccessFactors Hybrid cloud Hyperscaler IDOCs IT Improved productivity and efficiency Infotype 41 Managed Refresh Services Migration OData API PCE PCE XXS PI PRISM free assessment Pilot Premium Support Services Production ERP Production data Reliable Releases S/4 Hana migrations S/4HANA Private Cloud Edition (PCE) S/4HANA version 1709 SAN SAP AppHaus Network SAP Archive Extractor technology SAP BW SAP Basis SAP HCM SAP HCM Data SAP HR SAP IS-U SAP cloud migrations SAP customers SAP data copying and masking SAP environments SAP experts on call SAP landscape design SAP on AWS SAP roadmap for IS-U SAP system refresh SAP system types SAP test systems SAP-certified SAPinsider Secure scrambled production data for testing Solman Solution Manager Success Story SuccessFactors System Landscape Optimization System conversion Tailored expertise User Experience XXS archiving big data analysis business goals content tables data model data tailored design develop divestiture incremental updates industry sectors masking rules mergers multiple clients new functionality predictive analysis production SAP database regression testing release strategy technical data reductio technical logging technical tables test test data masking
+ See More

Get Instant Updates


Leave a Comment: