GxP-Datenarchivierung bei Systemstilllegung: Records bis zum letzten Abruf sichern

GxP-Datenarchivierung bei Systemstilllegung ist erst abgeschlossen, wenn relevante Daten und Metadaten vollständig übernommen oder kontrolliert archiviert, über die Aufbewahrungszeit lesbar und abrufbar sowie gegen unautorisierte Änderung geschützt sind. Die Abschaltung des Servers ist der letzte technische Schritt – nicht der Beginn des Projekts.

Warum der Datenlebenszyklus nicht mit dem Go-Live des Nachfolgers endet

Systemablösungen werden häufig als Migrationsprojekt geplant: Daten übertragen, Benutzer schulen, neues System freigeben. Für ein GxP-relevantes Altsystem reicht diese Sicht nicht. Die Daten bleiben möglicherweise noch Jahre für Chargenfreigabe, Stabilität, Reklamationen, Inspektionen oder Produktentscheidungen relevant.

Die EMA beschreibt den Datenlebenszyklus von Erzeugung und Verarbeitung über Nutzung, Speicherung und Abruf bis zur kontrollierten Aussonderung am Ende der Aufbewahrungszeit. Für Computersysteme sollen Business Process Owner und IT den Lebenszyklus gemeinsam bewerten. EU GMP Annex 11 verlangt außerdem, dass archivierte Daten zugänglich, lesbar und integer bleiben und dass die Abrufbarkeit bei relevanten Systemänderungen sichergestellt und geprüft wird.

Das ist der Kern einer GxP-Systemstilllegung: Nicht das Altsystem wird konserviert, sondern die Fähigkeit, erforderliche Records vollständig und nachvollziehbar zu verwenden.

Schritt 1: Stilllegungsscope und Verantwortlichkeiten festlegen

Der Scope beginnt beim Intended Use und den Geschäftsprozessen, nicht bei einer Serverliste. Ein ERP-, LIMS-, MES- oder eQMS-System kann unterschiedliche GxP-relevante Funktionen, Schnittstellen und Datenobjekte enthalten. Entsprechend muss das Team klären:

• Welche regulierten Prozesse und Produkte wurden unterstützt?
• Welche Daten, Metadaten, Audit Trails, Signaturen und Berichte sind Records?
• Welche Schnittstellen, Dateispeicher, Archive und Satellitensysteme gehören zum Datenfluss?
• Welche Aufbewahrungsfristen und laufenden fachlichen Verwendungen bestehen?
• Wer genehmigt Vollständigkeit, Zugriffskonzept, Testnachweise und finale Abschaltung?

Ein Decommissioning Owner koordiniert das Vorhaben. Die fachliche Verantwortung bleibt jedoch verteilt: Der Process Owner beurteilt Nutzbarkeit und Vollständigkeit, QA die GxP-Konformität, IT Architektur und Betrieb, Records Management die Aufbewahrung und Informationssicherheit die Schutzmaßnahmen.

Schritt 2: Daten- und Metadateninventar erstellen

Die häufigste Lücke ist ein Inventar, das nur Tabellen oder Dokumentdateien auflistet. Ein vollständiger Record kann zusätzlich Kontext benötigen: Versionsstand, Benutzerzuordnung, Zeitstempel, Audit Trail, elektronische Signatur, Status, Verknüpfung zu Masterdaten oder die verwendete Auswertelogik.

Für jedes relevante Datenobjekt sollte das Inventar mindestens festhalten:

Feld	Leitfrage
Geschäftszweck	Welche Entscheidung oder welcher Nachweis hängt davon ab?
Quelle	In welchem System, Modul oder Speicher entsteht der Record?
Kontext/Metadaten	Was wird für Bedeutung und Rekonstruktion benötigt?
Aufbewahrung	Wie lange und aufgrund welcher Vorgabe?
Zielzustand	Migration, validiertes Archiv, Read-only-System oder kontrollierte Vernichtung?
Abruf	Wer muss in welchem Format suchen, anzeigen und exportieren können?
Schutz	Wie werden Zugriff, Änderung, Verlust und Löschung kontrolliert?

Dieses Inventar verbindet regulatorische Anforderung und technische Umsetzung. Ohne diese Ebene ist ein erfolgreicher Zeilenvergleich noch kein Nachweis dafür, dass ein Record später fachlich verstanden werden kann.

