Legacy data as an AI asset: Why old SAP data should not be trapped in old ERP systems

Author: Audren Butery, SAP Consultant at TJC Group

Historical SAP data can support financial reporting, tax audits, long-term analysis, and future AI use cases. However, retaining valuable data does not mean organisations must continue operating the outdated systems that hold it. A structured system decommissioning strategy can preserve business context and controlled access while reducing cost, security exposure, and technical complexity.

Introduction

When an organisation moves from SAP ECC to S/4HANA, consolidates several ERP platforms, or replaces an old business application, it still needs to decide what happens to the information left behind.

Keeping the original system available in read-only mode may appear to be the cheapest and simplest option. However, it poses significant security threats and compliance risks.

Through legacy system decommissioning, organisations can preserve the historical data, documents, reports, and business context they still need while retiring the technology that created them.

The goal is to retain information that has a valid reporting, compliance, or analytical purpose without maintaining the complete legacy environment indefinitely.

Why legacy SAP data can still hold business value

Data does not automatically lose its value when a system is replaced. Records from SAP systems such as ECC or S/4HANA, as well as other retired SAP and non-SAP applications, may continue to support business decisions long after day-to-day transactions have moved elsewhere.

The value generally falls into three areas:

Business need	Examples of useful legacy information
Reporting and analysis	Historical transactions, balances, pricing, supplier performance, inventory movements
Compliance and evidence	Invoices, accounting documents, tax records, approvals, audit trails
Analytics and AI	Multi-year patterns, exceptions, outcomes, customer behaviour, operational history

The appropriate retention period, access method, and level of detail will differ for each category.

Historical reporting and trend analysis

Operational reports tend to focus on the current period. Strategic analysis often needs a longer view.

Finance teams may compare margins, working capital, closing activity, or payment behaviour across several years. Procurement teams may assess supplier reliability through multiple economic cycles. Operations teams may examine production, inventory, and maintenance patterns before and after a major change.

Older reports may become especially valuable after a merger, restructuring, or S/4HANA migration, when current reporting no longer includes every period or legal entity.

For example, during an S/4HANA programme, some business data may be transformed and loaded into the new environment, while older information remains in the legacy system or is extracted for governed long-term access. Because migration often involves an ETL process, the data used in S/4HANA may no longer represent the original source exactly. For audit, reconciliation, or future reference, organisations may still need faithful extraction from the original ECC system, along with the documents, relationships, and context required to understand it.

The data does not need to remain inside the original ERP to support these tasks. It does, however, need enough context for users to understand what the figures mean.

Audit, tax, and compliance requirements

Historical information may also need to remain available for tax authorities, statutory audits, regulatory reviews, litigation, or internal investigations.

The requirement is rarely limited to a single table or accounting total. Auditors may need the transaction, its supporting document, the approval history, relevant master data, and evidence of how the information was retained or later destroyed.

Retention requirements may differ by country, legal entity, document type, and industry. Privacy rules may also require personal data to be blocked or destroyed when its lawful purpose expires.

Organisations must therefore balance preservation with controlled deletion.

Information should remain available while a valid legal, fiscal, or business obligation applies. Once that purpose expires, data must be destroyed to comply with data privacy laws. Data masking may help limit visibility, but it does not replace deletion because it is non-destructive. Legacy access environments therefore need data privacy mechanisms that can support controlled deletion when information has reached the end of its retention period or no longer has a valid purpose.

SAP ILM and GDPR controls can support retention, blocking, legal holds, and controlled destruction. Equivalent controls must remain effective after the source system is retired.

Potential use in analytics and AI models

Historical ERP data can show how the business behaved under different conditions.

Depending on the use case, it may support analysis of customer payment behaviour, supplier reliability, demand patterns, equipment failures, or financial exceptions.

Multi-year information can reveal patterns that may not appear in the current ERP alone. It can also help organisations compare outcomes across different market conditions, organisational structures, or business policies.

