A system that no one needs anymore, but no one is allowed to shut down. It no longer serves any practical purpose, yet year after year it consumes licenses, maintenance costs, and the expertise of the few people who still know how to use it. The reason it keeps running is rarely because it’s useful. It’s the fear of no longer being able to access one’s data.
Replacing a legacy system means overcoming precisely this obstacle: shutting down the application without losing access to the data subject to retention requirements. This is possible, and it significantly reduces costs.
This guide explains why legacy systems remain in operation, what they really cost, and how you can safely decommission a legacy system step by step without jeopardizing your compliance.
KEY POINTS AT A GLANCE
|
IN A NUTSHELLMany manufacturing companies continue to operate legacy systems even though they are technically obsolete. The reason: Their data is subject to retention requirements, and no one wants to risk data loss. The result is high ongoing costs for licenses, maintenance, databases, and scarce specialized knowledge. The solution is application retirement: The legacy system’s data is archived in an audit-proof, unalterable, and open format, after which the application is shut down. Because the retention requirement applies to the content and not to the software, compliance is maintained while the costs are eliminated. CHRONOS in the CSP Manufacturing OS is designed specifically for this task. |
Replacing a legacy system means taking a functionally obsolete application out of service without losing access to its data. The technical term for this is “application retirement”: the orderly decommissioning of an application whose data must continue to be stored and remain accessible.
A legacy system is more than just old software. It is an application that has largely lost its business purpose but cannot be shut down because its data is still needed or must be retained. Typical examples include decommissioned ERP modules, outdated business processes, or legacy systems following a merger.
The key to phasing out a system is separating the application from its content. As long as the two are viewed as a single unit, shutting down the system seems impossible. However, once the data is backed up independently of the application, the software can be shut down while the data is preserved. We explore why you shouldn’t rely solely on the old database in our article explaining why we prefer not to blindly trust a live database.
| Key Metric | Value |
|---|---|
| Percentage of historical data in production databases | a large portion |
| Annual costs for five to ten legacy systems still in operation | in the seven-digit range |
| Legal retention periods | 6 to 10 years, sometimes longer |
| Search time per audit from legacy systems | Days to weeks |
When a legacy system has reached the end of its useful life, one would think it would simply be shut down. In practice, this rarely happens. Three reasons keep legacy systems alive, even though they have long since cost more than they are worth.
The first and most important reason is the legal obligation to retain data. The system’s data is subject to statutory retention periods. For documents relevant under tax and commercial law, Section 147 of the German Fiscal Code (AO) and Section 257 of the German Commercial Code (HGB) stipulate retention periods of 6, 8, or 10 years, depending on the type of document; in certain industries and product liability cases, these periods can be significantly longer. Throughout the entire period, the data must remain retrievable, readable, and verifiable. As long as no one knows of an alternative, the legacy system remains in operation as a data repository.
The second reason is the fear of data loss. Migration seems risky, and the concern about damaging or losing data in the process often leads to the more convenient decision to simply let the system continue running. However, this seemingly safe inaction comes at a high cost.
The third reason is a lack of knowledge about alternatives. Many people are unaware that the data can be archived in an audit-proof manner and the application subsequently shut down. This very option is at the heart of application retirement.
Doing nothing feels safe because it eliminates the risk of migration. But a legacy system that runs solely as a data repository is not a safe decision—it’s an expensive one.
The costs of a legacy system are higher than they appear at first glance because they consist of several components. Based on our client projects, we can provide typical cost ranges.
The most visible component is direct operating costs. Based on our project experience, continuing to operate a legacy business process or ERP module that is slated for replacement can quickly cost between 50,000 and 200,000 euros per year—and for a large mainframe inventory management system, the cost can be many times that amount. If several legacy systems are now functioning solely as data repositories, the total cost can quickly reach the seven-figure range per year.
The invisible component is the compliance aspect. When a regulatory or audit request comes in, the search begins in legacy systems, exports, and spreadsheets—in practice, a research task that can take days or even weeks. What looked like a fulfilled retention obligation on paper turns into an expensive project when the time comes.
Added to this is a cost factor that grows over time: specialized knowledge. Anyone operating a legacy system needs people who still understand it. This knowledge becomes scarcer and more expensive with each passing year. We describe how a legacy system can become the most expensive employee in a separate article.
| Item | Annual Cost Range |
|---|---|
| Legacy business process or ERP module to be phased out but kept in operation | 50,000 to 200,000 euros |
| Mainframe inventory management system at an insurance company | 1 to 5 million euros |
| Five to ten legacy systems serving solely as data repositories | seven-digit range |
| Search per audit or information request | Days to weeks of effort |
Database licenses are an often-underestimated cost driver in legacy systems. Many legacy applications rely on licensed databases, the costs of which continue to accrue even after the system has ceased to function for business purposes.
The point is: You don’t need an expensive, high-availability production database just to store data that must be retained. Once the data is transferred to an audit-compliant archive, there is no longer any need to continue operating the original database and its licenses. A running, licensed production system is transformed into a dormant, cost-effectively archived dataset. Our article on this topic details just how much database licenses drive up IT costs in manufacturing.
This is precisely where the approach comes in: no longer requiring an expensive database license for long-term retention. The archived data is stored in an open, long-term-secure format, not in a proprietary, license-required environment. This not only reduces costs but also eliminates dependence on a single database vendor. Our overview of the Manufacturing OS without Oracle details the specific benefits this brings.
Replacing a legacy system follows a clear process. By adhering to this process, you minimize risk and ensure that no data subject to retention requirements is lost.
Step 1: Inventory. First, you must identify what data is stored in the legacy system, what retention periods apply to it, and who still needs it. Without this clarity, the replacement cannot be justified.
Step 2: Data classification. Not all data is the same. A distinction must be made between data subject to retention requirements, data that may be deleted, and data still needed for ongoing operations. This classification forms the basis for all subsequent steps.
Step 3: Audit-proof archiving. Data subject to retention requirements is archived in an unalterable, open format that complies with GoBD and OAIS standards. Only once the data has been verifiably and completely secured in a readable format can the next step proceed.
Step 4: Decommissioning. Once the data set has been secured and access to it has been tested, the legacy application can be decommissioned. License, maintenance, and operating costs cease at this point. Our article on traceability in production discusses how such a chain of evidence can be permanently documented.
The entire approach stands or falls on the quality of the archiving. A simple data backup is not sufficient, as it can be overwritten and is not designed for long-term verifiability. To replace a system subject to retention requirements, audit-proof archiving is needed that meets three criteria.
First, immutability. The archived data must be stored in such a way that subsequent changes are either impossible or are fully logged. Only then can the data serve as reliable evidence.
Second, an open, long-term-stable format. With retention periods spanning decades, the data must remain readable even after the original system and its software have long since disappeared. A proprietary format tied to a specific application would pose a risk in this context. The OAIS standard for long-term archiving addresses precisely this issue.
Third, compliance. Archiving that complies with both GoBD and OAIS ensures that the collection is not only technically preserved but also legally sound. The central principle stems from retention law itself: The obligation applies to the content, not to the application in which it was created. Section 147 of the German Fiscal Code (AO) requires that data be made readable at any time throughout the entire retention period, regardless of the original system. This is precisely what makes the transition possible in the first place.
Replacing a legacy system pays off on multiple levels, which together make for a clear business case.
First, operating costs decrease. License, maintenance, database, and operating costs for the legacy system are eliminated. Based on our project experience, when multiple systems are replaced, these savings quickly add up to a seven-figure amount per year.
Second, IT performance improves. When historical data is migrated out of production databases, it significantly reduces the load on the remaining systems. An article on database archiving demonstrates how this can significantly boost IT performance.
Third, compliance becomes easier. Instead of having to gather data from legacy systems during an audit, the evidence is available in a central, searchable archive. A search task that used to take days can now be completed in seconds.
Fourth, you gain independence. The archived data is stored in an open format and is no longer tied to a specific database or software vendor. This eliminates dependencies and provides freedom of action—for example, during a cloud migration, as our article on selective archiving during cloud migration demonstrates.
Replacing a legacy system is easy to plan, but certain mistakes keep cropping up in practice. Knowing what they are can save you from costly detours.
Shutting down without verified access. The most common mistake is shutting down a legacy system before access to the archive has been thoroughly tested. The application should only be taken offline once it has been verified that the archived data is complete, readable, and verifiable. Otherwise, the migration will result in data loss.
Confusing backup with archiving. A backup protects against data loss, but it can be overwritten and is not audit-proof. Anyone looking to replace a legacy system needs true, unalterable archiving—not a backup. This confusion regularly leads to gaps in evidence during an audit.
Overlooking deletion requirements. System replacement is not just about retention. Personal data is also subject to deletion requirements. A proper system replacement clarifies for each dataset what must be retained and what must be deleted, rather than retaining everything across the board.
Starting too late. If you don’t start thinking about system replacement until an audit is underway, you’ve chosen the wrong time. Replacing a legacy system should be planned in advance, not done under the pressure of an ongoing regulatory inquiry. The best time is before the costs and risks escalate.
With its CHRONOS module, CSP’s Manufacturing OS is specifically designed to safely replace legacy systems. CHRONOS is designed for application retirement and database archiving: It identifies the data subject to retention requirements, converts it into an open, long-term-stable format, and stores it in an audit-compliant manner, allowing the legacy application to be decommissioned.
Archiving is performed in compliance with GoBD and OAIS standards; the data remains unalterable and readable over the long term, even after the original system is decommissioned. Because the data is no longer stored in a proprietary, license-based database, ongoing database license fees are eliminated, and dependence on a single provider is eliminated.
Practical experience from CSP client projects demonstrates how effective this approach is. During the insolvency proceedings for Anton Schlecker, seven legacy systems were decommissioned without any data loss, while access for courts, government agencies, and social security providers was permanently maintained. Following a merger, the KLS Martin Group centrally consolidated several legacy ERP systems, thereby significantly reducing storage and licensing costs. A separate case study describes how the KLS Martin Group relied on CHRONOS in this process. At an automotive manufacturer, millions of data records are archived on a monthly basis in an audit-compliant manner, while traceability in accordance with IATF 16949 is maintained.
Replacing a legacy system means taking a functionally obsolete application out of service without losing access to its data. The technical term for this is “application retirement.” The data is archived in an audit-compliant manner, independent of the application, so that the software can be shut down while the data remains intact.
The most common reason is the legal obligation to retain data: The data must be preserved for the duration required by law. Added to this are fears of data loss during migration and a lack of knowledge about alternatives. Many people are unaware that the data can be archived and the application subsequently decommissioned.
Yes. The retention requirement applies to the content, not to the application in which it was created. If the data is archived in an audit-proof, tamper-proof manner and in an open format, the legacy system can be decommissioned without violating compliance requirements.
Based on CSP’s project experience, the annual cost for a business process or ERP module being phased out can quickly range from 50,000 to 200,000 euros; for a large mainframe inventory management system, the cost is many times that amount. With multiple legacy systems still in operation, these costs add up to seven-figure amounts, not to mention the expenses associated with compliance research and the scarcity of specialized expertise.
No. An expensive production database is not required for long-term storage alone. If the data is migrated to an open, long-term-proof archive format, the ongoing database licenses are no longer needed, and dependence on a specific database vendor is eliminated.
In four steps: taking inventory of the data and its retention periods; classifying it into “subject to retention,” “deletable,” and “actively needed”; audit-proof archiving of the data subject to retention; and finally, decommissioning the legacy application once access to the archive has been tested.
Application retirement is the orderly decommissioning of an application whose data must continue to be retained. Instead of continuing to operate the system as a data repository, its data is archived in an audit-proof manner, and the application is then decommissioned. This reduces costs and ensures compliance.
Yes. That is the purpose of audit-proof archiving. The data remains searchable, readable, and verifiable in an open, long-term-stable format, even years or decades after the original system has been shut down. Access is provided through the archive, no longer through the legacy application.