The ERP system from 2009 hasn't recorded any transactions for years. Nevertheless, the server is still running, the database license is renewed every year, and no one dares to pull the plug. The reason isn’t in any project plan: somewhere in those tables are transaction documents, audit logs, and serial numbers that a tax auditor or a customer might want to see years later in the event of a complaint. Anyone who wants to archive legacy systems must therefore first answer a question that has little to do with technology: What data must survive when the application is discontinued?
THE MOST IMPORTANT POINTS AT A GLANCE
|
IN SHORT
|
What does it mean to archive and decommission legacy systems?
Archiving legacy systems means transferring data that is subject to retention requirements and is still needed for business purposes from an application that is no longer in operational use to a standalone archive. The archive then assumes the role of the legacy system for read access, analyses, and audits. The application itself, its database, and the underlying hardware can then be shut down.
In common parlance, several terms are used interchangeably, each referring to a different part of the same process:
| Term | What it means | Result |
|---|---|---|
| Archiving | Transferring data from the legacy system to an independent, audit-proof archive | Data remains readable and analyzable |
| Decommissioning | Set the application to read-only mode or take it completely offline | No new entries, no changes |
| Shut down | Permanently decommission the server, database, and licenses | Operating costs eliminated |
| Application Retirement | English umbrella term for the entire process of archiving, decommissioning, and shutting down | The legacy system has been completely replaced |
The trade journal Computerwoche describes application retirement as the decommissioning of obsolete systems and cites corporate mergers as a typical trigger. In manufacturing, this is further compounded by ERP migrations, MES replacements, plant closures, and version upgrades, after which the old database is no longer maintained. The article “Shutting Down Legacy Systems in Manufacturing” discusses how the technical shutdown process works in manufacturing. This article focuses on the data aspect: what needs to be archived, for how long, and in what format.
|
8 years Retention period for accounting documents effective January 1, 2025 Source: Section 147(3) of the German Fiscal Code (AO) as amended by the Fourth Bureaucracy Relief Act |
10 years Retention period for books, inventories, and annual financial statements Source: Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB) |
5 calendar years After a system change, full auditability remains mandatory Source: Section 147(6) AO |
44% of the surveyed companies classify at least half of their existing systems as legacy systems Source: “Legacy Modernization 2022” study by CIO and Computerwoche |
Why do legacy systems continue to run even though no one uses them anymore?
Legacy systems usually remain online because no one can say for certain whether the data they contain is still needed. This creates a “shadow operation” that ties up budget and no longer supports any business processes.
The “Legacy Modernization 2022” study, published by CIO and Computerwoche in collaboration with partners, illustrates the extent of the problem: In 44 percent of the companies surveyed, at least 50 percent of existing systems are considered legacy systems. A recent example comes from the German-Speaking SAP User Group (DSAG). According to its February 2026 survey, as reported by cloudmagazin, nearly half of German-speaking SAP users intend to continue operating their ECC systems beyond 2027, even though mainstream support is set to expire.
What Makes Up the Costs of a Legacy System
| Cost Category | What specifically is incurred | Does this cost disappear after archiving? |
|---|---|---|
| Database license | Annual maintenance for Oracle, SQL Server, DB2, or Informix | Yes |
| Application license | Maintenance contract or extended support from the manufacturer | Yes |
| Infrastructure | Servers, storage, backup, virtualization, data center space | Yes |
| Operations | Patches, monitoring, user management, expert on legacy technology | Yes |
| Security | Unpatched operating systems and databases as potential attack vectors | Yes |
| Archive | Storage and operation of the archive | No, but significantly lower |
The article “Why Database Licenses Drive Up IT Costs in the Manufacturing Industry” illustrates just how significant database licenses alone are. The article “The Costs of Not Archiving” describes the liability risks that arise when data is not archived at all.
|
Common Mistake: Continuing to Use the Legacy System as an Archive Putting the legacy system into read-only mode after the migration and designating it as an archive saves project effort in the short term. However, costs and risks remain: licenses, hardware, and the operating system continue to age, and with each passing year, the number of employees who can still operate the system decreases. If the operating system no longer receives security updates, a security problem is added to the cost problem. |
What retention periods apply to data from legacy systems?
The question of how long data from a legacy system must remain available determines the scope and architecture of the archive. For manufacturing companies, three legal frameworks generally apply simultaneously: tax and commercial law, product liability, and customer requirements stemming from standards such as IATF 16949.
| Data Type | Retention Period | Legal Basis |
|---|---|---|
| Books, records, inventories, annual financial statements | 10 years | Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB) |
| Accounting documents, such as invoices | 8 years (effective January 1, 2025; previously 10 years) | Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB), Fourth Bureaucracy Relief Act |
| Commercial and business correspondence received and sent | 6 years | Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB) |
| Production approvals, tooling, and process design records (automotive) | The product’s active production and service life plus one calendar year, unless otherwise specified by the customer or a regulatory authority | IATF 16949, Section 7.5.3.2.1 |
| Evidence of product safety | Claims under the Product Liability Act expire 10 years after the product is placed on the market | Section 13 of the Product Liability Act |
Two factors extend the deadlines in practice. First, according to Section 147(3) of the German Fiscal Code (AO), the tax retention period does not expire as long as the documents are relevant to taxes for which the assessment period is still ongoing. Second, the new EU Product Liability Directive (EU) 2024/2853 introduces an extension: According to EUR-Lex, the statute of limitations is extended from ten to 25 years if personal injuries occur only gradually. According to the government’s draft bill, the new German Product Liability Act is scheduled to take effect on December 9, 2026, and will apply to products placed on the market on or after that date. For archival planning purposes, therefore, the longest of the applicable periods applies.
A complete overview of the retention periods under the German Commercial Code (HGB), the German Fiscal Code (AO), and the General Data Protection Regulation (GDPR) is provided in the article “Retention Periods under the HGB, GDPR, and GoBD.”
|
WHITEPAPER Data Governance for Structured Data Before a legacy system is decommissioned, it must be determined who owns which data, how long it must be retained, and who is authorized to access it. This white paper explains how to establish these rules for database content and enforce them in the archive. |
Migrate, archive, or continue operating: Which approach is right for you?
Before any system is decommissioned, a decision must be made about what to do with the data. There are three possible approaches, and none is universally correct. The key factors are the proportion of data that is needed for operations in the new system and the effort required to convert old data structures into new ones.
| Criterion | Migrate completely | Archive and decommission | Continue Operation |
|---|---|---|---|
| Data is needed for day-to-day operations | Yes, open items and master data | No, read-only access | No |
| Data model matches the target system | Required | Not required | Not relevant |
| Effort | High, mapping of each table | Medium—one-time export with validation | Low at the beginning, increasing over the years |
| Ongoing costs | Storage in the target system | Archive storage | License, hardware, operation |
| Security risk | Low | Low | Increases with the age of the system |
| Typical Use | Active master data, open orders | Closed fiscal years, audit and process data | Transition phase lasting a few months |
It often comes down to a combination: Active master and transaction data are migrated to the new system, while historical data is moved to the archive. This separation keeps the target system lean and avoids the need to force decades-old data records into a new data model. The article “Greater Efficiency in Cloud Migration” demonstrates how such selective archiving works during cloud migrations. The strategic aspects of system replacement are covered in the article “Replacing Legacy Systems by 2026.”
Which data belongs in the archive and which does not?
An archive does not replicate the old database exactly. It contains the data that is required for legal or technical purposes, plus the metadata necessary to understand it. Every additional data record increases storage requirements and the effort required for verification; in the case of personal data, it also increases the data protection risk.
Mandatory Content: What Belongs in the Archive
- Tax-related data such as journal entries, supporting documents, and master data for customers and suppliers, to the extent necessary for understanding the journal entries.
- Quality and process data such as inspection results, measurement values, torque curves, serial numbers, and batch numbers, which are needed for traceability and handling complaints.
- Work instructions and organizational documents necessary for understanding the records. Section 147(1)(1) of the German Fiscal Code (AO) expressly includes them among the documents subject to retention requirements.
- Metadata such as table descriptions, field definitions, key relationships, and code lists. Without them, the raw data will be virtually impossible to interpret after ten years.
Items for Deletion: What Does Not Belong in the Archive
Personal data for which neither law nor contract requires retention is deleted prior to archiving. This is required by the principle of storage limitation in Article 5(1)(e) of the GDPR. Technical auxiliary data such as temporary tables, application logs, session data, and caches also do not belong in the archive. Data that has been verifiably and completely migrated to the new system does not need a second copy there.
It must also be possible to delete archived data later, once its retention period has expired. An archive without a deletion strategy becomes a legacy system itself after a few years. The article “Backup vs. Archiving” explains how backups and archives differ in this regard.
What are the six steps involved in legacy system archiving?
Decommissioning a legacy system is a project with a clear end point. The following procedure breaks it down into six steps, each of which concludes with a document. These documents serve as evidence in the event of an audit.
| Step | Content | Output Document |
|---|---|---|
| 1. Inventory | Record all legacy systems, including databases, data volumes, license costs, and responsible parties | System list with priority |
| 2. Deadlines and Data Categories | Define the legal basis, retention period, and start date for each data type; involve business units, the tax department, and the data protection office | Retention matrix |
| 3. Archive design | Define data scope, target format, access rights, search fields, and standard reports | Archive concept with procedural documentation |
| 4. Extraction | Export data directly from the database, including metadata and relationships between tables | Export log with record counts |
| 5. Validation | Reconcile record counts, totals, and sample data between the legacy system and the archive; reproduce standard reports in the archive | Acceptance Report |
| 6. Decommissioning | Set the legacy system to read-only, end the parallel phase, and decommission servers and licenses | Decommissioning Log |
Step 5 is the most critical. The validation confirms that the archive provides the same information as the legacy system. Without an acceptance report, it is impossible to prove to an inspector or auditor that nothing was lost during the export. For data coming directly from the database, it is advisable to perform a comparison based on the number of records per table and the totals of numeric fields, supplemented by functional spot checks conducted by the business units.
“A legacy system can be decommissioned as soon as the archive answers the questions that accounting and quality assurance have previously posed to the legacy system.”
Key Point on Acceptance
How can data access remain audit-proof after decommissioning?
Archived data is only valuable if it is available in the required format in the event of an audit. For tax-related data, Section 147(6) of the German Fiscal Code (AO) governs the tax authorities’ access to data. The GoBD distinguishes between three types of access:
| Type of Access | What the auditor does | Requirements for the archive |
|---|---|---|
| Z1: Direct Data Access | The auditor is granted read access to the company’s system | Role-based read access with search and filter functions |
| Z2: Indirect data access | Upon request, the company generates reports according to the auditor’s specifications | Report functions directly within the archive |
| Z3: Provision of Data Media | The data is provided in a machine-readable format | Export includes master data, metadata, and table relationships |
The five-year rule following a system change
A provision in Section 147(6) of the German Fiscal Code (AO) is particularly relevant to system decommissioning: If a company changes its data processing system or transfers data subject to retention requirements out of the production system, it is sufficient, after the expiration of the fifth calendar year following the changeover, to retain the data exclusively on a machine-readable and machine-processable data carrier. This is subject to the condition that no external audit has yet begun.
During the first five years after decommissioning, the archive must allow for analyses equivalent to access to the legacy system. A simple data export is not sufficient during this phase. Nor do PDF files or printouts meet the requirement for machine-readability. With the amendment to the GoBD effective July 14, 2025, the Federal Ministry of Finance has also clarified indirect access (Z2): According to KPMG, the tax authority may require the company to analyze the data electronically in accordance with its specifications or to have it analyzed by a third party it has commissioned.
In addition to tax audits, there are two other scenarios requiring access: internal and external audits—such as those conducted in accordance with IATF 16949—as well as complaints and product liability cases. In both cases, quality departments request serial numbers, test results, and process parameters. An archive that is accessible only via an IT ticket significantly slows down these processes. The article “Archive Access Without an IT Ticket” describes which access models are suitable for various departments. The article “GoBD-Compliant Archiving: Requirements and Implementation” provides an in-depth look at the requirements for GoBD-compliant implementation.
What mistakes could jeopardize decommissioning?
Any of the following errors can result in a system that has already been shut down having to be restarted for testing—if that is even possible at all.
- A database backup is treated as an archive. It can only be restored using the correct database version and often only with the application itself, and after a few years, one of these is missing.
- Tables are exported without field descriptions and code lists. Once the experts leave the company, no one can read the data anymore.
- Record counts and totals are not reconciled. As a result, there is no proof that the archive is complete.
- Only the tax retention period is considered. Customer requirements from IATF 16949 and product liability are not taken into account.
- There is no data retention policy. Data remains stored beyond its retention period, which violates the storage limitations under the GDPR.
- The procedural documentation in accordance with GoBD is not updated. It must also describe the transfer to the archive.
- The business units are not involved. IT is familiar with the spreadsheets, but only Quality Assurance and Accounting know which reports are needed in an emergency.
The article “Audit-Proof Archiving: Choosing the Right Software” discusses what matters when selecting archiving software.
|
NEXT STEP Decommission legacy systems without losing data The “Data Governance” white paper provides the framework for your retention matrix. If you’d like to see firsthand how a database archive can replace your legacy system, schedule a CHRONOS demo. |
How does CHRONOS support the decommissioning of legacy systems?
CHRONOS is the database archiving solution in CSP’s Manufacturing OS. It extracts data directly from the legacy system’s database and converts it into a long-term-stable format that remains readable regardless of database version or application. The legacy system can then be shut down, while access to its data is retained.
|
CHRONOS for Decommissioning Legacy Systems
|
A publicly documented example of a system decommissioning using CHRONOS is the winding-down of Anton Schlecker e.K.i.I. According to Computerwoche, CSP prepared seven systems there for decommissioning, including Navision, a highly customized AS/400 system, an intranet, and a Teradata data warehouse. A separate database archive was created for each system; the data warehouse, containing billions of inventory transactions, was the first to be decommissioned.
The Austrian Institute of Technology compared CHRONOS in a study on long-term digital archiving with SIARD—a tool widely used in the archiving field—for the use cases of database decommissioning, ongoing and partial archiving, and application retirement. In manufacturing, according to a published case study, the BMW Group uses CHRONOS to archive process data from the plant floor at monthly intervals. Another project is described in the article “KLS Martin Group Relys on CHRONOS for Application Data Backup.” The CHRONOS Data Archiving page provides an overview of all features.
Frequently Asked Questions
What is a legacy system?
A legacy system is an application based on outdated technology that is no longer supported—or only supported to a limited extent—by the manufacturer, and for which in-house expertise is dwindling. However, it often contains business-critical data or data subject to retention requirements, which is why it cannot simply be shut down.
What does “application retirement” mean?
Application retirement refers to the entire process of decommissioning an application that is no longer needed. This includes archiving data subject to retention requirements in an independent archive, decommissioning the application, and decommissioning servers, databases, and licenses.
How long must data from a legacy system be retained?
Accounting books, inventories, and annual financial statements must be retained for ten years; accounting documents must be retained for eight years starting January 1, 2025; and commercial and business correspondence must be retained for six years (Section 147(3) of the German Fiscal Code (AO), Section 257 of the German Commercial Code (HGB)). In manufacturing, customer requirements—such as those from IATF 16949—and the ten-year limitation period under § 13 ProdHaftG also apply. The longest period applies.
May a legacy system be decommissioned while retention periods are still in effect?
Yes, provided that the data subject to retention requirements has been fully transferred to an archive in a machine-readable format beforehand. During the first five calendar years following the system change, the archive must allow for analyses equivalent to access to the legacy system. Thereafter, pursuant to Section 147(6) of the German Fiscal Code (AO), a machine-readable and machine-processable data carrier is sufficient, provided that no external audit has begun.
What is the easiest way to decommission a legacy system?
The simplest and most reliable method is a database-level export of the data subject to retention requirements into a standalone archive, followed by validation of record counts and totals. The legacy system is then set to read-only, shut down after a brief parallel phase, and documented with a shutdown log.
Is it possible to migrate existing legacy systems, or do you have to start from scratch?
Both options are possible and are usually combined. Active master data and open transactions are migrated to the new system, while closed fiscal years and historical audit and process data are archived. This way, the historical data does not need to be converted into the new system’s data model.
Is a backup of the legacy system sufficient as an archive?
No. A backup can generally only be restored using the corresponding database version and application and is not intended for research or analysis. The GoBD requires that data be available and machine-readable throughout the entire retention period. Only an archive can meet this requirement.
How can legacy data be retrieved if the software is no longer running?
As long as the database is still accessible, the data can be exported directly at the database level without launching the original application. It is crucial to also back up metadata, table relationships, and code lists to ensure the data remains understandable later on.
Sources
- German Fiscal Code, Section 147: Regulations Governing the Retention of Documents: https://www.gesetze-im-internet.de/ao_1977/__147.html
- Forum Verlag Herkert: Retention Periods for Businesses, Overview (November 12, 2025): https://forum-verlag.com/fachwissen/fuehrung-und-management/aufbewahrungsfristen-unternehmen/
- KPMG: October 2024 VAT Newsletter on the Fourth Bureaucracy Reduction Act: https://assets.kpmg.com/content/dam/kpmg/de/pdf/Themen/2024/10/vat-newsletter-oktober-2024-kpmg-de.pdf
- KPMG: Federal Ministry of Finance (BMF) Letter Regarding the Second Amendment to the GoBD dated July 14, 2025: https://kpmg.com/de/de/themen/2025/07/bmf-gobd-zweite-aenderung.html
- Product Liability Act, Section 13: Expiration of Claims: https://www.gesetze-im-internet.de/prodhaftg/__13.html
- EUR Lex: Summary of Directive (EU) 2024/2853 on Liability for Defective Products: https://eur-lex.europa.eu/DE/legal-content/summary/defective-products-liability.html
- Marsh: New Product Liability Act Effective December 2026: https://www.marsh.com/de/services/casualty/insights/new-product-liability.html
- Advisera: IATF 16949, Section 7.5.3.2.1 on Record Retention: https://community.advisera.com/topic/archiving-period-for-documents-in-iatf-16949/
- REB Tax Consulting: Digital Tax Audits, GoBD Requirements, and Data Access: https://reb-steuerberatung.de/insights/digitale-betriebspruefung-gobd-anforderungen-und-datenzugriff-durch-das-finanzamt.html
- PC Welt: 2022 Legacy Modernization Study by CIO and Computerwoche: https://www.pcwelt.de/?p=1371215
- cloudmagazin: S/4HANA Migration and Data Decommissioning (April 9, 2026), DSAG Survey February 2026: https://www.cloudmagazin.com/2026/04/09/s4hana-migration-data-decommissioning-vergessener-schritt/
- Computerwoche: Why Anton Schlecker Still Needs IT: https://www.computerwoche.de/article/2773510/wozu-anton-schlecker-noch-eine-it-braucht.html
- Computerwoche: CSP’s CHRONOS Generates Reports Directly from the Database Archive: https://www.computerwoche.de/article/2686892/chronos-von-csp-generiert-reports-direkt-aus-dem-datenbankarchiv.html
- Lindley, A. (AIT Austrian Institute of Technology): Database Preservation Evaluation Report, SIARD vs. CHRONOS: https://services.phaidra.univie.ac.at/api/object/o:377400/download
- DirectIndustry: Case Study: Database Archiving with Chronos at BMW Group: https://pdf.directindustry.com/pdf/csp-intelligence-gmbh/database-archiving-chronos-reduces-storage-costs-automotive-manufacturer/4599583-1074287.html
- Regulation (EU) 2016/679 (GDPR), Art. 5(1)(e): https://eur-lex.europa.eu/eli/reg/2016/679/oj