Schritt 3: Zielarchitektur risikobasiert entscheiden

Es gibt keine universell beste Stilllegungsarchitektur. Drei Muster sind üblich:

Migration in das Nachfolgesystem. Geeignet, wenn Daten dort aktiv weiterverarbeitet werden und Semantik, Beziehungen und Funktionen zuverlässig abgebildet werden können. Die Migration kann aber unnötige Komplexität erzeugen, wenn historische Records im Zielsystem nur selten gelesen werden.

Übernahme in ein validiertes Archiv. Sinnvoll, wenn Records langfristig gesucht, angezeigt und exportiert werden müssen, aber keine operative Bearbeitung mehr vorgesehen ist. Das Archiv braucht definierte Datenmodelle, Zugriffskontrollen, Schutz vor Änderung, Backup/Recovery und eine geprüfte Retrieval-Funktion.

Read-only-Betrieb des Altsystems. Kann kurzfristig vertretbar sein, bindet jedoch Infrastruktur, Know-how, Lizenzen und Security-Support. Je länger der Betrieb dauert, desto größer wird das Risiko, dass Hardware, Betriebssystem, Authentifizierung oder Viewer nicht mehr tragfähig sind.

Die Entscheidung sollte Datenkritikalität, Restaufbewahrungszeit, Abrufhäufigkeit, Abhängigkeiten, Cyberrisiko, Betriebskosten und Verfügbarkeit geeigneter Anzeige-/Exportfunktionen gemeinsam bewerten.

Schritt 4: Migration oder Archivierung spezifizieren und testen

Der Eignungsnachweis muss zum Risiko passen. Bei strukturierten Daten reicht eine reine Dateianzahl selten aus. Relevante Tests können umfassen:

• Vollständigkeit nach Objekt, Zeitraum, Standort oder Produkt;
• Wertegleichheit und Behandlung von Rundung, Zeichensätzen und Zeitzonen;
• Erhalt von Beziehungen zwischen Record, Metadaten, Audit Trail und Signatur;
• korrekte Darstellung von Status, Version und Historie;
• Such-, Anzeige- und Exportfunktion für typische Inspektionsfragen;
• Berechtigungen und Schutz gegen unautorisierte Änderung;
• Backup, Restore und Wiederanlauf des Zielarchivs;
• dokumentierte Behandlung von Ausnahmen und nicht migrierbaren Objekten.

Bei großen Datenmengen kann eine Kombination aus automatisierten Vollständigkeitskontrollen und risikobasierten fachlichen Stichproben angemessen sein. Die Auswahl und Akzeptanzkriterien müssen vor Testbeginn feststehen. Die GxP-Systemvalidierung des Zielsystems und der Migrationsprozess sind dabei miteinander verbunden, aber nicht identisch.

Schritt 5: Retrieval als Geschäftsprozess qualifizieren

Ein Archiv gilt nicht deshalb als nutzbar, weil IT eine Datei öffnen kann. Ein späterer Benutzer muss den richtigen Record innerhalb einer angemessenen Zeit finden, vollständig anzeigen und für den vorgesehenen Zweck bereitstellen können.

Retrieval-Tests sollten daher reale Szenarien abbilden, zum Beispiel:

• eine Chargen- oder Materialhistorie anhand definierter Suchmerkmale finden;
• den zum damaligen Zeitpunkt gültigen Record einschließlich Status und Genehmigung anzeigen;
• Audit-Trail- oder Änderungsinformationen zum Record bereitstellen;
• einen lesbaren, kontrollierten Export für eine Inspektion erzeugen;
• einen Record nach Restore des Archivs erneut abrufen.

Die Testperson sollte das spätere Rollenprofil repräsentieren. Ein ausschließlich durch das Migrationsteam ausgeführter Test kann Bedienungs- und Wissensabhängigkeiten verdecken.

Schritt 6: Abschaltkriterien und Restkontrollen genehmigen

Vor dem Abschalten braucht das Projekt eine dokumentierte Entscheidung. Sinnvolle Exit-Kriterien sind:

