The virtual machine has been running since 2011. Only two people in the company still know how to log in. The database license is automatically renewed every year, and in every IT roadmap workshop, the system appears on the list of things that need to be addressed at some point. The real reason for keeping it running isn’t documented anywhere: no one can prove that the data it contains is available in its entirety elsewhere. It is precisely this ability to provide proof that is the essence of legacy system archiving, and it determines whether the system will ever be shut down.
THE MOST IMPORTANT POINTS IN A NUTSHELL
|
What Legacy System Archiving Is and How It Differs
Legacy system archiving is the structured transfer of data from an application being phased out into an audit-compliant archive that keeps this data readable, analyzable, and verifiable, independent of the original software.
This definition of legacy system archiving includes three caveats that are often overlooked in projects. “Independent of the source software” means that the old application is no longer needed afterward, not even as a fallback option. “Analyzable” means more than just “displayable.” And “traceable” means that the state of the data has remained verifiably unchanged since the transfer.
In practice, legacy system archiving is regularly confused with three other approaches. The differences between them determine whether the legacy system can ultimately be shut down.
| Approach | Goal | Access to data after eight years | Legacy system thereafter |
|---|---|---|---|
| Continued operation | Availability without project effort | Guaranteed as long as the license, hardware, and expertise are available | Continues to run; costs continue to accrue |
| Backup | Restoration of a system state | Virtually nonexistent, as the runtime environment and database version are missing | Would have to be reconstructed for evaluation |
| Migration | Transfer to a successor system | Possible for migrated data areas, often without history | can be disabled, provided the history is included |
| Legacy system archiving | System-independent storage with audit trail | Provided via the archive, without the original software | Can be completely disabled |
The third line is the most common stumbling block. Migration projects typically transfer master data and open transactions, but not the completed history. It is precisely this history that is subject to retention requirements. That is why, even after many successful migrations, the legacy system remains in operation.
If you’re still deciding whether to replace a system, you’ll find the basis for your evaluation in our article on legacy systems and their replacement. This article assumes that decision has already been made and focuses on the implementation of archiving.
| Value | Meaning | Source |
|---|---|---|
| 10 years | Retention period for trading records and accounting documents | Section 257(4) of the German Commercial Code (HGB), Section 147(3) of the German Fiscal Code (AO) |
| 15 years | Recommended archiving period for documentation on products with special characteristics | VDA Volume 1, Documentation and Archiving |
| 1 month | Deadline for responding to a data subject’s request for information | Art. 12(3) GDPR |
| ISO 14721 | OAIS Reference Model for Digital Long-Term Archiving | ISO 14721, Open Archival Information System |
What should be transferred from a legacy system to the archive?
THE SHORT ANSWERA complete archive package from a legacy system consists of five components. First, the user data—that is, the business content itself. Second, the data model, which documents tables, field types, and relationships. Third, the metadata, which classifies each data record by subject matter and specifies the retention period. Fourth, the logs—that is, the audit trail, change history, and authorization status at the time of transfer. Fifth, the procedural documentation, which describes how the archive was created and why it is complete. If any one of these five components is missing, the archive remains vulnerable in the event of an audit. |
The second component is the one most frequently missing. User data without a data model is simply a collection of columns with cryptic names. A field named STAT with values ranging from 1 to 7 is worthless without a value table, and the value table is stored in the legacy system, not in the data itself. If you fail to extract it, you end up with an archive that is formally complete but functionally unreadable.
The OAIS reference model according to ISO 14721 describes this relationship using three types of packages, and distinguishing between them is helpful in the project. The transfer package contains what comes out of the legacy system. The archival package contains what is permanently preserved, including the descriptive information. The delivery package contains what a user or auditor actually receives later. A project that plans only for the first package produces an archive from which no one will be able to extract anything later.
An archive is not judged by how well the data was entered into it, but by how well it can be retrieved eight years later.
Which data sources in the legacy system are regularly overlooked
Data extraction during legacy system archiving usually focuses on the main database. However, a legacy system rarely stores all its data there. The following sources are most commonly omitted in archiving projects, and any one of them can invalidate the proof of completeness.
Binary data outside the database. Test reports, measurement curves, drawings, and photos are often stored as files in the file system, linked via a path in the database. If only the database is extracted, the archive will contain references to files that no longer exist.
History tables and change logs. Many applications track changes in separate shadow tables. These tables contain the audit trail and thus serve as proof of immutability. They are often overlooked because they do not appear in the user interface.
Master data history. The current supplier address is stored in the master data table. The address that was valid at the time of the 2014 delivery is either stored in a version table or not at all. Without master data history, an old transaction can no longer be reconstructed correctly.
Authorization and user status. Who was authorized to approve an audit in 2016? In the event of a dispute, this question determines the evidentiary value of an approval. The answer is found in the user and role model, which disappears along with the system.
Custom Fields and Clones. Over the years, additional fields, free-text fields with domain-specific meaning, and small add-on applications are created within the same database. They are not described in any vendor documentation and can only be identified by consulting the business departments.
Data on legacy media. Tape archives, old export files, and off-site annual data sets technically belong to the legacy system but are physically stored elsewhere. They go unnoticed when the system is shut down and only resurface during an audit.
PRACTICAL ERRORSThe extraction list is created based on the vendor’s documentation rather than the actual database schema. Evolving systems regularly contain tables that are not mentioned in any official documentation. The basis must always be the schema of the current production instance, verified with the business departments. |
Format Decision: In Which Format Can Legacy Data Remain Verifiable?
There is no legally mandated archiving format for legacy systems. However, there is a legal requirement regarding the result. Section 147(2) of the German Fiscal Code (AO) requires that documents subject to retention obligations be available at any time and machine-readable throughout the entire retention period. The GoBD, as set forth in the BMF letter dated November 28, 2019, specifies this further and adds the requirements of traceability and immutability.
This leads to a stark conclusion about the most popular shortcut: Printing all reports as PDFs ensures availability but fails to provide analyzeability. You cannot filter a PDF collection by a specific attribute, aggregate data across years, or track a batch across multiple tables. This format is suitable for unstructured documents, but for structured data, it’s a drawback.
| Format | Machine-readable | Readable without special software | Preserves the data model | Suitable for |
|---|---|---|---|---|
| Database representation of the original version | only with a compatible database version | No | Yes | Short-term workaround; not for long-term archiving |
| PDF reports | no | yes | No | Unstructured documents and reports |
| Vendor-proprietary archive format | Yes, within the product | No | Yes | Only with contractually guaranteed export |
| Open structured format with schema, OAIS-compliant | Yes | yes | Yes | Structured legacy data from ten years ago and older |
The third line deserves attention because it describes the most common reality. A proprietary archive format is not a problem in and of itself, as long as a documented export to an open format is contractually guaranteed and has been tested in practice at least once. Without this test, you have merely shifted the legacy system’s dependency problem to a new provider. The additional criteria that apply when selecting a product are described in “Audit-Proof Archiving: Choosing the Right Software.”
How to Verify the Completeness of the Archive
This is the section that determines whether an archiving process for legacy systems stands or falls during a tax audit. The question is not whether the transfer was successful, but whether you can prove it. Four types of evidence have proven effective, and they complement each other because each reveals a different class of errors.
| Type of Evidence | Procedure | Detects | Document |
|---|---|---|---|
| Quantity Comparison | Number of records per table in the legacy system compared to the number of records in the archive | Missing tables, aborted extractions, filtered subsets | Reconciliation log with count totals per table and timestamps |
| Total reconciliation | Business-specific totals such as amounts, quantities, and number of measured values | Data records implicitly lost while the total number of records remains the same | Sum log with a deviation of zero or a documented explanation |
| Checksums | Hash value per data record or per packet during extraction and in the archive | Changes to content during transport and reformatting | Checksum list, stored in the archive |
| Technical sampling | The department retrieves defined legacy transactions from the archive and compares them | Loss of meaning, missing value tables, unreadable codes | Random sample report signed by the department |
The fourth line is the one that is most frequently omitted and most urgently needed. Quantity, total, and checksum comparisons are technical verifications. They prove that the bits have arrived. They do not prove that a staff member in the archive can still understand a transaction from 2015. That is exactly what the technical sample check verifies, and that is exactly what an auditor asks.
A practical approach is to take a sample of ten to twenty cases, selected based on case complexity rather than at random: the most complex case, the oldest case, a case with addenda, a canceled transaction, and a case with a file attachment. If these five examples can be traced in the archive, then the simple cases are covered anyway.
All four pieces of evidence should then be stored not on a project drive, but in the archive itself. They are part of the retention policy because, in eight years, they will be the only way to verify completeness. Why a backup cannot fulfill this verification function is explained in the comparison of backup and archiving.
Procedural Documentation for System Decommissioning
The GoBD requires process documentation for tax-relevant processes. In the case of legacy system archiving, this documentation marks the completion of the project and is not merely a byproduct. In the case of a system decommissioning, this documentation is what bridges the gap between the old and new states. Without it, in eight years’ time, the question will arise as to why there is no longer any data in the legacy system at a certain point in time and whether anything has gone missing from it.
It must include at least six pieces of information:
- A description of the decommissioned system, including the version, operational period, and functional scope.
- A definition of the transferred data set, including an explanation of which areas were not transferred and why.
- A description of the extraction and transformation process, including all reformatting.
- The four completeness certificates, including the date and the person responsible.
- Description of archive access: who has access, how they access it, and in what form data is provided.
- Date and approval of the decommissioning, including the names of the decision-makers.
This documentation is created during the project, not afterward. Anyone who writes it retrospectively reconstructs decisions from memory and creates precisely the uncertainty that it is intended to eliminate. The detailed requirements for audit-proof documentation are outlined in the article on GoBD-compliant archiving.
How the archive will be used after decommissioning
Legacy system archiving that produces data no one can use is an expensive data graveyard. The four real-world scenarios for accessing the data vary greatly in terms of timeframes and requirements, and the architecture must meet the needs of all four.
Tax audits. According to Section 147(6) of the German Fiscal Code (AO), the tax authorities may access data in three ways: direct read access to the system, indirect access via reports generated by the company, or the provision of data on a storage medium. For decommissioned systems, the third form is the one that is practically relevant. The archive must therefore provide a structured export with a documented schema, not just a screen mask.
The complaint. Speed is of the essence here. What matters is the scope in question: which batches, which time period, and which audit results. An archive that can only display individual transactions but does not allow for volume queries spanning multiple years fails to meet this requirement.
The request for information under Article 15 of the GDPR. According to Article 12(3) of the GDPR, the deadline is one month. Being able to provide information means being able to locate all data records pertaining to a specific individual across the entire historical data set. To do this, the archive requires a personalized search path, which must be created at the time of data transfer.
Technical research. A design engineer is searching for the process parameters of a component that has not been manufactured since 2018. This scenario is the most common and the least well-planned because it is not compliance-driven. Appropriate role models are described in the article “Archive Access Without an IT Ticket.”
What Happens to Personal Data in Legacy Systems
Before an legacy system in manufacturing is archived, it contains more personally identifiable information than the system description suggests: operator IDs in machine logs, inspector codes on approvals, user accounts with real names, contact persons in supplier data, and timestamps with shift assignments.
Before archiving the legacy system, two questions therefore arise in this order. The first: Which part of the legacy data needs to be transferred at all? According to Article 5(1)(e) of the GDPR, storage must be limited to what is necessary. Data whose retention period expired in 2019 does not belong in a new archive but must be deleted. This retention period review is also the most effective way to reduce the archive’s volume.
The second question concerns the data records that must be retained: How is the personal reference handled if the retention obligation extends beyond the duration of the processing purpose? The practical approach is to anonymize individual fields within records that are retained, so that the transaction remains complete for product liability and tax law purposes, while the association with specific individuals is removed. This requires an archive with a domain-specific data model, as this operation is not possible at the file level. The structural framework for this is described in the deletion policy for production facilities, and the corresponding retention periods are outlined in the overview of statutory retention obligations.
A note on the order: Both steps must be completed before data is transferred to the archive. After archiving, the retention period review is a separate project, and pseudonymizing a collection that has already been sealed is significantly more time-consuming than pseudonymizing one that is still in active use.
Where Legacy System Archiving Fails in Practice
| Common Issue | Early Warning Sign | Consequence |
|---|---|---|
| Archive without a data model | The extraction list contains tables, but no value tables and no field descriptions | Data exists but cannot be interpreted in a business context |
| The legacy system remains active as a fallback option | The decommissioning is postponed by one quarter following archiving | Costs and risks continue to accrue; the project goal will not be achieved |
| Completeness is verified only technically | There are meter readings, but no report from a business unit | In the event of an audit, there is no evidence of functional usability |
| New dependency on a specific vendor | The target format is proprietary, and exporting has never been tested | The dependency issue has been postponed, not resolved |
| Expired records were also imported | There is no validity check prior to extraction | Archive volume and GDPR risk are unnecessarily increased |
The second type of error is the most costly in legacy system archiving because it occurs unnoticed. Archiving is complete, the verification documents are available, and yet the legacy system remains online because no one takes responsibility for shutting it down. An effective countermeasure is one that is included in the project plan: a fixed decommissioning date linked to the acceptance of the completeness documentation, and a designated person who approves it. The article on decommissioning legacy systems in manufacturing describes how this approval is integrated into the decommissioning process.
The economic aspects of continued operation—particularly the licensing costs for dormant database instances—are broken down in the article on database licenses and IT costs in the manufacturing industry.
How the Manufacturing OS Implements Legacy System Archiving
CSP’s Manufacturing OS combines process data management, operator guidance, inspection, and audit-compliant archiving in a single platform. The CHRONOS archiving component serves as the backbone for legacy system archiving.
With regard to the requirements for legacy system archiving described here, it addresses the areas where simple storage is insufficient. Data is transferred across databases and is vendor-neutral, allowing even end-of-life database versions to serve as sources. The source’s data model is also transferred, ensuring that field meanings and relationships are preserved in the archive. Archiving takes place in an open, documented format based on the OAIS reference model, meaning that machine-readability in accordance with Section 147(2) of the German Fiscal Code (AO) does not depend on the availability of specific software. Retention periods are managed on a per-data-class basis, and individual records can be selectively deleted or anonymized in specific fields without affecting the rest of the collection.
A practical example from the medical technology sector describes the success story of securing application data at the KLS Martin Group. The article on Application Retirement addresses the broader context of system decommissioning.
An honest assessment is essential: Defining the data set, assigning retention periods, and selecting a representative sample remain the company’s responsibility. Software can handle the transfer and generate the necessary documentation, but it cannot determine which data set is complete from a business perspective. Details about the archiving component can be found on the page about audit-compliant data archiving with CHRONOS.
A Seven-Step Process
| Step | Content | Result |
|---|---|---|
| 1 | Collect data from the current schema, not from the manufacturer’s documentation, and verify it with the subject-matter experts | Complete list of sources, including files, histories, and legacy media |
| 2 | Assign retention periods to each data class and weed out expired records | Reduced scope of data transfer with documented justification |
| 3 | Determine whether data is personally identifiable and decide on anonymization or separate classification | GDPR classification of the scope of data transfer |
| 4 | Specify the target format and conduct a practical test of the re-export process | Demonstrated independence from the archive provider |
| 5 | Perform the import and generate all four completeness reports | Reconciliation, total, checksum, and sample logs |
| 6 | Finalize the procedural documentation and have it approved | Audit-proof documentation for tax audits and regulatory oversight |
| 7 | Perform and document the shutdown on the specified date | Legacy system taken offline; license and maintenance costs eliminated |
Steps two and three are often planned together with the data transfer during legacy system archiving, but they are misplaced in that context. Both steps reduce the scope, and any reduction prior to extraction simultaneously lowers effort, volume, and risk. Those who transfer data first and then filter it out end up doing the work twice.
Step four is often treated as a formality. It is the only point in the process that prevents a new vendor lock-in from replacing the original one at the end of a project.
Conclusion
Legacy system archiving is not a storage problem, but a documentation problem. Extracting data from a legacy system is the technically easier part. Being able to prove that the data is complete, unaltered, and business-understandable is the factor that determines whether the system is decommissioned.
The two conditions for reliable legacy system archiving can be summarized in a single sentence. The archive must be analyzable without the original software, and its completeness must be verified both technically and in terms of business content. If both conditions are met, decommissioning is a done deal. If either is missing, it remains a risk, and the legacy system continues to run.
The most important single step in legacy system archiving is therefore not the extraction, but the business-critical sample check. It is the only proof that answers the question that will truly be asked in eight years: Will a person be able to find the transaction they are looking for in this archive?
Frequently Asked Questions
What is legacy system archiving?
Legacy system archiving is the structured transfer of data from an application being phased out into an audit-proof archive that keeps the data readable, analyzable, and verifiable, independent of the original software. The goal is not to back up a system state, but to ensure the long-term availability of business content beyond the statutory retention period. The difference from migration is that the data is not transferred to a successor system, but rather converted into a system-neutral archive format.
What is the difference between legacy system archiving and a backup?
A backup preserves a system state so that it can be restored in the event of a failure. It is tied to the software, the database version, and, in some cases, the hardware, and is overwritten after its retention cycle expires. Legacy system archiving converts business content into a system-independent format with its own data model, metadata, and logs. A backup of a decommissioned application is practically unusable after a few years because the associated runtime environment is missing.
Can I decommission a legacy system after archiving it?
Yes, provided that the archive is verifiably complete and its analyzability is ensured without the original software. Both must be documented: completeness through a documented comparison of record counts and checksums, and analyzability through a practical access test on the archive. Only with these two forms of evidence and the corresponding procedural documentation is decommissioning justifiable in the event of a tax audit.
In what format must archived historical data be stored?
There is no legally prescribed format. However, Section 147(2) of the German Fiscal Code (AO) requires that the documents be available at all times and machine-readable throughout the entire retention period. A simple collection of PDF files meets the availability requirement but fails to meet the machine-readability requirement, because structured data can no longer be filtered, sorted, or linked from them. Practical solutions include open, documented structured formats that preserve the data model, based on the OAIS reference model according to ISO 14721.
What access rights does the tax authority have to an archive?
According to Section 147(6) of the German Fiscal Code (AO), the tax authorities may access tax-relevant data in three ways: direct read access to the system, indirect access via reports generated by the company, or the provision of data on a data carrier. In practice, the third option is the relevant one for decommissioned systems. The archive must therefore be able to provide a structured data export with a documented schema, not just a screen view.
Must personal data be deleted from an old database?
Yes, as soon as the purpose of processing no longer applies and there is no retention obligation to the contrary. According to Article 5(1)(e) of the GDPR, storage is limited to what is necessary. A legacy database often contains data records whose retention period has long since expired. It is therefore worth checking retention periods before archiving, because transferring data that is no longer needed to a new archive prolongs an existing risk rather than eliminating it. Where retention and deletion obligations apply to the same data record, anonymizing individual fields is the solution.
How long must an archive from a decommissioned system be retained?
The duration depends not on the system, but on the content. For trading ledgers and accounting documents, a ten-year retention period applies pursuant to Section 257(4) of the German Commercial Code (HGB) and Section 147(3) of the German Fiscal Code (AO). VDA Volume 1 recommends a 15-year retention period for documentation related to products with special characteristics. The liability period under the EU Product Liability Directive (EU) 2024/2853 may exceed this. The longest retention period applicable to any of the data sets contained therein is always decisive.
