Tips for decommissioning SAP (without EPI-USE Labs)

Change is in the air

The vast majority of my working life has been in and around SAP, and we’re currently seeing a monumental change in where people are hosting their SAP systems, with all but ‘very high security’ industries making the journey to the cloud. In many cases this is being seen as a watershed moment where organisations want to ditch the decades of history they have on legacy SAP systems and start fresh with S/4HANA in the cloud. 

I discovered recently that this isn’t limited to just the SAP world, and I have a theory. The late nineties through to the mid-noughties was an unprecedented period of IT transformation, starting with Y2K concerns and then embracing the internet for consumers and the universal use of EDI in the supply chain. Firms were forced to invest heavily in their IT systems, and have been squeezing every last drop out of them ever since. 

Taking roughly 20 years of history to the cloud doesn’t just cost you more, but either paints you into a corner in terms of enterprise structure, or creates a massive ETL component to the project. The end result….legacy systems of all shapes and sizes are abundant.

Why listen to me? 

I have been working with SAP for 20 years, and heavily involved in SAP data management in one form or another for the last 15+ years. I’ve worked on more decommissioning projects in the last two years than the previous 18 put together. 

In this blog, I walk you through a checklist I’ve put together on decommissioning SAP and give you some more background to each point. 

This is a generic guide to some of the challenges, giving free advice (let’s hope my boss isn’t reading this) for anyone on this path and keen to go it alone, or locked into an existing technology solution for the decommissioning. 

Also look out for my follow-on blog explaining for each tip/challenge how we (EPI-USE Labs) can simplify or even completely avoid the task.  

Enough malarkey… let's get to the tips

• The archive system won't look like SAP
• Not everything done in SAP today will be done in the archive system
• There will be compromise required

In the project, you will be dealing with a variety of people, ranging from IT consultants helping with technology, to internal IT teams, and a wide variety of business users – some of whom may be more IT savvy than others. They will also, for the most part, be distracted by the trials and tribulations of the new system implementation. This is particularly pertinent if you’re leaving SAP. I’ve never been divorced or had to break a hardcore narcotics addiction, but for collective pain, heartbreak and tears, I would imagine both follow a long way behind moving off SAP.  So expectation management is important.

 
The new system cannot look like SAP for a variety of reasons, but it's also important to point out that you might not want it to. Yes, the users currently have Stockholm Syndrome for the SAP GUI, but on the new system they will not be using SAP GUI. Even if the new system is S/4HANA, they will be using Fiori instead.

It’s also important to consistently message that any testing and validation should not be engaged into with the idea that you are signing off A as equivalent to B. This isn’t the system replacing SAP; this is just the system stopping you from having to run a ‘display only’ SAP system forever. Its usage will degrade almost from day 1, and may be completely unused for days or even weeks on end, but will have some compliance purpose. Having the data will be massively more important than how it is displayed. Knowing the data is definitely there is more important than how hard it is to search and retrieve, or how long the response times from any archive system may be. Don’t oversell the brilliance or usability of your solution, even if you feel it has both qualities at the start. You and your user base will undoubtedly be forced to compromise down the line. 

• You don't need ‘point in time backup’ options, or high availability

Whoever is provisioning the decommissioning system, they may not fully appreciate its use case, and will default to standard Backup and Disaster Recovery (DR) options. These typically come in a spectrum of options which align to the peril/cost of something terrible happening. The less disruptive you want that to be for the business, the more you will pay. ‘Point in time recovery’ is where a Backup can be restored, but then database logs reapplied to the database to bring it to exactly the moment before the bomb landed/hardware failed/user wrongly re-executed a 5 year old batch job/mouse chewed through the wire (delete as appropriate). 

The joy of decommissioned data is that it doesn’t change. Understand what could change in terms of user layout preferences, and then work accordingly to the backup strategy required. In all likelihood, a year into its usage a backup of the decommissioned system one week will be identical to the backup taken the next week. The required SLA time to be back online is also not likely to be in the normal realms for an IT system. We can probably live with an hour's outage. 

TLDR: this use case is off the spectrum at the low end; don’t let someone charge you for better backup and DR than you need.

• Focus on the use cases not the data in the system
• Preface the conversations with the fact that the current activities in SAP will not all be required when the system is decommissioned. 
  

Level 1 (Easy) - Finding 2x2 Lego blocks in a box of thousands of Lego bricks
Level 2 (Medium) - Looking for a needle in a haystack
↓
Level 9 (Ultra hard) - Identifying all the data needed from a SAP system

There are 70k+ client specific tables in a modern SAP system. Many will contain default data, but for an industry or business process completely unrelated to what your organisation does.

I would guess there will be around 3-5 thousand tables with data you actually need. Start with the use cases, and go and find the data needed to support them. ST05 traces are very useful for seeing where a particular transaction leads, but you can also use the F1 technical help; just beware of structures (data likely combined from several tables) as opposed to Transparent tables. Use the workshops to identify the use cases and document them for sign off. Ask the attendees to consider a month, a year and three years after SAP is switched off; what will people still be asking for? Keep challenging if a use case is something they do today; or something they will still need to do when that SAP system is not the productive system of record.