• genehmigtes Daten- und Metadateninventar;
• abgeschlossene Migration/Archivierung einschließlich Abweichungen;
• bestandene Retrieval-, Berechtigungs- und Restore-Tests;
• definierter Owner und Betriebsprozess für das Zielarchiv;
• geregelte Aufbewahrung, Legal Hold und kontrollierte Vernichtung;
• aktualisierte Systeminventare, SOPs, Verträge und Business-Continuity-Unterlagen;
• deaktivierte Schnittstellen, technische Konten und Benutzerzugriffe;
• genehmigte Restpunkte mit Verantwortlichem und Termin.

Erst danach werden Anwendung, Infrastruktur und Schnittstellen kontrolliert außer Betrieb genommen. Datenträger oder verbliebene Kopien dürfen nicht unkoordiniert gelöscht werden; ihre Behandlung folgt Aufbewahrungs-, Sicherheits- und Vernichtungsregeln.

Schritt 7: Den archivierten Zustand periodisch erhalten

Die Verantwortung endet nicht mit dem Abschlussbericht. Ein Archiv kann durch Plattformwechsel, Browser- oder Viewer-Updates, Identitätsmigration, Schlüsselwechsel oder organisatorische Änderungen seine Nutzbarkeit verlieren.

Der Betriebsprozess sollte deshalb risikobasiert prüfen:

• Erreichbarkeit und Lesbarkeit ausgewählter Records;
• Wirksamkeit von Zugriffskontrollen;
• Backup-/Restore-Fähigkeit;
• technische Obsoleszenz und Supportstatus;
• offene Aufbewahrungsfristen und geplante Vernichtung;
• Änderungen, die einen erneuten Retrieval-Test auslösen.

Damit wird Stilllegung zu einem kontrollierten Endzustand des Systemlebenszyklus – nicht zu einem einmaligen Infrastrukturprojekt.

Typische Fehlentscheidungen

„Wir migrieren einfach alles.“ Das verschiebt Daten ohne zu klären, ob Kontext, Beziehungen und Abruf im Ziel erhalten bleiben.

„Das PDF ist der Record.“ Ein PDF kann lesbar sein, aber Audit Trail, Signaturkontext, Version oder strukturierte Beziehungen verlieren.

„Read-only bedeutet risikofrei.“ Ein nicht mehr veränderbares Altsystem kann trotzdem ausfallen, unpatchbar werden oder nur noch von einzelnen Mitarbeitern bedient werden.

„Nach dem Go-Live kann der Server aus.“ Ohne genehmigte Vollständigkeit, Retrieval- und Restore-Nachweise ist die Datenverfügbarkeit nicht ausreichend belegt.

Häufige Fragen

Müssen alle historischen Daten in das neue System migriert werden?

Nein. Migration, Archiv oder befristeter Read-only-Betrieb können je nach Intended Use, Aufbewahrung und Risiko angemessen sein. Entscheidend ist, dass relevante Records vollständig, geschützt, lesbar und abrufbar bleiben.

Genügt ein Datenbank-Backup als GxP-Archiv?

In der Regel nicht als alleiniger Nutzbarkeitsnachweis. Ein Backup unterstützt Wiederherstellung. Ein Archiv muss zusätzlich kontrollierten Zugriff, Bedeutung, Lesbarkeit, Suche und Retrieval über den Aufbewahrungszeitraum ermöglichen.

Wann darf das Altsystem abgeschaltet werden?

Wenn genehmigte Exit-Kriterien erfüllt sind: Daten und Metadaten wurden kontrolliert übernommen oder archiviert, Abweichungen bewertet, Retrieval und Restore geprüft, Verantwortlichkeiten geregelt und Schnittstellen sowie Zugriffe kontrolliert beendet.

Primärquellen

• EMA: Guidance on GMP/GDP — Questions and Answers, Abschnitt Data Lifecycle
• Europäische Kommission: EU GMP Annex 11 — Computerised Systems
• EudraLex Volume 4 — aktueller Veröffentlichungsstand

---

Autor

Daniel Herrmann Consulting unterstützt Pharma- und Biotech-Unternehmen bei der kontrollierten Ablösung validierter Systeme – vom Dateninventar über Migration und Archivierung bis zum geprüften Legacy Shutdown.

Steht eine SAP-, LIMS-, MES- oder eQMS-Ablösung an?

Bei der SAP-Validierung und anderen Systemablösungen strukturieren wir Scope, Datenentscheidungen, Nachweise und Abschaltkriterien so, dass Ihr Nachfolgesystem starten kann, ohne den historischen GxP-Nachweis zu verlieren.

Systemstilllegung besprechen