Preserving that history keeps future analytical options open. Whether the information is suitable for a particular AI use case should be assessed separately.

Historic data contains valuable insights for forecasting, supply chain, and customer trends. Proper curation fuels predictive and generative AI models effectively.

Why valuable data often remains trapped in legacy systems

Many organisations retain old applications because users still need occasional access to their data.

A finance team may need an invoice from eight years ago. A tax team may need records from a closed legal entity. An auditor may ask for the original report behind a historic balance. A customer-service team may need a transaction from a retired regional ERP.

The organisation therefore places the system in read-only mode and postpones retirement.

This is sunsetting rather than full decommissioning. Sunsetting keeps the application available, while decommissioning preserves the required information elsewhere and retires the original application.

Data often remains trapped because reports still depend on the original application logic or because documents are stored separately from the underlying transactions. Custom tables may be poorly documented, interfaces may not have been mapped, and users may be unsure which historical records they will need later.

The organisation may also lack an alternative platform that can preserve transactions, documents, reports, and relationships in a form that business users and auditors can understand.

These concerns should define the information and validation requirements of the decommissioning project. They do not necessarily justify keeping the complete application operational.

The cost and risk of keeping old systems operational

A read-only legacy system may no longer process new transactions, but it still requires ongoing management.

The business continues paying for an application whose main purpose is occasional historical retrieval.

Cost or risk	Continuing requirement
Infrastructure	Servers, databases, storage, backups, disaster recovery
Software	Application, database, operating-system, and middleware licences
Operations	Monitoring, incident response, patching, and access administration
Expertise	Specialists who understand the old technology and data model
Security	Vulnerability management, authentication, and privileged access
Compliance	Retention, deletion, audit evidence, privacy controls, and authorised data-removal processes

Over time, the environment becomes harder to support while the level of useful business activity continues to fall.

Infrastructure, licensing, and maintenance costs

Legacy applications may depend on outdated hardware, unsupported database versions, old operating systems, or dedicated hosting arrangements.

Moving the system to cloud infrastructure does not remove the cost. The organisation may still pay for computing capacity, storage, backups, monitoring, software licences, specialist support, interfaces, and disaster-recovery arrangements. Some components may no longer receive regular patches or vendor updates, increasing cybersecurity exposure over time.

These expenses are often spread across several budgets, which can hide the full cost of retaining the application.

The financial impact of keeping legacy systems should therefore be assessed at portfolio level. An organisation may have dozens of retired or semi-retired applications, each consuming money and technical attention.

Together, they can divert resources from S/4HANA, SAP BTP, analytics, security, and AI programmes.

Security and access-control risks

Older systems may not support the organisation’s current identity, authentication, encryption, or monitoring standards.

For example, legacy SAP user accounts may sit outside the current identity provider, while broad display roles created years earlier may no longer be included in modern access-review processes.

Unsupported components can also make patching difficult. Security teams may have to choose between changing an unstable system or leaving a known weakness unresolved.

Moving historical information into a supported access environment can reduce this exposure by applying current authentication, logging, authorisation, and data-protection controls.

The objective is not simply to copy the database. It is to place the retained information under a more sustainable security model.

Compliance challenges in unsupported systems

Compliance becomes harder when historical information is spread across several legacy applications.

Each system may use different retention rules, destruction processes, access models, and audit mechanisms. Some records may contain personal information that should eventually be blocked or deleted, while others may remain subject to legal holds.

An unsupported application may preserve the original record but lack the controls needed to manage it throughout the rest of its lifecycle. Many legacy applications were designed before modern data privacy requirements existed, so they may not include reliable mechanisms for privacy review, controlled deletion, evidence capture, or authorised data-removal workflows.

For example, the application may not support the controlled destruction of an expired customer record without affecting related documents or accounting evidence. This creates a compliance gap: the organisation may be responsible for applying privacy rules, but the old system may not provide the features needed to apply them safely.

