The Real Cost of Keeping an Old SAP System Alive

Why SAP Decommissioning Needs a Business Case, Not Just a Technical Plan

I’ve been working with SAP archiving and data management for a long time. One thing I keep seeing is that when we start talking about archiving or decommissioning, we usually start with the technical stuff.

How big is the database?

What are the biggest tables?

What archive objects can we use?

How much data is old?

How much has already been archived?

All of this is important. I look at the same things.

But eventually somebody is going to ask:

What are we going to save?

And sometimes we don't have a very good answer.

We have a technical plan, but we don't really have a business case.

We Spend a Lot of Time Looking at the Technical Side

When I start looking at an SAP system, I want to understand the data first.

I want to see the large tables, the growth, the years of data and what business areas are driving the size.

Then I start looking at the archive objects.

What can be archived using standard SAP?

What has already been archived?

What needs to stay?

What is custom?

What are we going to do with the Z tables?

You can spend a lot of time doing this analysis, and you should.

But at some point we have to take all of this technical information and turn it into something the business understands.

Keeping an Old SAP System Running Costs Money

This is something that I think gets overlooked.

Doing nothing isn't free.

If an old SAP system is still running, somebody has to support it.

There is infrastructure. Database support. Backups. Basis support. Security. Monitoring. Licensing in some cases.

And somebody still has to know how the old system works.

I've seen systems kept around mainly because somebody might need to look at an old document someday.

That may have made sense years ago.

But does it still make sense to keep an entire SAP environment running just so somebody can look up historical data?

Maybe it does.

Maybe it doesn't.

But we should at least know what it is costing us.

This Is Where the Business Case Comes In

This is something I'm working on more now.

We already have a lot of information from the technical analysis.

Database size.

Table sizes.

Archive objects.

Historical years.

Archived data.

Custom tables.

Retention requirements.

Why not use that information to start building the business case at the same time?

For example:

How much data could we potentially remove from the active system?

How much will it cost to archive, extract or preserve it?

What does the current environment cost every year?

What could be eliminated after decommissioning?

How long would the project take?

When would we start seeing savings?

These aren't always easy numbers to get.

And they're definitely not going to be exact during the first assessment.

That's okay.

I'd rather give the business a reasonable estimate than give them 50 pages of table analysis and no idea whether the project makes financial sense.

The Data Still Has Value

Another thing I think we're going to see more of is companies wanting to do something with their historical SAP data.

We're used to thinking about old data mainly from a retention and compliance standpoint.

We archive it because we have to keep it.

But there may be 10, 15 or 20 years of business history sitting there.

Purchasing.

Finance.

Sales.

Inventory.

Manufacturing.

Orders.

Customers.

Vendors.

That's a lot of information about how a company operated.

If we can preserve that information outside the original SAP system and still make it accessible, now we have more options.

Reporting is one.

Analytics is another.

And I think AI will eventually become part of this too.

Not AI just for the sake of saying we're using AI.

I'm talking about being able to ask questions against years of historical business information, identify patterns and possibly find things that would have been difficult to see before.

Decommissioning Shouldn't Start With Shutting Down SAP

For me, that's the biggest point.

A decommissioning project shouldn't start with:

How do we shut this system down?

It should start with:

What is actually in this system?

Then:

What do we need to keep?

Why do we need to keep it?

Where are we going to put it?

How will people access it?

What will this cost?

What will we save?

And can we still get some value out of the data?

Once you can answer those questions, then you have more than an SAP decommissioning plan.

You have a business case.

And I think that's the part we've been missing on a lot of these projects.