• Will they also be decommissioned?
• Is there data duplication? Which system should the data be taken from?

For most organisations running SAP, it is their main system of record for Finance, and the centre of their IT universe. Many things interface with it and act as ‘SAP to outside world’ interpreters. You may have other SAP technologies which are integrated with ERP, such as CRM and SRM. Make sure you have a list of peripheral systems ready for the workshops. The project replacing SAP should already have this list and know which ones are being switched off at the same time. Validate that any which are included in the ‘to be’ design will still have historical data from when they were linked to SAP, and then remove those from your list. For what remains, use the workshops to challenge whether any of the data in peripheral systems is actually needed. Is its key data replicated to SAP ERP, or the final versions of its data? For example, SRM sending Purchase Orders into ERP where the ones that didn’t process are not data anyone will need in the future. Where required data lives in two systems, look at the complexity of retrieval for each and pick the easier. 

• Documents might not be persisted in the database, or might be stored in a separate repository
• Can documents not persisted be created in the new technology?
• Those in a separate repository: do they come from another system, and is that system being decommissioned? 

It is important to explain and keep reminding people that the decommissioning will involve structured and unstructured data:

• structured being the table entries downloaded and stored in a different database; 
• unstructured being the PDFs, Word documents etc. that are either needed to be reproduced for a partner or held for compliance reasons, or possibly in order to allow the business users to definitively answer a query. Examples of this are payslips, invoice pdfs and specific finance reports that might be needed for auditors. 

Keep reminding the users that the decommissioning system will not have the logic of SAP built in. So anything which combines table records with logic to produce a well-defined output might have to be run for all combinations before the system is switched off. This may well include Z/Y reports specific to the system/company.

If the unstructured data is persisted in SAP, it can be stored in SAP Office or in a Content Server. Before investigating this for the unstructured data in scope, I would recommend first asking the question: where did the document come from or go to? In other words, is there some middleware it has been through which might also have a copy? What’s the future of that system? How accessible is it for end users? Is it easier to extract the documents from that system than from SAP?

If you do need to retrieve the documents from SAP will this be done programmatically or by screen automation such as Robotic Process Automation (RPA). If it’s in a content server, is it easier to take it directly from there, or from SAP?

• Structured data contains a lot of identifiers: 01 = Mrs, 02 = Miss, etc. Are these needed?
• Materials, Purchase Orders, Sales Orders and many others allow the user to enter texts. These are stored in clustered tables and cannot be read directly in the table.

Structured data was stored in SAP in a way that was most efficient for use in the system, and not the best format for you to detach it from the system and make it usable. One key example for consideration is the descriptions that are part of the configuration. The relational database management system enforces that a field in table A can only be one of the possible entries in table B, and the description of the values meaning can be stored once in table B, not multiple times in table A. 

Examples of this are titles like Mrs, Miss and Mr, or order types. In some cases, the user might instinctively know what the technical code means, but will they remember in three years’ time when they haven’t looked at the old SAP data for some time? Probably not. 

So it will be important in the workshops to determine which related config tables need to be stored so that the descriptions can be shown. You will then need to see whether the archive system chosen can store them in a simple way. Also consider whether you really need all SAP’s supported language versions, or only certain languages. 

Text seems such a basic thing when you view it through Notepad. But behind simple character strings lies a hidden world of complexity. Not least the ways in which text can make for a good target for compression to reduce volume, and so it isn’t always directly retrievable. In SAP there are two tables, STXH and STXL, which are linked to lots and lots of types of data. You can use transaction TAANA to see how many records there are for each text type. On most systems, it’s millions. The actual text is compressed in a cluster stored in STXL, and so you will need to use SAP function modules to access it. 

In the workshops, I would recommend finding out which ones are used and reducing that list to which ones are needed (not wanted, needed). The reason is that SAP didn’t have firm control over how its developers linked to these tables. Normally, there is a direct link with a key like a Vendor number or PO number, but there are some peculiar cases like one of the Production order texts which uses a key containing the Production order but prefaced by the client number in use. This is superfluous, because the Production orders and the text tables are client specific. I’m assuming it was either that developer’s first and last project with SAP, or they were so embarrassed by it later they never confessed until it was too late. The point being… I wouldn’t recommend trying to decluster all the STXH\L rows because you may not even be able to link them all to the business data they relate to. 

• Will someone just need the data, or will they also need the change history from the data?

Being the main system of record for many things, SAP keeps a record of changes as and when they happen. For the vast majority of areas, these won’t be needed in a decommissioned system. Employee data could be one that is needed; or for specific industries you might need changes to Recipes, Materials or Batches. Just like the texts, I wouldn’t recommend trying to take them all. Find out which areas are needed and then look again at whether a programmatic solution or a screen automation solution is best. For most areas the changes are in…another cluster (tables CDHDR and CDPOS) but for HR you should be looking in the PCL4 cluster.

