ISACA Now Blog

Knowledge & Insights > ISACA Now > Posts > How to handle legacy data in an SAP environment

How to handle legacy data in an SAP environment

| Posted at 1:43 PM by ISACA News | Category: Privacy | Permalink | Email this Post | Comments (0)

James BairdMany companies have older legacy SAP systems for audit compliance, review and reporting purposes. We know that as data ages it become less valuable, and this is especially true for legacy data. However, businesses need to retain data until it reaches its end-of-life for legal holds, in support of governance/audit requirements, or for maintenance histories.

Holding onto everything is not only expensive and inefficient, but can also run contrary to compliance guidelines. For data that still has value for business and/or audit governance, there are several options for those operating in an SAP-based solutions environment:

 

  1. Leave the legacy SAP system running so that information is available if needed. This can be expensive in terms of personnel, space and costs, since you have to maintain support-pack updates and backup schedules, and have resources to support the system.
  2. Decommission the system after backing up to tape and relying on system recovery if data is needed.  This is not the option I would recommend, as you have the cost of standing up an SAP system to recover ALL data, when only a portion is needed. This may occur multiple times due to changes in audit and legal requirements, and it is time-consuming. Plus, tape also degrades over time and at some point you may not be able to recover data.
  3. You can also move data to a less expensive platform, such as Microsoft SQL platform. The data is compressed, but live and easy to maintain. Costs are low compared to keeping an SAP system up and running. Because you must only move data that needs to be retained, you can purge that which is no longer needed, reducing your space footprint. Governance and compliance issues will also be decreased, as you can move multiple SAP-system data onto one decommissioned system and still keep appropriate security. The result is that there is only one system to support with data from multiple SAP systems.

Decommissioning the legacy system is simplified with the third approach. You select the data, using purpose-built tool sets to move it to a decommissioned platform, then validate. You save space, licensing and support costs. When the data has reached its end of life, you can purge.

I’ve found that this is the best approach, as data can be deleted from decommissioned systems without risk to your functioning SAP system by using the standard deletion process of “select the loaded data file” and delete. And there is no risk to active SAP system(s). I have found that these types of decommissioning projects typically pay for themselves within one year of the project.

The most important thing is to remember is to move data in a controlled manner. For instance, many SAP systems have older data that is not useful, so keeping it available in the active system takes up valuable space. With a controlled method, you take the time to understand what data is needed for those using the system. An example is audit/controls/governance, in which you likely need financial, controlling and asset data, the latter depending on audit regulation and country.

You also want to provide a means for reporting on extracted data that is efficient and enables you to meet response deadlines, which is critical for business and audit purposes.

With the appropriate solutions in place, you can select the data to be moved and have a specified way to report only the data that is needed, while controlling user access to that data through authorizations.

James Baird
Dolphin Corp.

Continue the conversation in the Big Data topic within ISACA’s Knowledge Center.

Comments

There are no comments yet for this post.
You must be logged in and a member to post a comment to this blog.
Email