The system has been running for 14 years. The manufacturer has discontinued support. The last update came in 2019. The data in it is indispensable - 15 years of process history, test results, batch protocols. And yet: no one dares to switch it off.
Legacy systems in production are one of the most underestimated sources of risk in German SMEs. Not because the systems are bad - many are stable and reliable. But because switching them off is considered impossible: too risky, too expensive, too unknown. So the old system remains running, alongside the new one, alongside the successor to the successor, until the IT architecture resembles a patchwork quilt that no one fully understands.
This guide shows how to safely decommission the legacy system in production - with a structured 5-step plan that prevents data loss, maintains compliance and does not interrupt operations.
THE MOST IMPORTANT POINTS IN BRIEF
|
BRIEFLY SUMMARIZED
|
The term 'legacy system' does not describe a specific software or a specific age - it describes a condition. A system is a legacy system if it is no longer being actively developed, if the manufacturer no longer provides support or if the further development of the system can no longer keep pace with the company's requirements.
In manufacturing, this often applies to three system categories: older MES systems (Manufacturing Execution Systems), proprietary machine control and data acquisition systems and legacy QMS installations (quality management systems) that run on database platforms that are no longer supported.
|
Risk level |
Legacy signal |
Consequence |
Recommendation |
|---|---|---|---|
|
Critical |
No more manufacturer support, operating system end-of-life, no security patches for over 12 months |
Active security risk: every network connection is a potential attack vector |
Initiate shutdown plan immediately. Transition period maximum 6 months. |
|
High |
Support expired, but basic updates still available. No integration into modern systems possible. |
Isolated operation, rising operating costs, increasing interface problems |
Initiate shutdown plan within 12 months |
|
Medium |
Manufacturer still active, but system at the end of its lifecycle. Replacement system already defined. |
Growing operational complexity, knowledge concentration on a few people |
Plan and initiate migration |
|
Low |
System functional, manufacturer active, but strategically no longer future-proof |
No immediate risk, but on a long-term shutdown path |
Include in investment planning, evaluate successor |
Important: The risk class determines the urgency - not the age of the system. A 20-year-old system with active manufacturer support is less risky than a 5-year-old system running on Windows Server 2012.
In practice, there is always the same reason why legacy systems are not shut down in production: Nobody knows exactly what's in them. And as long as you don't know, you don't switch anything off. That's understandable - but it's a decision with growing consequences.
|
Reason |
What's behind it |
The reality |
|---|---|---|
|
'We need the historical data. |
Genuine requirement - but the data can be archived. The system does not need to be running for this. |
Archive data ≠ Keep the system running. Archived data is often more accessible than data in a legacy system. |
|
'It's stable, we won't touch it'. |
Operational stability is not an advantage if security vulnerabilities are not patched. |
A stable system without security updates is not a stable system - it's a silent risk. |
|
'We don't have time for a migration. |
Migration is costly - but uncontrolled continued operation is more expensive in the long term. |
Each year of continued operation of an end-of-life system costs on average 2-3× more than a planned migration. |
|
'Some processes are still hanging on. |
Legitimate problem - but solvable. Usually 1-3 interfaces are involved. |
These interfaces are not found if the system is not actively inventoried. |
|
'We don't know how to get the data out. |
Most common technical obstacle - but solvable with database access or ETL tools. |
Data extraction is a solved problem. Almost any database can be extracted - even without an API. |
The real problem: legacy systems are not shut down because the time of shutdown is never the right time. There is always an ongoing project, an upcoming audit, a change of personnel. The result: the system runs for another five years - and the problem grows.
|
Cost category |
Annual cost drivers |
Typical amount p.a. |
|---|---|---|
|
License & maintenance |
Maintenance contracts for end-of-life software, often overpriced because there is no alternative |
5.000-40.000 € |
|
IT infrastructure |
Server, operating system, virtualization for a system that would otherwise be replaced |
3.000-20.000 € |
|
Integration costs |
Manual data maintenance, duplicate entries, interface maintenance for the successor system |
10.000-60.000 € |
|
Concentration of knowledge |
Only 1-2 people know the system. Failure = production crisis. Hardly quantifiable internally. |
Risk: 50,000-200,000 € in the event of damage |
|
Security risk |
Unpatched security vulnerabilities: ransomware risk in networked production environments |
Potential: total loss of production |
The most expensive decision in the IT architecture of a manufacturing company is not the new system. It's the old one that couldn't be switched off - and which therefore runs alongside the new one for another three years, not really looked after by anyone, but feared by everyone.
-Amadeus Chief Technology Evangelist, CSP Intelligence GmbH
This plan was developed from real migration projects in the manufacturing industry. It is sequential: each stage must be completed and approved before the next begins. Skipping leads to the problems that most legacy switchers encounter.
Timeframe: 2-6 weeks
Goal: Complete picture of all data, users, interfaces and dependent processes
⚠ This stage is most frequently underestimated. An incomplete inventory is the cause of 80% of all data losses during legacy shutdowns.
Time frame: 1-2 weeks
Goal: Clear decision for each data category: migrate, archive or delete
⚠Archived data must be available in a format that will still be readable in 15 years' time. Proprietary export formats are not an auditable archive format.
Time frame: 4-16 weeks
Goal: All data is available in the successor system or archived in accordance with standards
⚠ No productive operation of the migration without test migration. An error in the production migration is more difficult to correct than careful test preparation.
Time frame: 4-8 weeks
Goal: Confirmation that the successor system completely takes over all tasks of the legacy system
⚠ Parallel operation without an end date is not parallel operation - it is the legacy system with a new neighbor. The end date must be set before the start of the parallel phase.
Time frame: 1 week + 30 days monitoring
Goal: Legacy system is shut down, all proofs are documented, operation runs exclusively on the successor system
The biggest challenge in terms of content when switching off legacy systems is the decision: Which data will be migrated to the successor system - and which will be archived? This decision is not only technically relevant, but also operationally and legally.
|
Data category |
Data content |
Goal of the migration |
Priority |
|---|---|---|---|
|
Operational master data |
Article numbers, material data, tool data, station parameters, inspection plans |
Complete migration to the successor system |
Very high - before go-live |
|
Active transaction data |
Open production orders, current batches, active inspection processes |
Complete migration - no shutdown during ongoing processes |
Very high - time-critical |
|
Historical process data |
Completed batch records, process parameters of past production orders |
Migration of the last 2-3 years to the successor system, archive the rest |
High |
|
Compliance-relevant quality data |
Test results, release decisions, complaint data, audit logs |
Audit-capable long-term archiving for at least 15 years (IATF 16949) |
Very high - legally mandatory |
|
User and authorization data |
User accounts, access rights, processing histories |
Rebuild authorization concept in successor system, archive histories |
Medium |
|
Configuration data |
System settings, alarm limits, calibration parameters |
Carefully check whether transfer makes sense or whether reconfiguration is better |
Medium - critical for measurement technology |
In compliance logic, 'archived' does not mean 'stored somewhere'. It means: retrievable, readable, tamper-proof and verifiable with a time stamp - for an auditor or a court that no longer knows the system from which the data originated.
Open format: No proprietary binary format that can only be read with the original software. Recommended: PDF/A (for reports), CSV with schema documentation (for raw data), XML with XSD validation.
Completeness: The archive must contain the data AND the metadata: Timestamp, system of origin, time of export, person responsible.
Integrity: Checksums (SHA-256 or better) for all archive files so that subsequent manipulation can be detected.
Retrievability: The archive must be structured in such a way that an auditor without IT knowledge can find specific data for a specific part or batch.
Time stability: The archive format must still be readable in 15 years' time. Proprietary software formats and older versions of Office documents often do not meet this requirement.
The legacy system has been shut down. The data is archived. This is the beginning of what many forget: The retention obligations continue. The obligation to retrieve data continues. Liability for the integrity of the archived data continues.
|
Standard / set of rules |
Obligation after system shutdown |
Retention period |
Requirements for the archive |
|---|---|---|---|
|
IATF 16949:2016 |
Quality data (test results, batch records, approvals) must remain retrievable |
At least 15 years after last delivery (longer depending on OEM requirements) |
Retrievable, readable, tamper-proof |
|
ISO 9001:2015 |
Records must be stored in accordance with their intended purpose |
Depending on contractual agreement and product liability requirements |
Structured and traceable retrievable |
|
EU Product Liability Directive 2024 |
Production data must be available as exculpatory evidence |
Up to 25 years for latent damage |
It must be possible to reconstruct the exact component assignment |
|
GDPR |
Personal data (user IDs, worker logs) are subject to deletion obligations |
Max. Retention according to original processing purpose |
Documented deletion with proof |
|
HGB / GoBS |
Commercial documents and booking data (in integrated systems) |
10 years |
Unchangeable, readable at any time, machine analyzable |
Critical: Many companies lose their historical quality data in the course of a legacy shutdown and ERP migration because the data migration only includes the 'active' data. IATF auditors know this - and specifically ask for documents from the time before the migration.
When we visit a production facility that has just replaced a system, the first question we always ask is: Can you show me the component file for a delivery lot from the year before the migration? The answer to this question tells us everything we need to know about how the migration was prepared.
-Amadeus Chief Technology Evangelist, CSP Intelligence GmbH
These are the five mistakes we encounter most frequently in practice. None of them are unavoidable - they all have a structural cause, which is addressed with the 5-step plan.
The migration project starts without anyone knowing what is really in the legacy system. 'We've moved over the most important data' - but nobody has systematically determined what 'important' means. Result: Data is missing in the successor system, and this only becomes apparent during the first audit or the first callback.
Avoidance: Stage 1 of the 5-stage plan is not optional. The inventory must be complete before the first migration decision is made.
The historical data is archived as a database dump in the format of the legacy system - or as a proprietary binary export that only the original software can read. In 10 years' time, neither the software nor anyone who can operate it will still be available.
Avoidance: Only use open, long-term stable formats for archiving. Every archive document must be readable without special software.
The successor system has been introduced, but the legacy system continues to run 'for safety reasons'. There is no end date. A year later, the legacy system is still active - because it 'doesn't feel right' to switch it off. The result: two systems, two data statuses, increasing conflicts.
Avoidance: The end date of the parallel phase is set in stage 4 before the start and is binding. Extensions only with the written approval of the project manager.
IT reports: Migration completed, all data transferred. But production management or the quality team has never checked the content of the migrated data. The first audit reveals: inspection plans are missing, batch histories are incomplete, reference data is incorrect.
Avoidance: Every data category needs a technical approval - not just a technical completeness check. The quality of the migrated data is checked by the specialist department, not IT.
The CRM, ERP or reporting system obtains data from the legacy system - and nobody has it on the inventory list. After the shutdown, the ERP no longer provides quality data, the reporting shows gaps and the sales department asks why test certificates are no longer being generated.
Prevention: In stage 1, all outgoing interfaces are inventoried - not only the interfaces that are documented, but also those that only 'sort of work'.
|
CHECKLIST Before the go-live: Legacy shutdown acceptance checklist ☐ All data categories from the inventory have been migrated or archived ☐ Technical acceptance for each data category is available in writing ☐ All interfaces have been converted to the successor system and tested ☐ Compliance-relevant data is archived in an audit-compliant format ☐ Retention periods for each data category are documented ☐ GDPR deletion obligations for personal data are fulfilled ☐ No active user still has write access to the legacy system ☐ Final backup of the legacy system has been created and checked ☐ End date of the parallel phase has been met or approved in writing ☐ Rollback scenario has been checked and is no longer necessary ☐ Final protocol has been completed and approved ☐ Hardware and license decommissioning has been initiated |
The most common reason for the decision not to switch off is the fear of migration costs. A planned migration costs money. What is rarely calculated: What does it cost to continue operating the legacy system each year?
|
Scenario |
Migration costs |
Costs 5 years of continued operation |
Costs of unplanned downtime |
Decision |
|---|---|---|---|---|
|
MES legacy system, 200 employees, critical risk class |
80,000-150,000 € (one-off) |
75,000-175,000 € (cumulative) |
150,000-500,000 € (production downtime, ransomware) |
Migration pays off from year 2-3 |
|
QMS legacy system, 50 employees, high risk class |
30,000-70,000 € (one-off) |
40,000-80,000 € (cumulative) |
50,000-200,000 € (audit findings, data loss) |
Migration pays off from year 1-2 |
|
Proprietary data acquisition, 1 line, medium risk class |
15,000-40,000 € (one-off) |
15,000-35,000 € (cumulative) |
30,000-100,000 € (line downtime in the event of failure) |
Break-even after 12-18 months |
Note: These figures are approximate values based on typical project costs in the manufacturing industry. The actual ROI depends on system complexity, data volume and existing IT infrastructure.