• Include in the blueprint the process if something were to be missed. This may help dictate how much/little an area chooses to take. 
• Do this EARLY in the project, it helps everything!

Documentation is important in any project, but in this one there will be limited attention from the teams involved and a willingness to get agreement quickly to return to more immediately pressing matters.

 
Develop a blueprint of what is going to be decommissioned and how. Ask each area of the business to sign off on their parts. 

• The level of testing should be proportionate to the cost for temporarily bringing the system up again.

As I mentioned earlier, this project is unlikely to be the most pressing in anyone’s to-do list (except perhaps you, if you’re the project manager). Keep that in mind when requesting testing/validation from business users. Wait for several use cases to be ready for validation to ask for their time, rather than making many demands for small slots of time. 

In my mind there are some key questions to ask when considering how much testing is needed: 

• General question: how hard will it be to restore access to the system if something has been missed?
• Use case by use case: what’s the impact if data is missing? And for whom?

When we’ve decommissioned data as part of a divestiture, it's been a cliff edge in terms of systems access. In that situation, the testing/validation is critical, and the sign-off could be legally binding. If the data will still be retrievable but there is a cost/effort involved, then the testing should be proportionate to the cost. 

Apply to that result a co-efficient for the business area and specific data type. In most countries, there is a requirement to keep accounting documents for at least seven years, and failure to do so could in a very extreme case result in prison time for directors of the company. Hopefully an unlikely outcome in the case of an accidental omission due to project scope shortcomings. 

• Market your solution internally for other system decommissioning. 
• Regardless of what you're using, the cost ROI is better the more systems you can put in it.
• Plan for other systems joining later on in considering permissions, expected space/compute, etc.

Perhaps there are areas of the business unaffected by what’s happening to SAP. Do they have traditional on-premise or cloud hosted systems? Take ten minutes to brief their IT experts and business process owners on your project.

Wherever you’re taking your SAP data to, you will be far more cost-effective in the future if you have friends sharing the decommissioning system. Ask your technology vendor what limitations could occur if you wanted to decommission other systems later. Are there any licence restrictions? Is it better to plan for more compute and storage than you need for just the SAP data? Is there anything you should consider in your permissions for the SAP data to future-proof it for other users joining the system later on?

• Remove access to SAP and track any requests to access it again.

If possible, plan to have your SAP system still available during the stabilisation/ hyper-care period of the new system, and perhaps a little beyond that. The users have enough to deal with, so if they have to check something in the SAP data, let them do it in SAP. Then lock their SAP access and ask them to use the new decommissioning system.

BEWARE: don't let the users hang on to it (check out this blog about the hidden costs of display-only systems). This goes hand-in-hand with Tip 12. The duration of the phases will depend on how feasible/costly it is to restore SAP from a backup.

• Check your SAP licences – can you keep the system display only, even after maintenance has ended? 

Depending on your agreement with SAP, you may be able to keep your old system as display-only for as long as you wish. Even if you signed an updated contract (perhaps upon renewing SAP maintenance after a break), a technical user can always get into an old SAP system, even if the business users cannot. 

Document your ‘Please smash the glass to access’ plan for how someone can get data from SAP that was missed in the project. Ensure that includes swift access to the data for them, and the right notification and availability of skills for you to resurrect the project for one small (hopefully only one) encore to get that extra data set out and into the archive. 

There will come a point where you wish to take a backup and switch the system off completely. When exactly that should happen will depend on what would be the cost to get it back up. All this should be in this plan. 

• Include workshops with internal AND external auditors

This tip is slightly out of sequence, since the last few have been chronologically ordered with the end of your project. (Unless there is that point in the zombie movie where they unexpectedly come back at the very end. You know the one I mean). ‘24 fiscal periods later’ we could call this a movie. Each year there will be some sort of audit, and it will be likely to include your decommissioned data. There is no guarantee that the person, or even company, that does the audit one year will be the one that does it the next, so this area needs attention. 

Set up a workshop with internal and external auditors and explain the purpose of the project, and ask what they will need in the next x years. Include this in the blueprint and get them to sign off on it. Hopefully, the person signing off will at least work for the organisation responsible for the first time this audit will occur. Someone flagging other reports they want in year 2 will be easier to negotiate with if the previous audit went smoothly. Explain clearly the structured vs unstructured data, and that while we may have the table entries, we won’t have the ABAP logic. Find out what reports they want running, and make sure these are included in your RPA or programmatic approach to unstructured data.

Just kidding (sort of, but this is useful information). Watch out for false requirements like ‘reporting’. ‘Are there APIs to read the data from an external analysis tool?’ comes up a lot in discussion, but is very rarely an actual requirement someone is willing to pay for. The data becomes less and less useful for reporting with every day the system exists. That’s not to say this won’t be a firm requirement in your project but it's a good point to remember; other people may come up with perceived requirements, which in an ideal world would be good, but will be the first thing cut when the project costs need reviewing. Save everyone some time, and just challenge whether a requirement makes sense for historical, static data.

If you found this interesting, why not read my follow-on blog explaining how we can help you make this process much simpler?