In almost every manufacturing company, there’s a system that nobody needs anymore and nobody is allowed to shut down. From a technical standpoint, it no longer serves any purpose. The processes have long since been migrated elsewhere. Yet IT renews the database license every year, the server still sits in the rack, and everything still depends on the one colleague who still understands how it works—and who is set to retire in two years. The reason it’s still running is rarely technical. It’s the fear of no longer being able to access one’s own data. This very fear can be resolved, and those who resolve it not only save money but also regain the ability to provide information—which is what counts during an audit.
THE MOST IMPORTANT POINTS AT A GLANCE
|
What Is a Legacy System?
A legacy system is an outdated software application that remains in production use even though its technology, maintenance model, or integration capabilities are no longer up to current standards. The term does not describe a point in time, but rather a relationship: business-critical importance on the one hand, and limited maintainability on the other.
That is why age as a criterion is misleading. A twenty-year-old system that is well-maintained, has documented interfaces, and is supported by the manufacturer is not a legacy system. A five-year-old system without support, without integration capabilities, and with exactly one person in the company who understands it may already be one.
In manufacturing, this typically applies to four categories:
- Process databases that have grown over the years and store measurement values in proprietary structures
- older MES and CAQ applications running on database platforms that are no longer supported
- proprietary machine control and data acquisition systems from individual equipment manufacturers
- in-house developed siloed solutions whose developers have long since left the company
These legacy systems almost always contain precisely the data that must remain available in the long term for compliance reasons. And they continue to be operated for that reason alone. This is the core of the problem and, at the same time, the starting point for the solution.
The 6 Warning Signs That an Legacy System Is Ready to Be Replaced
Not every legacy system needs to be replaced. The key factor is whether multiple warning signs are present. A single sign is not a reason to take action, but three or more are. This combination almost always indicates how a legacy system gradually becomes a cost driver, and is described in detail in a separate article.
- No more vendor support. Security updates and bug fixes are no longer provided, and the system remains frozen at its last updated version.
- Dependence on specific individuals. Only one or two employees still understand the system. When they leave, that knowledge is irretrievably lost.
- Expensive specialized licenses. Database or runtime licenses incur high annual costs without providing any new value.
- Lack of interfaces. The system cannot be integrated with ERP, MES, or modern analytics tools—or can only be integrated via workarounds.
- Unpatched security vulnerabilities. Known vulnerabilities remain unaddressed because the manufacturer no longer provides support.
- Data transfer issues. Data must be manually transferred, exported, or retyped, which increases the risk of errors and adds to the workload.
These warning signs reinforce one another. A lack of support leads to security vulnerabilities; security vulnerabilities lead to the system’s isolation within the network; isolation leads to data discontinuities; and data discontinuities tie up staff resources. Anyone who waits to act until all six points apply has already missed the most cost-effective options for action.
Why legacy systems continue to run even though they no longer serve any functional purpose
The most common scenario is not an actively used legacy system, but rather read-only operation: processes run in the new system, while the old one remains online because it contains the historical data. Two obstacles keep this state in place for a legacy system.
The visible obstacle is the migration risk. A data migration seems dangerous. The concern about damaging or losing data during the process leads to the easier decision to simply let the system keep running. This decision is never made; it is simply not made year after year.
The invisible obstacle is the compliance aspect. When a regulatory or audit request comes in, the search begins in legacy systems, exported data, and spreadsheets. In practice, this is a research task that takes anywhere from days to weeks. What appeared on paper to be a fulfilled retention obligation turns into an expensive special project when the time comes. The legacy system, therefore, does not actually provide the ability to disclose information; it merely simulates it.
Added to this is a structural reason: The timing for decommissioning is never right. There’s always an ongoing project, an upcoming audit, or a personnel change. The result is that the system runs for another five years while the problem grows. The 5-step plan for decommissioning legacy systems in manufacturing describes how to make this decision in a structured way.
What a Legacy System Really Costs
The visible costs of a legacy system are only part of the equation—and usually the smaller part. Far more significant are the expenses that don’t appear on any license invoice and therefore don’t come up in any budget discussions.
| Cost Type | Visibility | Specific Example |
|---|---|---|
| License and maintenance fees | Visible | Annual database and support contracts, even with minimal usage |
| Infrastructure operating costs | Visible | Servers, storage, and backup for a rarely used system |
| Dedicated IT staff | hidden | Specialized knowledge that cannot be repurposed for further development |
| Integration effort | hidden | Manual data transfer between the old and new systems |
| Time spent on research during audits | hidden | Days to weeks per regulatory or audit request |
| Opportunity costs | hidden | Stalled modernization, delayed cloud and ERP projects |
| Risk costs | hidden | Potential outages, compliance violations, data loss |
| Knowledge risk | Hidden | Rising market prices for expertise in obsolete technologies |
The biggest single lever: database licenses
Many legacy applications rely on licensed databases, the costs of which continue to accrue even after the system is no longer functionally operational. The key point: A highly available production database is not required simply for the storage of data subject to retention requirements. Once the data is transferred to an audit-compliant archive, there is no longer any need to continue operating the original database and its associated 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.
PUTTING THE NUMBERS INTO PERSPECTIVEThere are no reliable industry averages for legacy operating costs because system landscapes vary too widely. The only reliable figure is your own calculation: license costs, infrastructure costs, and person-days per year for a system that no longer performs any business functions. In CSP’s project experience, the database license cost is almost always the largest expense—and at the same time, the one that can be reduced the fastest. |
What risks does continued operation pose?
Continuing to operate a legacy system gives rise to three categories of risk that reinforce one another.
Maintenance risks arise because spare parts, technical expertise, and manufacturer support are no longer available. A failure can then no longer be repaired in a planned manner, but becomes an open-ended project of unknown duration.
Security risks arise because unpatched systems are vulnerable and usually no longer fit into modern security strategies. The common response to this is network segmentation—that is, isolation. This reduces the risk of attack but simultaneously increases the number of media breaks.
Compliance risks arise because it becomes increasingly difficult to meet documentation requirements with an unstable, barely usable system. This aspect is the most severely underestimated. When an auditor wants to see a product’s complete history and the system that stores this data can only be operated by a single person, a technical problem becomes a regulatory one.
The difference from other IT risks lies in the temporal behavior. The risk posed by a legacy system does not decrease by waiting, nor does it remain constant. It grows steadily because support, expertise, and spare parts availability are moving in only one direction.
Replace, migrate, or archive? A comparison of the three approaches
There are three basic approaches to dealing with a legacy system. Which one is appropriate depends on a single question: Is the business functionality still needed, or is it only the data? The decision is made not on a per-system basis, but on a per-data-domain basis. In practice, two approaches are often used in parallel within a single project.
| Approach | When Appropriate | Result | Typical Effort |
|---|---|---|---|
| Migration to a new system | Functions and data are still actively needed | The legacy system is completely replaced; processes run in the new system | High |
| Data migration and decommissioning | Function is discontinued; current data is still needed | Relevant data is migrated to the target system; the legacy system is decommissioned | medium |
| Audit-compliant archiving | Only the retention requirement remains in effect | Data is archived with secure access control; the application is decommissioned | low |
The most common planning mistake when replacing a legacy system is the assumption that the first approach must always be the right one. A complete migration of historical data to a new ERP or MES system is expensive, prolongs the project, and creates a data set in the target system that no one there needs. If the requirement is that data must be retained and remain retrievable, the third approach is the most cost-effective and technically sound.
Why a Backup Is Not a Replacement
Many companies believe the problem is solved as soon as a backup is in place. This is the most common—and most costly—mistake when replacing legacy systems.
A backup safeguards a system. Archiving safeguards information. The difference becomes relevant the moment the original application no longer exists: The database backup is still there, but without the application logic that interprets field names and resolves relationships, it can no longer be analyzed. The data technically exists but is practically unusable.
| Criterion | Backup | Audit-proof archiving |
|---|---|---|
| Purpose | System recovery | Long-term availability of information |
| Design | Disaster recovery | Retention and Disclosure Requirements |
| Format | Mostly proprietary and system-specific | Long-term readability, system-independent |
| Immutability | Not guaranteed | Guaranteed and logged |
| Access in the event of an audit | only by restoring the system | Targeted query of individual transactions |
| Time frame | Short- to medium-term | Years to decades |
Our article comparing backup and archiving goes into detail on the distinction between the two. When it comes to phasing out a system, only one thing matters: A backup doesn’t make it possible to shut down a legacy system. It simply makes shutting it down less risky.
Application Retirement: Decommissioning in 6 Steps
Application retirement refers to the orderly decommissioning of an application whose data must continue to be retained and remain accessible. The order of the steps is not arbitrary. Skipping a step risks data loss or unplanned additional costs.
- Assessment. What data, functions, and interfaces are available, and which of these are actually still needed? The result is a list organized by data category, not by system.
- Clarify retention requirements. Which data must remain available, for how long, and in what format? This step determines the scope of the entire project.
- Define the target scenario. Migration, data transfer, or archiving—decide separately for each data area.
- Prepare for data transfer. Define the structure, formats, and validation rules so that completeness can be verified later rather than merely claimed.
- Implementation and verification. Transfer or archive the data, then verify completeness and readability and document the results.
- Decommissioning. Only after all data has been backed up and verified should the legacy system be decommissioned and the license terminated.
THE REAL MILESTONEThe critical point is not Step 5, but the acceptance process involved in it. A data migration is only considered successful once its completeness and readability have been verified and documented against defined validation rules. Without this protocol, the system shutdown remains a matter of trust, and in companies, matters of trust are decided in favor of continuing operations. |
What Happens to Legacy Data: Retain, Delete, and Document
The crux of the matter when replacing a legacy system is the data. Three obligations apply to the same dataset: Certain data must be retained, other data must be deleted by a specified deadline, and in the event of a dispute, you must be able to prove both.
The retention periods are not derived from a single uniform archiving law, but from several areas of law simultaneously. Section 147 of the German Fiscal Code (AO) requires tax-relevant records to be retained for ten years, while the GoBD standards mandate machine-readable format throughout the entire retention period. For quality-related product data in the automotive sector, retention periods of 15 years or longer are common in customer agreements. The GDPR follows the opposite logic and prescribes maximum retention periods with an active obligation to delete data. Our article on retention periods under the German Commercial Code (HGB), the GDPR, and the GoBD provides a comprehensive overview by standard and data category.
This results in a practical requirement for data retention that many archiving concepts do not meet: The data must be both unalterable and selectively deletable. It must be unalterable to ensure the evidence remains valid, and selectively deletable so that personal data can be removed within the prescribed timeframe without compromising the remaining evidence. Our article on selecting audit-proof archiving discusses the criteria that software must meet for this purpose. The requirements from the perspective of the tax authorities are summarized in the article on GoBD-compliant archiving.
COMMON MISTAKESThe legacy system continues to operate as a precaution because no one wants to take responsibility for shutting it down. As a result, every cost item is extended indefinitely, while the actual goal—the long-term availability and verifiability of the data—could be achieved more cost-effectively and securely through archiving. |
How the Manufacturing OS Is Replacing Legacy Systems
CSP’s Manufacturing OS is the platform that enables manufacturing companies to manage process data, quality assurance, operator guidance, and audit-traceable archiving on a single, unified data foundation. Two components are crucial for replacing a legacy system because they separate the two types of data that are intermingled in the legacy system.
| Component | Handles | Result |
|---|---|---|
| IPM Process Data Management | active process and quality data | The business functionality of the legacy system continues to run in a structure that can be integrated |
| CHRONOS Archiving | Historical data subject only to retention requirements | Data remains retainable, can be deleted in a timely manner, and is verifiable without the legacy system |
The practical benefit lies in decoupling: Historical information is no longer dependent on the operation of an old application. Business units can access archived data without an IT ticket, and decommissioning the legacy system shifts from a matter of trust to a project decision. Technical details regarding the archiving aspect are provided in the article on future-proof database archiving with CHRONOS. Companies such as the BMW Group, Mercedes-Benz, MAN Truck & Bus, Knorr-Bremse, and Stadler Rail use CSP solutions in their quality assurance processes.
SELF-CHECK: CAN YOUR LEGACY SYSTEM BE SHUT DOWN?
|
The more issues remain unresolved, the greater the likelihood that the legacy system will continue to run into the next fiscal year. These unresolved issues also serve as the to-do list: They describe exactly steps 1 through 4 from the section on application retirement.
Frequently Asked Questions
What is a legacy system?
A legacy system is an outdated but still business-critical software application that can only be maintained, further developed, or integrated at great expense. The key factor is not the age of the system, but the balance between its importance and the limitations on its maintainability. In manufacturing, this typically applies to process databases, older MES or CAQ applications, proprietary machine data acquisition systems, and in-house developed siloed solutions.
How can you identify a legacy system?
By a combination of several warning signs: lack of manufacturer support, dependence on specific individuals, expensive specialized licenses, missing interfaces, unpatched security vulnerabilities, and data inconsistencies with other systems. A single warning sign is not a reason to take action, but three or more are.
How can a legacy system be replaced?
In six steps: Inventory of data, functions, and interfaces; clarification of retention requirements; definition of the target state for each data area; preparation of the data migration with defined structures and validation rules; implementation with verification of completeness and readability; and final decommissioning once all data has been verified and secured.
Can existing legacy systems be migrated, or do you have to start from scratch?
Both are possible; a complete restart is rarely necessary. If the business functionality is still needed, migration makes sense. If only retention is required, a data transfer followed by decommissioning—or audit-proof archiving of the legacy data upon application shutdown—is sufficient.
How can you reduce the operating costs of a legacy system?
The most effective way is to shut down the system. If the data subject to retention requirements is transferred to an audit-compliant archive, the license, maintenance, and infrastructure costs of the legacy system are eliminated. For long-term retention alone, there is no need for a highly available, licensed production database. Based on CSP’s project experience, database licenses usually represent the single greatest cost driver.
How can data be migrated from a legacy system without loss?
Through a prepared data migration with defined structures, formats, and validation rules. Completeness and readability are verified and logged after the migration before the legacy system is decommissioned. Acceptance is the actual milestone, not the extraction.
Is a backup sufficient to secure legacy data in the long term?
No. A backup is intended for the technical restoration of a system and is tied to that system’s structure and format. Without the original application, the information often can no longer be interpreted. To meet retention requirements and audit requests, an archiving solution is needed that keeps data readable, searchable, and analyzable independently of the source system.
What happens to the legacy data after the system is replaced?
Data subject to retention requirements is archived in an audit-proof manner so that it can be retained, deleted in a timely manner, and verified at any time. Data not subject to retention requirements is removed according to a documented deletion policy. The legacy system itself does not need to remain operational for this purpose.
How long does a legacy system replacement take?
That depends on the volume of data, the complexity of the system, and the chosen approach. Simple archiving followed by system shutdown is significantly faster than a complete migration. In practice, the timeline is determined primarily by the inventory process and the clarification of retention requirements, not by the technical extraction itself.
