The server in the basement has been running for years for a single purpose: in case a tax auditor or an OEM auditor asks. The old ERP system is no longer supported, the operating system no longer receives security updates, and the only colleague who still understands the database is retiring in two years. Yet no one dares to shut it down. After all, anyone who wants to decommission a legacy system without complying with retention requirements risks gaps during a tax audit, an IATF audit, or a product liability case. With a properly archived dataset, however, the legacy system can still be decommissioned.
THE MOST IMPORTANT POINTS AT A GLANCE
|
IN SHORT
|
What does it mean to decommission a legacy system while still complying with retention requirements?
Decommissioning a legacy system means permanently taking an application—including its database, server, and licenses—out of service. In manufacturing, this typically applies to replaced ERP systems, old MES installations, test bench databases, screw data servers, or in-house quality applications. Complying with the retention requirement despite this means that all information subject to retention from this system remains available, unaltered, and analyzable until the end of its statutory, normative, or contractual retention period.
Legacy system archiving is the transfer of data subject to retention requirements from a legacy system into an audit-proof archive that keeps this data readable and analyzable without the original software. In English-speaking countries, this process is called “application retirement” or “decommissioning.” The legal standard is set by Section 147(2)(2) of the German Fiscal Code (AO): Electronically stored documents must be available at all times throughout the entire retention period, must be made readable immediately, and must be capable of being analyzed by machine.
A decommissioning project therefore only becomes risky if the server goes offline before anyone has verified that the data is available outside the system in a complete and analyzable form. Once this verification is in place, the legacy system can be shut down according to plan. The article “Replacing Legacy Systems” provides an overview of the replacement process itself.
THE FOUR KEY RETENTION PERIODS
|
What retention periods apply to data from legacy systems?
The applicable retention period depends on the content of the data. A single ERP or MES system often contains data with five different retention periods: accounting documents, business correspondence, production orders, inspection results, and batch data. In the decommissioning plan, the longest retention period applicable to each data set is used.
| Data Type | Minimum Retention Period | Legal Basis | Start of Retention Period |
|---|---|---|---|
| Books, inventories, annual financial statements, management reports, work instructions | 10 years | Section 147(3) of the German Fiscal Code (AO), Section 257(4) of the German Commercial Code (HGB) | End of the calendar year in which the last entry or preparation took place |
| Accounting documents (invoices, expense receipts) | 8 years | § 147(3) AO, § 257(4) HGB | End of the calendar year in which the document was created |
| Received and sent commercial and business letters | 6 years | § 147(3) AO, § 257(4) HGB | End of the calendar year in which the document was received or sent |
| Technical documentation for medical devices | 10 years; 15 years for implants | Art. 10(8) MDR | Placing the last product on the market |
| PPAP, tooling, design and process records (automotive) | Product service life plus 1 calendar year, unless otherwise specified by the customer or regulatory authority | IATF 16949, Section 7.5.3.2.1 | End of production run and spare parts supply |
| Evidence for product liability claims (products as of December 9, 2026) | Claims expire after 10 years; for latent personal injury claims, after 25 years | Directive (EU) 2024/2853, new Product Liability Act | Placing on the market or putting into service |
Two rules extend the deadline. First, pursuant to Section 147(4) of the German Fiscal Code (AO), any time limit does not begin until the end of the calendar year in which the document was created. Second, pursuant to § 147(3) of the German Fiscal Code (AO), the tax-related time limit does not expire as long as the assessment period for the taxes in question is still open. This suspension of the time limit applies, for example, during ongoing tax audits or appeal proceedings.
In the automotive industry, contractual deadlines can be significantly longer than the standard. In published customer-specific requirements (CSR), Mercedes-Benz, citing VDA Volume 1, requires that PPA documents be archived for 15 years after the end of series production. General Motors, according to its CSR, even requires PPAP records to be retained for the duration of production plus 50 years. Anyone decommissioning an MES or an inspection database must therefore include these customer requirements in their list of retention periods. The article “Retention Periods According to the German Commercial Code (HGB), GDPR, and GoBD” provides a concise overview of commercial retention periods.
PRACTICAL NOTE ON THE 2025 RETENTION PERIOD REDUCTIONAs of January 1, 2025, a retention period of eight years instead of ten applies to accounting documents (Section 147(3) AO, Section 257(4) HGB). This does not affect production data. Before deleting any data, check whether the same data record is also subject to IATF 16949, MDR, or an OEM requirement. |
Why a backup does not satisfy the retention requirement
When decommissioning a legacy system, many teams initially plan as follows: back up the database, shut down the server, and put the backup on a shelf. This fails to meet three requirements. A database dump is unreadable without the appropriate database version, schema, and application logic. It cannot be analyzed by a machine because queries are only possible after a complete restore. And it cannot be verifiably unaltered because no one can prove that the content has remained the same since the backup was taken.
The tax authorities set the standard in the GoBD (BMF letter dated November 28, 2019, last amended on July 14, 2025). If data is no longer stored in the production system following a system change, it must be transferred to a system that allows for equivalent analyses.
“The new system must enable the same quantitative and qualitative analyses of the data subject to recording and retention requirements as if the data were still in the production system.”
Based on GoBD, Marginal Note 142
If this transfer fails, the GoBD requires that the original hardware and software of the production system be retained for the duration of the retention period. As a result, servers that no longer receive any maintenance continue to run in many plants. The article “Backup vs. Archiving” discusses this difference in detail.
| Criterion | Backup | Database Dump | Audit-Proof Archive |
|---|---|---|---|
| Purpose | Recovery after data loss | Technical copy of a database | Retention beyond the statutory period |
| Readable without legacy software | No | No | Yes |
| Machine-readable (Section 147(2) AO) | Only after a backup | Only after import | |
| Verifiable immutability | No, it will be overwritten | No | Yes, with checksums and a log |
| Targeted deletion after expiration | Not possible | Only by re-exporting | Possible on a per-record basis |
What Section 147(6) of the German Fiscal Code (AO) requires when changing systems: Z1, Z2, Z3, and the five-year rule
During an on-site audit, the tax authority may access electronically created documents in three ways under Section 147(6) of the German Fiscal Code (AO). In practice, these access methods are referred to as Z1, Z2, and Z3. All three must continue to function even after the legacy system has been decommissioned.
| Access Type | What the auditor may request | Impact on the legacy system |
|---|---|---|
| Z1 Direct Access | Access to stored data and use of the system for the audit | Archive requires read-only access with search and filter functions |
| Z2 Indirect access | Automated analysis of the data by the company according to its specifications | The archive must generate analyses without legacy software |
| Z3 Data transfer | Transfer of data in a machine-readable format | Export in a machine-readable format, including a description of the structure |
The five-year rule following a system change
Section 147(6) of the German Fiscal Code (AO) now expressly includes a provision that is relevant to every system decommissioning project. 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 fifth calendar year following the transition—to retain the data exclusively on a machine-readable and analyzable data carrier. This is subject to the condition that no external audit has yet begun at that time.
Here’s an example: A plant switches from the old to a new ERP system in 2026. The five subsequent calendar years are 2027 through 2031. Full data access (Z1 and Z2) must be available until December 31, 2031; starting January 1, 2032, the data storage medium alone is sufficient. A journal entry from 2025 must still be retained until the end of 2033, and annual financial statements for 2025 prepared in 2026 must be retained until the end of 2036.
LIMITS OF THE FIVE-YEAR RULEThe rule only shortens the time required for tax authorities to access the data; it does not shorten the retention period itself. It does not apply to audit data under IATF 16949, technical documentation under the MDR, or evidence in product liability cases. It also does not apply if an external audit has already begun. Therefore, coordinate the timing of the deactivation with your tax advisor. |
A Comparison of Four Approaches for Legacy Data: Continued Operation, Migration, Freezing, and Archiving
There are four options for data from a legacy system. Each fulfills the retention requirement under certain conditions. The legacy system can only be decommissioned after a full migration or archiving.
| Option | Description | Meets retention requirements | Legacy system can be decommissioned | Typical Risk |
|---|---|---|---|---|
| 1. Continued operation | Legacy system runs in read-only mode until the deadline | Yes, as long as it is running | No | Missing security updates, loss of expertise, license costs |
| 2. Full Migration | All historical data is migrated to the successor system | Yes, provided completeness is verified | Yes | Significant mapping effort; legacy data burdens the new system |
| 3. Freeze | The legacy system is virtualized and started as needed | Limited | Only partially | If the virtual machine no longer starts after several years, access is lost |
| 4. Legacy System Archiving | Data, including context, is moved to an audit-proof archive, followed by decommissioning | Yes | Yes | Requires a clear retention schedule and proof of completeness |
A full migration sounds like the simplest option, but it is rarely cost-effective in manufacturing. Historical test values, screw-driving curves, and batch data often do not fit into the successor system’s data model and permanently increase the size of its database. With a “freeze,” the problem persists, because even a virtual machine requires a functional operating system, licenses, and staff capable of operating the application. Legacy system archiving separates the data from the application. The legacy system can be shut down without burdening the successor system with historical data.
Shut Down the Legacy System and Comply with Retention Requirements in Six Steps
These six steps apply to an ERP system just as much as they do to an MES or a test bench database.
- System Inventory: Identify all applications, databases, interfaces, and user groups of the legacy system. Determine which processes still access the data in read-only or write mode.
- Data classification and retention schedule: Assign each table and document to a data type and specify the longest applicable retention period based on the German Fiscal Code (AO), the German Commercial Code (HGB), IATF 16949, the Medical Device Regulation (MDR), product liability laws, and customer requirements.
- Define the Archive Format and Context: Archive not only raw data but also schemas, relationships, master data, and reporting logic in a software-independent format such as XML or CSV with a structural description.
- Verify completeness: Document record counts, total values, and checksums before and after the transfer. This comparison serves as proof that nothing was lost and nothing was altered.
- Regulate access and procedure documentation: Specify who in the business unit, accounting, or audit department has access to which data. Describe the procedure in the procedure documentation in accordance with GoBD.
- Shut Down and Delete After the Retention Period Expires: Do not shut down the legacy system until the reconciliation has been successfully completed. Delete archived data records as soon as their retention period has expired and there are no factors preventing their deletion.
Step four determines whether the archive will withstand an audit. An auditor or tax examiner wants to see proof that all data has been transferred to the archive. A comparison of data records per table before and after the transfer, supplemented by checksums, answers this question in just a few minutes. The article on audit trails in manufacturing describes how to structure audit trails for an audit.
Step six also pertains to data protection. The General Data Protection Regulation (GDPR) requires, in Article 5(1)(e) GDPR, that personal data be stored only for as long as necessary for the purpose, and Article 17 GDPR governs the obligation to erase data. This includes worker IDs, login credentials, and employee ID numbers in production data. An archive must therefore be able to delete individual data records once the retention period has expired. The article on the GDPR-compliant deletion policy in manufacturing facilities illustrates what such a concept looks like.
The Five Most Common Mistakes Companies Make When Decommissioning Legacy Systems
- Only the accounting department is consulted. Everyone knows the tax deadlines, but often only the quality management team is aware of the deadlines specified in IATF 16949, the MDR, and OEM requirements. Therefore, involve QM and production in the project from the very beginning.
- Raw data is backed up without context. Ten years later, no one will understand a table with column names like FIELD_17. Be sure to archive master data, key relationships, and the meaning of the fields as well.
- The five-year rule is being stretched too far. The data carrier required under Section 147(6) of the German Fiscal Code (AO) only serves to facilitate tax audits. For an OEM audit or a recall, you still need to be able to perform quick, targeted queries.
- There is no proof of completeness. Without reconciling record counts and checksums, it is impossible to verify that the archive matches the legacy system.
- The system shutdown date precedes the archive test. Simulate typical auditor requests—such as retrieving all audit results for a specific serial number—before shutting down the server.
Most of these errors can be avoided if quality management, accounting, and IT share responsibility for the project. They often only become apparent years after the system is taken offline, during an audit or in the event of a liability claim. The article on the costs of non-archiving and liability highlights the financial consequences that a lack of archiving can have.
Case Study: Seven Systems, One Archive
A project reported on by Computerwoche illustrates what large-scale legacy system archiving looks like. During the winding-down of the Schlecker drugstore chain, CSP prepared seven different systems for decommissioning, including a Navision ERP system, a highly customized AS/400 system, an intranet, and a Teradata data warehouse. According to the report, after assessing the current situation, a separate database archive was created for each system, complete with forms, queries, and reports for future research.
Afterward, data from all seven systems could be searched via a unified interface without any of the original systems needing to remain operational. In manufacturing, this works just as well for MES, test benches, and quality databases. The KLS Martin Group’s success story demonstrates how a medical technology manufacturer secures its application data using CHRONOS.
How CHRONOS Implements Legacy System Archiving
CHRONOS is the database archiving module in CSP’s Manufacturing OS. The software was developed between 2004 and 2006 as part of a research collaboration with the Department of Computer Science at Landshut University of Applied Sciences and transfers data from relational databases into an archive consisting of text and XML files. This ensures that the data remains readable regardless of the manufacturer of the original database.
- CHRONOS archives the data from a legacy system that is subject to retention requirements; afterward, the application and database can be decommissioned.
- Individual data records can be retrieved and analyzed directly from the archive without having to restore the entire database.
- Long-term archiving is audit-compliant and designed to meet the requirements of GoBD, MDR, and IATF 16949.
- Quality management and audit teams can access archived data without an IT ticket. The article “Archive Access Without an IT Ticket” describes how this is organized.
In day-to-day operations, the BMW Group uses CHRONOS for monthly archiving to reduce storage costs. When a system is decommissioned, the archive takes over storage entirely, and the legacy system can be taken offline. You can find more information about the module on the CHRONOS Data Archiving page.
Frequently Asked Questions
How long must a legacy system be maintained after a system migration?
The legacy system itself does not need to be retained if its data subject to retention requirements has been transferred in full and in a machine-readable format to an archive or successor system (GoBD Marginal Note 142). If this is not possible, the hardware and software must be kept in operation until the end of the longest retention period, which is generally ten years (Section 147(3) of the German Fiscal Code (AO)).
Is a single data storage medium sufficient for a tax audit after five years?
Yes, for tax-related data access. According to § 147(6) AO, once the fifth calendar year following the conversion or outsourcing has elapsed, a machine-readable and analyzable data carrier is sufficient, provided that no on-site audit has yet begun. This does not shorten the retention period itself.
May I decommission a legacy system if the retention period is still in effect?
Yes, provided the data has been archived in an audit-proof manner beforehand and remains available, readable, and machine-readable there for the entire retention period (Section 147(2)(2) of the German Fiscal Code (AO)). Document the completeness of the transfer and describe the procedure in the procedural documentation.
What is legacy system archiving?
Legacy system archiving is the transfer of all data subject to retention requirements from a legacy system into an audit-proof archive that keeps the data readable and analyzable without the original software. It is a prerequisite for decommissioning a legacy system while still complying with retention requirements.
What is the difference between application retirement and data archiving?
In ongoing data archiving, an active system offloads old data and remains in operation. In application retirement, the application is completely decommissioned after its data has been archived. Both processes use the same archiving technology but pursue different goals: reducing the system’s load in the first case, and decommissioning it in the second.
Does the five-year rule also apply to production and quality data?
No. The rule in Section 147(6) of the German Fiscal Code (AO) applies only to data access by the tax authorities. Separate retention periods apply to production data, for example, the product’s service life plus one calendar year according to IATF 16949 Section 7.5.3.2.1, or at least ten years according to Art. 10(8) of the MDR.
When must archived historical data be deleted?
Personal data must be deleted as soon as the retention period has expired (Art. 5(1)(e) and Art. 17 of the GDPR). Tax-related data may not be deleted until the assessment period has also expired (Section 147(3) of the German Fiscal Code (AO)). An archive should therefore be able to delete individual data records in accordance with the applicable retention periods.
Sources
- § 147 of the German Fiscal Code, Regulations Governing the Retention of Documents (Source)
- § 257 of the German Commercial Code, Retention of Documents (Source)
- BMF GoBD Letter dated November 28, 2019, last amended on July 14, 2025, Marginal Numbers 142 through 144 (System Change)
- Regulation (EU) 2017/745 (MDR), Article 10(8) (Source)
- IATF 16949:2016, Section 7.5.3.2.1 Retention of Records
- Customer-specific requirements for Mercedes-Benz (MBST 13/18) and General Motors (GMW15920), published by SMR Automotive (Source)
- Directive (EU) 2024/2853 on Liability for Defective Products, Summary on EUR-Lex (Source)
- Computerwoche: Why Anton Schlecker Still Needs IT (Source)
- Wikipedia: Database preservation (CHRONOS, Landshut University of Applied Sciences) (Source)
- Storage Newsletter: Chronos Archiving Solution for Application Retirement (Source)
- DirectIndustry: Database Archiving with Chronos at the BMW Group (Source)
Note: This article is not a substitute for tax or legal advice. Please coordinate deadlines and decommissioning dates with your tax advisor.