Decommissioning provides an opportunity to manage legacy information under a more controlled access model. This can simplify retrieval, access reviews, privacy checks, and audit support. However, privacy and deletion rules still need to be assessed and applied according to the specific source system, data type, and retention requirement, rather than assuming one single policy can automatically apply across every retired system.

What legacy data needs before it can support AI

Historical data is not automatically suitable for analytics or AI, but it is not always directly usable in its raw legacy-system form. Some data may be difficult to retrieve, stored in structures that were not designed for modern analytical use, or held in formats such as clustered, encrypted, or custom tables. Before it can support AI, the data needs to be extracted with context, checked for quality, and prepared for the intended use case.

For enterprise use cases, it must remain understandable, consistent, traceable, and available under defined permissions.

This is particularly important for SAP data because business meaning is often distributed across transactions, master data, configuration, custom fields, organisational structures, and supporting documents.

Business context and metadata

A table of historical transactions has limited value if users cannot explain what each field represents, which company code created the record, which currency and fiscal period apply, or whether identifiers changed during mergers or migrations.

They may also need to understand whether the original result was influenced by source-system configuration, custom fields, reports, or business rules, where supporting documents are stored, and how the record relates to other business objects. This does not mean recreating the original application logic in the decommissioning platform.

Metadata preserves this meaning.

It may include table definitions, field descriptions, document relationships, organisational context, report logic, source-system identifiers, extraction dates, extraction logs, and traceability back to the original system.

Preserving report logic deserves particular attention. A historical financial report may depend on exchange-rate tables, fiscal calendars, configuration values, custom calculations, or rules that changed over time. Supporting attachments may also sit outside the SAP database.

Retaining transaction tables alone may therefore be insufficient to reproduce the original result.

Consider a model designed to predict payment delays.

• It may combine current receivables from S/4HANA, historic payment behaviour from ECC, dispute information from a retired customer-service system, and customer attributes from a former regional application.

• Those sources cannot be treated as interchangeable until customer identifiers, currencies, payment terms, date formats, and business definitions have been reconciled.

• Historical data must remain connected to the context that gives it meaning.

Preparing historical data for analytics and AI

Decommissioning preserves historical information and the context required to use it after the source application has been retired.

For analytics or AI, selected information may still need to be mapped, standardised, or prepared for the specific use case, particularly where business structures or definitions have changed over time.

This does not reduce the value of decommissioning. It separates two different requirements: preserving reliable access to historical information and preparing selected data for a particular analytical or AI purpose.

Governance and controlled access

Historical data should not become more widely available simply because it is being considered for AI.

User authorisation, purpose-based access, masking, retention, deletion, audit trails, data residency, and confidentiality requirements continue to apply.

A platform may preserve historical records for compliant retrieval, while a separate controlled pipeline supplies selected information to SAP Business Data Cloud, a data lake, a warehouse, or another analytical platform.

These access patterns serve different purposes:

Access need	Typical requirement
Historical retrieval	Source data, documents, saved reports, relationships, and traceability, without recreating SAP transactions in the legacy-access platform
Audit or tax response	Reproducible evidence with controlled user access
Analytics or AI	Selected, transformed, and quality-assessed data supplied through an approved pipeline

The legacy repository and the AI platform do not need to be the same system.

Preserving historical information in a legacy-access environment allows organisations to keep the current ERP focused on active operations while maintaining access to the data, documents, and reports expected to be needed after retirement. It does not mean the platform should be treated as a pure cold-storage layer for every possible future use case.

When a later analytics or AI use case is approved, the organisation should define a separate access or extraction process from the retained legacy data. The purpose, permissions, data quality, and retention status should be checked before that information is used outside the legacy-access environment.

How to preserve historical information while decommissioning the source system

A successful decommissioning project does not begin by switching off the application.

