Before You Retire SAP: Know Your Data First

Before You Shut Down SAP: Decide What Happens to the Data

I have worked with SAP data archiving and data management for many years, and one thing I see with decommissioning projects is a lot of attention goes into shutting down the old system, but sometimes not enough attention goes into the data that is being left behind.

Before you shut down an SAP system, you need to decide what is going to happen to the data.

It sounds simple, but when an SAP system has been running for 10, 15 or 20 years, it isn't.

First, Know What You Have

I think this is where a decommissioning project should start.

Take a snapshot of the system and understand what is actually there.

How large is the database?

What are the largest tables?

What business areas are using the space?

How much of the data is old?

What has already been archived?

What archive objects are available for the remaining data?

You can't make a good decommissioning decision if you don't know what is in the system.

I like looking at this as creating a baseline. Once you have the snapshot, you have something you can analyze instead of guessing.

Not Everything Should Be Migrated

When moving from ECC to S/4HANA or another system, I don't think the answer should automatically be to move everything.

If you have 15 years of historical data, does all 15 years really need to be in the new production system?

Maybe some does.

Maybe some needs to remain available for audit or legal reasons but doesn't need to be migrated.

And some may have reached the end of its retention period and no longer needs to be kept.

Those are different situations and should be treated differently.

Archive, Migrate, Retain or Delete

This is where I think the real decommissioning strategy starts.

For each major area of data, determine what should happen to it.

Some data may need to be migrated because the business still actively uses it.

Some may need to be archived and preserved for historical access.

Some may need to be retained because of legal, tax or audit requirements.

And some data may be eligible for deletion once the proper retention requirements have been met.

The important thing is to make these decisions intentionally.

Keeping everything isn't really a strategy.

Neither is deleting everything just because the old system is being shut down.

Don't Forget the Documents

SAP data isn't only database tables.

There may be invoices, scanned documents and other attachments connected to SAP transactions.

Those documents may be stored somewhere completely different from the SAP database.

Before decommissioning, you need to know where those documents are and how they are linked back to the business data.

If somebody retrieves an old accounting document five years from now but can't retrieve the invoice that belongs to it, you haven't completely solved the historical access problem.

The Business Needs to Be Involved

Decommissioning shouldn't only be a Basis or technical project.

Finance needs to tell you what they need.

Purchasing may have different requirements.

Legal and compliance may have retention requirements.

The technical team can identify the data and provide the options, but the business needs to be involved in deciding what information still has value and what needs to remain available.

Test Before You Shut It Down

This sounds obvious, but I think it is one of the most important steps.

Before shutting down SAP, test the historical data.

Pick some old accounting documents.

Pick some purchase orders.

Check the related attachments.

Make sure somebody who didn't build the solution can actually find the information.

Don't wait until an auditor asks for a document three years later to find out something was missed.

Decommissioning Starts With the Data

For me, SAP decommissioning isn't really about turning off a server.

Turning off the server is the last step.

The work comes before that.

Understand the data.

Take the snapshot.

Analyze it.

Decide what to migrate, archive, retain or delete.

Make sure the documents are accounted for.

Then test that the information you decided to keep can actually be retrieved.

After all of that, you are in a much better position to shut down the old SAP system.

Before you ask, "When can we turn SAP off?" ask a more important question:

"Have we decided what happens to the data when we do?"