Inhaltsverzeichnis
Das Wichtigste vorab
Ist ein Read-only-Altsystem ein geeignetes GxP-Archiv?
Ein lesender Restbetrieb kann ein geeigneter Übergangs- oder Aufbewahrungszustand sein, wenn benötigte Daten zugänglich, verständlich und geschützt bleiben. Er ist aber nicht allein durch das Etikett „Read-only“ abgesichert. Prüfen Sie verbleibende Schreibwege, technische Abhängigkeiten, Lizenzzugang und langfristige Betreibbarkeit. Die Aufbewahrungsverantwortung endet nicht mit dem letzten produktiven Auftrag.
Einordnung und Geltungsbereich
Hier wird eine mögliche Stilllegungsvariante bewertet. Es gibt keine pauschale Empfehlung, jedes Altsystem dauerhaft weiterzubetreiben. Migration und gesondertes Archiv können je nach Datenbestand geeigneter sein.
Lesend für den Nutzer bedeutet nicht unveränderbar auf jeder Ebene
Der Zugriff hängt oft von Komponenten ab, die nicht im Archivplan stehen: Identitätsdienst, Zertifikate, Lizenzserver oder alte Betriebssysteme. Wenn diese Dienste später entfallen, kann ein technisch intakter Datenbestand trotzdem unlesbar werden. Der Restbetrieb benötigt deshalb einen benannten Betreiber und eine realistische Erhaltungsstrategie.
Testen Sie den fachlichen Abruf nach dem Übergang. Können Personen mit vorgesehenen Rechten einen historischen Vorgang finden und interpretieren? Ist eine erforderliche Kopie exportierbar? Ein erfolgreicher Administrator-Login genügt nicht als Nachweis für den späteren Audit- oder Untersuchungszugriff.
Was ein lesender Restbetrieb tatsächlich erhält
Ein Read-only-Modell kann historische Recherche in der ursprünglichen Anwendung ermöglichen. Es kann damit Beziehungen und Funktionen erhalten, die ein einfacher Export verliert. Gleichzeitig bleibt eine technische Umgebung aktiv. Diese Umgebung benötigt weiterhin Zuständigkeit, Zugriff, Sicherheit und eine geeignete Wiederherstellbarkeit. Read-only bedeutet daher nicht automatisch wartungsfrei.
Definieren Sie, welche Schreibvorgänge verhindert werden sollen. Eine gesperrte Eingabemaske beantwortet nicht, ob Datenbankzugänge, Schnittstellen, Jobs oder administrative Werkzeuge weiterhin Inhalte verändern. Ermitteln Sie die tatsächlichen Wege und wählen Sie passende Kontrollen. Eine pauschale Behauptung vollständiger Unveränderbarkeit wäre ohne diese Prüfung zu weitgehend.
Unterscheiden Sie Archivfunktion und technische Verpackung. Eine virtuelle Maschine ist ein Betriebsweg, kein eigener Nachweis der langfristigen Lesbarkeit. Eine PDF-Sammlung kann statische Informationen erhalten, aber dynamische Recherche verlieren. Der Zielzustand muss anhand benötigter historischer Fragen beurteilt werden.
Eine Architekturentscheidung mit laufenden Abhängigkeiten treffen
Erfassen Sie Anwendung, Datenbank, Betriebssystem, Identitätsdienst, Lizenzserver, Viewer und Schlüssel, soweit sie benötigt werden. Prüfen Sie, welche Komponenten weiterhin unterstützt und wiederherstellbar sind. Ein funktionierender Zugriff am Abschalttag beweist nicht die Verfügbarkeit nach einem späteren Server- oder Kontowechsel.
Vergleichen Sie Restbetrieb und unabhängige Archivlösung anhand desselben fachlichen Umfangs. Ein günstiger Restbetrieb kann langfristig hohe Pflege oder unbeherrschte Ausfälle verursachen. Ein Archivprojekt kann anfangs aufwendiger sein, dafür technische Abhängigkeiten verringern. Es gibt keinen universellen Gewinner; die Entscheidung sollte Risiken, Nutzungsbedarf und Lebensdauer zusammenführen.
| Kriterium | Lesender Restbetrieb | Unabhängiger Archivweg |
|---|---|---|
| Historische Funktion | Ursprüngliche Anwendung kann Kontext erhalten | Benötigte Recherche muss gezielt abgebildet werden |
| Schreibschutz | Alle relevanten Wege bewerten | Übernahme und nachfolgende Integritätskontrollen prüfen |
| Technische Abhängigkeit | Alte Laufzeit, Lizenz und Dienste bleiben relevant | Neue Formate und Archivkomponenten werden relevant |
| Wiederherstellung | Vollständige Umgebung erforderlich | Geeignete Daten- und Anwendungswiederherstellung |
| Spätere Änderung | Betrieb weiter kontrollieren | Lesbarkeit und mögliche Archivmigration erhalten |
Beispiel: Oberfläche gesperrt, Hintergrundjob verändert weiter
Das Szenario ist konstruiert. Ein Altsystem wird für gewöhnliche Benutzer lesend gesetzt. Ein geplanter Hintergrundjob bereinigt jedoch weiterhin bestimmte historische Datensätze. Die Oberfläche wirkt unverändert, obwohl der Bestand nach dem vorgesehenen Stilllegungszeitpunkt verändert wird. Ein Test nur der Schaltflächen entdeckt diese Abhängigkeit nicht.
Inventarisieren Sie Jobs, Verbindungen und technische Identitäten. Prüfen Sie die gewählte Read-only-Regel mit geeigneten Versuchen über die relevanten Wege. Für den Hintergrundjob wird beobachtet, ob er deaktiviert, kontrolliert begrenzt oder weiterhin fachlich erforderlich ist. Die Entscheidung muss den vorgesehenen Zielzustand berücksichtigen.
Rekonstruieren Sie danach einen historischen Vorgang und vergleichen Sie einen bekannten Referenzbestand. Ergänzen Sie einen berechtigten administrativen Wartungsvorgang. Notwendige technische Pflege darf nicht unbemerkt fachliche Aufzeichnungen verändern. Der Nachweis sollte die Grenze zwischen erlaubter Administration und geschütztem Inhalt verständlich machen.
| Prüffall | Aktion | Erwarteter Nachweis |
|---|---|---|
| Oberfläche | Historischen Record ändern versuchen | Gewählte Nutzerbegrenzung wirkt |
| Schnittstelle | Bezeichneten Schreibaufruf versuchen | Kein ungeklärter Änderungsweg |
| Job | Geplante Hintergrundverarbeitung bewerten | Zielzustand wird nicht unbemerkt verändert |
| Administration | Notwendige Wartung durchführen | Fachliche Datenwirkung ist kontrolliert |
| Referenzrecherche | Bekannten Vorgang wiederfinden | Benötigter Inhalt und Kontext erhalten |
Lesbarkeit und Wiederherstellung praktisch erproben
Wählen Sie einen normalen historischen Vorgang und einen Fall mit kritischem Kontext, etwa Korrektur, Methodenversion oder Anhang. Ein berechtigter Mitarbeiter sollte beide ohne Hilfe des ursprünglichen Entwicklers erklären können. Eine geöffnete Startseite oder erfolgreiche Anmeldung ist dafür zu wenig.
Erproben Sie einen geeigneten Wiederherstellungsfall. Dazu gehören die tatsächlich benötigten Daten und Komponenten. Prüfen Sie danach nicht nur den technischen Start, sondern die historische Recherche. Ein Backup kann vorhanden sein, während Lizenzzugriff oder Schlüssel fehlen. Solche Grenzen müssen vor der endgültigen Abschaltentscheidung bekannt sein.
Dokumentieren Sie erwartete Zugriffszeiten nur mit passender Begründung. Eine universelle Sekunden- oder Stundenanforderung wird hier nicht angenommen. Entscheidend ist, ob benötigte Informationen für die vorgesehenen Aufgaben angemessen verfügbar sind und Ausfälle kontrolliert behandelt werden.
Sicherheit und Zugriff im Restbetrieb weiterführen
Alte Software kann Sicherheitsrisiken besitzen, die durch fehlende aktive Fachnutzung nicht verschwinden. Bewerten Sie Exposition, Zugriffswege und mögliche Schutzmaßnahmen. Eine angemessene Isolation kann unterstützen, ersetzt jedoch weder kontrollierten Zugang noch eine funktionsfähige Recherche. Änderungen an Schutzmaßnahmen müssen ihre Daten- und Betriebswirkung berücksichtigen.
Benennen Sie interne und externe Benutzer. Auch selten verwendete Konten brauchen einen nachvollziehbaren Zweck. Prüfen Sie Vertretung und den Weg bei einer späteren Inspektion. Ein Archiv, das nur über das persönliche Konto eines ausgeschiedenen Administrators erreichbar ist, besitzt eine praktische Zugriffslücke.
Halten Sie notwendige Wartung und Veränderungen fest. Eine neue Virtualisierungsplattform, ein geänderter Identitätsdienst oder ein Storagewechsel kann die Lesbarkeit beeinflussen. Der Umfang zusätzlicher Prüfungen richtet sich nach dieser Wirkung. Read-only befreit nicht von der Bewertung relevanter technischer Änderungen.
Die endgültige Ablösung des Restbetriebs vorbereiten
Ein Restbetrieb kann eine begründete Zwischenlösung sein. Legen Sie fest, welche Bedingung seine spätere Ablösung ermöglicht. Dazu können ein geeigneter Archivexport, eine abgeschlossene historische Untersuchung oder ein geänderter Aufbewahrungsbedarf gehören. Ein bloßes Kalenderdatum ist ohne fachlichen Bezug schwach.
Übergeben Sie Architektur, Zugriffe, Recherchefälle, Wiederherstellung und offene Abhängigkeiten. Die Verantwortung darf nicht nach Ende des Projekts verschwinden. Ein kontrollierter Restbetrieb ist ein eigener Betriebszustand mit bewusstem Umfang. Dokumentieren Sie ihn entsprechend und halten Sie die weitere Entscheidung nachvollziehbar.
Arbeitsvorlage: Schreibschutz und historische Nutzung gemeinsam nachweisen
Beschreiben Sie den vorgesehenen Restzustand mit erlaubten und nicht erlaubten Handlungen. Fachliche Records sollen im Beispiel nicht mehr regulär geändert werden; berechtigte Recherche und notwendige technische Pflege bleiben möglich. Erfassen Sie alle relevanten Wege, nicht nur die gewöhnliche Oberfläche.
Prüfen Sie außerdem den Ausfall einer Abhängigkeit. Ein Read-only-System kann bei fehlendem Identitäts- oder Lizenzdienst ebenso unzugänglich werden wie ein aktives System. Der Nachweis verbindet deshalb Schutz vor unerwünschter Änderung und geeignete Wiederherstellbarkeit. Keine dieser Aufgaben ersetzt die andere.
Bei einem gefundenen Schreibweg wird dessen fachliche Wirkung bewertet. Nicht jede technische Änderung ist eine Veränderung historischer Records, aber die Grenze muss verständlich sein. Dokumentieren Sie geeignete Maßnahmen und prüfen Sie danach die benötigte Recherche erneut. Eine pauschale Sperrung kann sonst auch den einzigen historischen Zugriff zerstören.
| Kontrollfeld | Konstruierter Eintrag | Prüfaussage |
|---|---|---|
| Fachliche Nutzung | Historische Untersuchung öffnen. | Inhalt und Kontext verfügbar. |
| Oberfläche | Kritischen Wert ändern versuchen. | Vorgesehene Begrenzung wirkt. |
| Alternativweg | Job, Schnittstelle und direkter Zugang bewertet. | Kein ungeklärter Schreibpfad. |
| Administration | Notwendige Wartung mit Zuständigkeit. | Datenwirkung kontrolliert. |
| Ausfall | Bezeichnete Abhängigkeit wiederherstellen. | Recherche funktioniert danach vollständig. |
| Ablösung | Bedingung für späteres Ende des Restbetriebs. | Keine unbegründete Dauerabhängigkeit. |
Die nächsten Schritte
- Aufbewahrungszweck und Dauer des Restbetriebs definieren.
- Schreibwege, automatische Jobs und technische Abhängigkeiten erfassen.
- Fachlichen Abruf und Schutz mit vorgesehenen Rollen prüfen.
- Betreiber, laufende Kontrollen und späteren Ausstieg festlegen.
Häufige Fragen zu Stilllegung: Lesender Restbetrieb
Muss ein Read-only-System weiter gepflegt werden?
Darf die Anwendungslizenz gekündigt werden?
Ist ein Screenshot der alten Oberfläche ausreichend?
Ist eine virtuelle Maschine automatisch ein geeignetes Archiv?
Nein. Sie kann einen technischen Betriebsweg bereitstellen. Prüfen Sie zusätzlich Datenkontext, Schreibwege, Abhängigkeiten, Zugriff und Wiederherstellung. Ein virtueller Server kann ebenso von alten Lizenzen oder Schlüsseln abhängen wie eine physische Maschine. Die Eignung folgt aus dem nachgewiesenen historischen Nutzungszweck.
Kann ein Read-only-System ohne weitere Betreuung bestehen bleiben?
Nicht automatisch. Benennen Sie notwendige technische Pflege, Zugriff und Wiederherstellung. Änderungen an Infrastruktur oder Identitätsdiensten können die Nutzung beeinflussen. Die passende Betreuung richtet sich nach Risiken und Dauer. Ein einmal erfolgreicher Test am Projektende bestätigt keine unbegrenzte zukünftige Verfügbarkeit.
Warum genügt das Entfernen aller Fachbenutzer-Schreibrechte nicht immer?
Andere Wege wie Jobs, Schnittstellen oder administrative Werkzeuge können weiterhin wirken. Erfassen und bewerten Sie die tatsächliche Architektur. Die benötigte Kontrolle soll den vorgesehenen historischen Bestand erhalten, ohne erforderliche technische Pflege unklar auszuschließen. Der Nachweis muss diese Grenze zeigen.
Wie planen wir das spätere Ende eines Restbetriebs?
Benennen Sie den verbleibenden Bedarf und eine geeignete alternative Lösung oder den begründeten Wegfall des Bedarfs. Prüfen Sie den Zielzustand vor endgültigem Entzug. Ein Kalenderdatum allein bestätigt keine Eignung. Archivzugriff, Aufbewahrung und technische Abhängigkeiten müssen zusammenpassen.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)§§ 7, 10, 12, 16 und 17: Datenhaltung, Änderungen, Zugriff, Kontinuität und Archivierung. Geltende Fassung laut EudraLex am 14.10.2026; keine universelle Projekt- oder Fristvorgabe.
- PIC/S: PI 041-1, Good Practices for Data Management and Integrity (2021)Inspektionsleitlinie zur Datenintegrität; insbesondere elektronische Daten, Übertragung, Zugriff und Review.
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Vom offenen Punkt zu einem nachvollziehbaren Vorgehen.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.