It begins by identifying which historical information users, auditors, tax teams, and business owners will still need after the source system is retired. This may include business data, documents, attachments, reports, source-system references, and enough context to make the retained information understandable.

The objective is not to recreate the legacy application in a new platform. It is to preserve the information that still has a valid business, legal, fiscal, or reporting purpose, while allowing the original system to be retired.

For this reason, the scope should be agreed before shutdown. The organisation should confirm which data and documents need to remain accessible, who will need access, how retrieval will be tested, and which privacy, retention, and legal-hold requirements still apply.

Once this scope is clear, the most important stages are validation and controlled retirement.

1. Signed-off reconciliation and retrieval testing

Business users, auditors, tax teams, and data owners should confirm that the retained information is complete and usable.

Testing should cover the retrieval of transactions, reports, documents, and attachments. It should also confirm that totals reconcile with the source, user roles work as intended, and applicable privacy or legal-hold controls remain effective.

Where historical reports must be reproduced, testing should confirm that the necessary logic, configuration, and supporting data have been preserved.

The source system should remain available until the relevant owners have approved the results.

2. Application retirement and controlled future access

Once extraction, reconciliation, and user testing are complete, the organisation can retire the old infrastructure, licences, interfaces, accounts, and support processes.

Historical information can remain available through a durable legacy-access model.

The retirement plan should define how routine historical retrieval, audit support, legal enquiries, and approved analytical extracts will be managed after shutdown.

How ELSA supports legacy system decommissioning and long-term data access

The Enterprise Legacy System Application, or ELSA, is TJC Group’s solution for decommissioning SAP and non-SAP systems while preserving access to historical information.

ELSA separates long-term access from the original application and can retain business data, documents, attachments, reports, relationships, source-system context, and audit information.

Authorised users can search, query, report on, and retrieve this information after the old application has been retired.

A decommissioning project with ELSA may include source assessment, data and document extraction, reconciliation, preparation and preservation of required reports, access and privacy configuration, user acceptance testing, application retirement, and long-term support. Where historical reports are required, they should normally be generated from the source system before or during the project and stored for future access, rather than recreated in the legacy-access platform.

ELSA can be deployed in the customer’s SAP BTP environment or in TJC Group’s SAP BTP environment, while the data storage remains customer-owned. Depending on the customer’s architecture, that storage may be cloud-based or on-premises. TJC Group does not take over the storage of customer data. ELSA is certified as built on SAP BTP and available on SAP store. Its SAP BTP certification supports its role within modern SAP landscapes.

Project outcome	Business effect
Retire legacy applications	Reduce infrastructure, licensing, and support requirements and cybersecurity exposure
Preserve historical access	Keep data, documents, reports, and relationships available
Centralise legacy information	Access several retired SAP and non-SAP systems through one platform
Apply current governance controls	Use modern authorisation, privacy, retention, and audit controls
Support future analytics and AI	Allow approved applications or analytics and AI pipelines to access selected legacy data through ELSA’s API under defined permissions
Maintain traceability	Preserve source information and lineage after application retirement

ELSA allows the current ERP to remain focused on active operations while historical information remains accessible through ELSA. Where required, approved applications or analytics and AI pipelines can access selected legacy data through ELSA’s API under defined permissions.

Conclusion

Retiring a legacy SAP system does not have to mean losing the information it holds. Historical transactions, documents, reports, and business context can retain real value for reporting, audits, tax obligations, and future AI use cases, long after the original application stops running.

The risk lies in leaving that value trapped inside an ageing, costly, and increasingly vulnerable system. A structured decommissioning approach, built on validated extraction, reconciliation, and governed access, lets organisations preserve what still matters while retiring what no longer needs to run.

With ELSA, TJC Group helps organisations make that shift with confidence: retaining traceable, well-governed access to legacy data while reducing infrastructure costs, security exposure, and compliance risk, so historical information stays ready to support the business, whenever and however it is needed next.