Eine neue SCADA-Version lässt sich problemlos installieren. Anschließend zeigen historische Trends jedoch einen falschen Anlagenbezug, und der Wiederanlauf eines Rezepts verhält sich anders. Nicht nur die Softwareversion hat sich verändert, sondern das betriebliche System. Eine Migration älterer Automatisierung ist deshalb nicht automatisch ein einfacher gleichwertiger Austausch, auch wenn ein Lieferant die neue Plattform als kompatibel beschreibt.
Eine belastbare Migration erhält Funktionen, Aufzeichnungen und betriebliche Fähigkeiten oder verändert sie bewusst durch einen kontrollierten Übergang. Ihr Umfang umfasst Steuerungen, SCADA, Server, Netzwerke, Datenbanken, Rezepte, Benutzerrechte und Support. Die Projektgrenze muss die tatsächlichen Abhängigkeiten dieser Elemente berücksichtigen.
Den Grund und das Ziel der Migration bestimmen
Benennen Sie die Auslöser: auslaufender Betriebssystemsupport, fehlende Ersatzteile, selten gewordene Fachkenntnisse, Sicherheitsrisiken, Kapazitätsgrenzen oder neue Funktionen. Trennen Sie notwendige Risikominderung von gewünschten Verbesserungen. Werden sämtliche Erweiterungswünsche mit einem Ersatz wegen Obsoleszenz verbunden, kann das Projekt schwer prüfbar, planbar und rückgängig zu machen werden.
Beschreiben Sie den bisherigen und den zukünftigen Verwendungszweck. Legen Sie fest, welche Funktionen gleichwertig bleiben, welche verändert und welche stillgelegt werden. Vorhandene Dokumentation ist nicht automatisch ein korrektes Abbild der laufenden Anwendung. Vergleichen Sie die installierte Konfiguration mit kontrollierten Unterlagen und klären Sie wesentliche Abweichungen vor Festlegung der Ausgangsbasis.
[QRM] Bewerten Sie sowohl die Folgen eines Weiterbetriebs als auch die Risiken der Umstellung. Während der Vorbereitung können vorübergehende Kontrollen erforderlich sein. Sie benötigen Verantwortliche, Bedingungen für erneute Bewertung und einen glaubwürdigen Weg zur Lösung. Der Hinweis auf eine früher validierte Anlage ersetzt diese Bewertung nicht.
Abhängigkeiten vor der Umfangsfestlegung erfassen
Erfassen Sie Steuerungen, Ein- und Ausgänge, Kommunikationsmodule, Bedienstationen, Server, Datenbanken, Lizenzen, Engineering-Werkzeuge und angebundene Systeme. Beziehen Sie Identitätsverwaltung, Zeitdienste, Sicherungen und Netzwerke ein. Versionen und Supportstatus müssen ausreichend genau sein, um Kompatibilität und Wiederherstellung beurteilen zu können.
Suchen Sie nach weniger sichtbaren betrieblichen Abhängigkeiten: lokalen Skripten, geplanten Berichten, manuellen Exporten, Lieferantenrechnern, Rezeptdateien und nicht dokumentierten Datenbankabfragen. Sprechen Sie mit Bedienern und Instandhaltung. Ein selten genutztes Werkzeug kann nach der Umstellung entscheidend sein, wenn eine Steuerung ausfällt.
Prüfen Sie physische Schnittstellen. Ein Steuerungsaustausch kann elektrische Eigenschaften, Kanalzuordnung, Zeitverhalten und Kommunikation mit Lieferantensystemen verändern. Die Virtualisierung eines Servers verändert Infrastrukturabhängigkeiten, selbst wenn die Anwendung gleich bleibt. Planen Sie deshalb den vollständigen technischen Dienst und nicht lediglich eine Softwareinstallation.
Übergangsstrategie mit klaren Abwägungen wählen
| Ansatz | Möglicher Vorteil | Zu klärende Frage |
|---|---|---|
| Vollständige geplante Umstellung | Eindeutiger Wechsel und kürzere Mischkonfiguration | Passen Stillstand, Prüfung und Wiederherstellung in das verfügbare Zeitfenster? |
| Schrittweise Migration | Begrenzter Änderungsumfang pro Schritt | Können alte und neue Schnittstellen ohne unklare Zuständigkeit zusammenarbeiten? |
| Parallele Beobachtung | Vergleich ausgewählter Ergebnisse vor Übergabe | Wie werden konkurrierende Befehle und doppelte maßgebliche Aufzeichnungen verhindert? |
| Altes Archiv und neues Betriebssystem | Historischer Zugriff ohne vollständige Konvertierung | Bleibt das Archiv über die Aufbewahrung sicher, lesbar und betreibbar? |
Ansätze können kombiniert werden. Entscheiden Sie anhand von Prozessbedingungen, Risiko, Datenbedarf und Wiederherstellbarkeit. Der Begriff Parallelbetrieb benötigt eine genaue Bedeutung. Zwei Systeme dürfen nicht widersprüchliche Befehle oder konkurrierende Originalaufzeichnungen erzeugen, nur damit ein Vergleich möglich wird.
Steuerungslogik funktional migrieren
Automatische Codekonvertierung kann helfen, doch erfolgreiche Übersetzung beweist kein gleichwertiges Verhalten. Prüfen Sie Ausführungsmodell, Datentypen, Bedeutung von Anweisungen, Kommunikationsbehandlung und Wiederanlauf. Verifizieren Sie Kanalzuordnung sowie Beziehungen zwischen Befehl, Rückmeldung und Prozesszustand.
Priorisieren Sie folgenreiche Funktionen und Übergänge: Verriegelungen, Freigabebedingungen, Sequenzen, Rezeptausführung, Halten, Wiederanlauf, Kommunikation und gespeicherte Zustände. Schnellere oder anders geplante Programmausführung kann Logik beeinflussen, die von bisherigen Zeitannahmen abhing. Ähnlicher Quelltext allein belegt keine Prozessequivalenz.
[GEP] Nutzen Sie geeignete Simulation und repräsentative Prüfungen, gefolgt von der Verifikation installierter Schnittstellen. Bewahren Sie Identitäten von Original und migrierter Konfiguration auf und dokumentieren Sie beabsichtigte Änderungen. Die Nachweise erklären die Eignung für den vorgesehenen Prozess einschließlich der Grenzen verwendeter Vergleichsmethoden.
SCADA- und Serverwechsel als Anwendungsänderungen bewerten
Überprüfen Sie Grafiken, Skripte, Treiber, Alarme, Trends, Berechnungen, Berichte und Sicherheitsrollen. Plattformwechsel können Standardwerte, unterstützte Komponenten oder Skriptausführung verändern. Vergleichen Sie Lieferantenaussagen zur Kompatibilität mit den tatsächlich eingesetzten Modulen und standortspezifischen Anpassungen.
Serverersatz und Virtualisierung erfordern eine Bewertung von Speicher, Netz, Ressourcenzuteilung, Zeitverhalten, Sicherung und Wiederherstellung. Gemeinsam genutzte Infrastruktur kann neue gemeinsame Ausfallursachen schaffen. Bestätigen Sie Verfügbarkeit und Leistung unter erwarteter Last sowie relevanten Störungsbedingungen.
Prüfen Sie Bedienaufgaben auf der gelieferten Oberfläche. Ein überarbeitetes Bild kann sämtliche Werte enthalten und dennoch Navigation oder Befehlsbedeutung verändern. Schulen Sie wesentliche Unterschiede und passen Sie Anweisungen an. Die Umstellung ist betrieblich unvollständig, wenn Mitarbeiter weiterhin Verfahren für ein anderes Systemverhalten anwenden.
Daten nach Aufzeichnungsklassen behandeln
Bestimmen Sie, welche Aufzeichnungen übertragen werden, welche in einem kontrollierten Archiv verbleiben und welche nach genehmigtem Verfahren gelöscht werden dürfen. Definieren Sie Aufbewahrungspflichten und notwendige Beziehungen für die Interpretation. Historian-Werte, Audit Trails, Rezepte, Benutzerhistorie und Chargenkontext können unterschiedliche Lösungen benötigen.
Erstellen Sie eine Zuordnungsspezifikation für konvertierte Daten. Berücksichtigen Sie Kennungen, Einheiten, Zeitstempel, Qualitätsmerkmale, Verknüpfungen und Versionen. Beschreiben Sie Transformationen und Regeln für Ausnahmen. Gleiche Zeilenzahlen belegen keine Richtigkeit, wenn Inhalte gekürzt, Zeitzonen verschoben oder Beziehungen verloren werden.
Erhalten Sie Herkunft sowie Unterscheidung zwischen ursprünglicher und migrierter Information. Kann das Ziel eine ursprüngliche Eigenschaft nicht aufnehmen, bewerten Sie die Folge und eine begründete Alternative. Fehlende historische Metadaten dürfen nicht erfunden werden. Rekonstruierte Information darf nicht als zeitgleich mit dem Prozess erfasst erscheinen.
Vollständigkeit und Bedeutung der Migration nachweisen
Nutzen Sie passende Abgleichsmethoden: Mengen, gegebenenfalls Prüfsummen, Feldvergleiche, Beziehungsprüfungen und repräsentativen Abruf. Automatisierte Prüfungen können die Population abdecken; gezielte Betrachtung oder Prozessrekonstruktion prüft die Bedeutung ausgewählter Fälle. Wählen Sie diese nach Risiko und bekannten Datenmerkmalen aus.
Berücksichtigen Sie alte Versionen, Sommerzeitwechsel, korrigierte Einträge, ungewöhnliche Zeichen, lange Werte, schlechte Messqualität und Aufzeichnungen über Anlagenänderungen hinweg. Untersuchen Sie Abweichungen und dokumentieren Sie ihre Behandlung. Eine kleine ungeklärte Differenz kann auf einen systematischen Transformationsfehler hinweisen.
Bestätigen Sie, dass berechtigte Personen migrierte und archivierte Daten mit unterstützten Werkzeugen finden und verstehen können. Eine technisch wiederhergestellte Datenbank genügt nicht, wenn Prüfer den passenden Chargenkontext oder die erforderliche Änderungshistorie nicht mehr erreichen.
Rezepte und Zugriffsrechte bewusst übernehmen
Gleichen Sie freigegebene Rezepte und Versionen vor der Übertragung ab. Kennzeichnen Sie veraltete, entworfene und aktive Definitionen und verhindern Sie versehentliche Aktivierung ungeprüfter Versionen. Prüfen Sie Parametergrenzen, Einheiten, Ablaufstruktur und Beziehung zu den Fähigkeiten der Zielausrüstung.
Ordnen Sie Benutzerrollen und Berechtigungen gezielt zu. Übernehmen Sie überholte Konten oder unnötige Privilegien nicht nur deshalb, weil ein Importwerkzeug dies unterstützt. Historische Zuordnung und aktuelles Zugangsrecht sind getrennte Bedürfnisse. Ein ehemaliger Benutzer muss in alten Aufzeichnungen erkennbar bleiben können, ohne weiterhin ein aktives Konto zu besitzen.
Prüfen Sie Dienstkonten, Zertifikate und Lieferantenzugänge zusammen mit menschlichen Benutzern. Bestätigen Sie Verantwortlichkeit und Lebenszyklusregeln in der Zielarchitektur. Der Beitrag zur OT-Cybersicherheit vertieft die damit verbundenen Entscheidungen.
Die Umstellung als kontrollierte Folge planen
Definieren Sie Voraussetzungen, Rollen, Schritte, Prüfpunkte und Kommunikation. Legen Sie den erforderlichen Prozesszustand fest und behandeln Sie laufende Chargen sowie offene Transaktionen ausdrücklich. Frieren Sie relevante Konfigurationen und Datenbestände an einer bekannten Grenze ein, damit der Abgleich einen nachvollziehbaren Bezug besitzt.
Regeln Sie die Übergabe der Steuerungs- und Aufzeichnungsverantwortung. Bestimmen Sie, wann das alte System Befehle und Datenerfassung beendet und wann das neue beginnt. Verhindern Sie die verspätete Wiedergabe alter Warteschlangen, gespeicherter Befehle oder geplanter Aufgaben nach Wiederverbindung. Prüfen Sie Schnittstellen auf beiden Seiten.
Verwenden Sie entscheidbare Kriterien für Fortsetzung oder Abbruch. Dazu gehören wesentliche Funktionen, Datenabgleich und Supportbereitschaft. Reservieren Sie Zeit für eine begründete Wiederherstellungsentscheidung. Ein Rückkehrplan ist unglaubwürdig, wenn der Entscheidungspunkt erst nach Verbrauch des verfügbaren Zeitfensters erreicht wird.
Rückkehr und ihre Grenzen verstehen
Rollback kann mehr verlangen als die Neuinstallation alter Software. Sobald das neue System Aufzeichnungen erzeugt oder den Prozess verändert hat, kann eine Rückkehr Datenabgleich und Kompatibilitätsbewertung erfordern. Bestimmen Sie, ab wann einfache Umkehr nicht mehr möglich ist und welches Wiederherstellungsverfahren danach gilt.
Schützen Sie alte Referenzkonfiguration, Medien und Wiederherstellungsabhängigkeiten. Demonstrieren Sie den Wiederherstellungsweg soweit angemessen in einer geeigneten Umgebung. Dokumentieren Sie Einschränkungen, Zeitbedarf und Fachkenntnisse. Eine Sicherung, die nie wiederhergestellt wurde, ist eine Annahme und kein belegter Rückfallweg.
[GUIDEGXP-EMPFEHLUNG] Bewerten Sie die Rückkehr gemeinsam mit Produktion, Automatisierung, IT und Qualität. Entscheidend ist ein akzeptabler kontrollierter Zustand mit verständlichen Aufzeichnungen. Das erfolgreiche Starten eines alten Serverabbilds beantwortet diese umfassendere Frage noch nicht.
Praxisbeispiel: Historian-Wechsel im Stillstand
Ein beispielhafter Standort ersetzt einen nicht mehr unterstützten Historian und behält die lokale Prozesssteuerung. Alte Aufzeichnungen müssen erreichbar bleiben; neue Daten sollen mit freigegebenen Einstellungen erfasst werden. Das Team wählt ein kontrolliertes Archiv für einen Teil des Bestands und verifizierte Konvertierung für Daten mit integriertem Abrufbedarf.
Vor dem Stillstand erfasst es Tags, Einheiten, Qualitätskennungen, Zeitkonventionen und Chargenzuordnung. Ein Probelauf zeigt, dass einige alte Tags im Zeitverlauf andere Anlagen bezeichneten. Das Team erhält die Konfigurationshistorie und passt den Abrufkontext an, statt jede Kennung als unveränderliche physische Messstelle zu behandeln.
Bei der Umstellung endet die alte Erfassung an einer definierten Grenze. Die neue Erfassung beginnt und der Übergangszeitraum wird abgeglichen. Die Abnahme betrachtet bekannte Ereignisse, verspätete Werte, Qualitätsmerkmale und historischen Abruf. Die alte Umgebung bleibt gemäß Archiv- und Wiederherstellungsplan kontrolliert.
Abnahme an der veränderten Systemgrenze ausrichten
Trennen Sie Nachweise der neuen Funktion von Vergleichen zur betrieblichen Kontinuität. Das neue System darf bewusst anders und besser arbeiten; exakte Gleichheit ist daher nicht immer richtig. Dokumentieren Sie genehmigte Unterschiede und untersuchen Sie ungeklärte Abweichungen, statt sie automatisch als Verbesserung einzuordnen.
Prüfen Sie Szenarien, die die geänderte Grenze überschreiten. Eine neue Steuerung benötigt ihre tatsächlichen Überwachungs- und Ausrüstungsschnittstellen. Ein neuer Server benötigt Identität, Zeit, Speicher und Wiederherstellung. Ein migrierter Bericht wird gegen bekannte Quelldaten und genehmigte Berechnungsregeln geprüft.
Eine angemessene Probe der Umstellung kann Timing und Verantwortlichkeiten verbessern. Dokumentieren Sie, was die Probe belegt und welche Standortbedingungen nicht reproduziert wurden. Eine erfolgreiche Laborübung beweist nicht, dass alle betrieblichen Abhängigkeiten erfasst wurden.
Wissen übertragen und Stabilisierung begleiten
Aktualisieren Sie Zeichnungen, Inventare, Wiederherstellungsanweisungen und Wartungsverfahren auf den gelieferten Zustand. Übergeben Sie Engineering-Umgebung, Zugänge und notwendige Lizenzen. Bestätigen Sie, dass Standortpersonal repräsentative Diagnose und Wiederherstellung durchführen kann, ohne ausschließlich vom Migrationsdienstleister abhängig zu sein.
Erläutern Sie geänderte Navigation, Alarme, Datenabruf und historische Einschränkungen. Schulung verwendet die freigegebene Konfiguration oder eine kontrollierte Entsprechung. Halten Sie offene Supportabhängigkeiten mit Verantwortlichen fest, bevor das Projektteam abzieht. Andernfalls kann ein neues System dieselbe betriebliche Fragilität wie sein Vorgänger entwickeln.
Für die erste Betriebsphase definieren Sie eine Beobachtung der besonders betroffenen Funktionen. Prüfen Sie ausstehende Schnittstellenmeldungen, ungewöhnliche Bedienprobleme und Abweichungen zwischen geplanten und tatsächlichen Wiederanlaufwegen. Das bedeutet keine pauschale zusätzliche Vollprüfung, sondern eine begründete Konzentration auf die Risiken des Übergangs. Benennen Sie Ansprechpartner und Kriterien für das Ende der erhöhten Betreuung.
Verwalten Sie offene Restpunkte sichtbar. Ein akzeptierter Dokumentationsnachtrag ist anders zu behandeln als ein ungeklärter Verlust von Chargenkontext. Beschreiben Sie jeweils Auswirkung, vorübergehende Maßnahme, Verantwortlichen und Abschlussnachweis. Eine Freigabe darf nicht allein deshalb erfolgen, weil das Wartungsfenster endet oder der Lieferant abreisen muss.
Freigabe und geordnete Außerbetriebnahme
[REGULATORISCHE ANFORDERUNG] Wenden Sie relevante GMP-Regeln für Änderung, computergestützte Systeme und Qualifizierung auf die bewertete Änderung an. Umfang der erneuten Prüfung folgt Auswirkung und Risiko. Die Bezeichnung gleichwertiger Austausch durch einen Lieferanten entbindet den Standort nicht von dieser Bewertung.
Entfernen Sie alte Konten, Fernzugänge, Lizenzen und Hardware gemäß Plan, ohne benötigte Aufzeichnungen oder Wiederherstellung zu verlieren. Verbinden Sie die Migration mit risikobasierter Assurance, gegebenenfalls Cleanrooms & HVAC Systems und Automation & Digital Systems.
Primärquellen und Status
Bei der endgültigen Stilllegung prüfen Sie außerdem, ob externe Schnittstellen noch auf alte Adressen, Konten oder Dateipfade verweisen. Entfernen Sie solche Verweise kontrolliert und bestätigen Sie, dass Archivzugriff und Aufbewahrung weiterhin funktionieren. Kennzeichnen Sie außer Betrieb genommene Komponenten eindeutig im Inventar. So bleibt für spätere Wartung und Inspektion nachvollziehbar, welches System zu welchem Zeitpunkt die maßgebliche Funktion und Aufzeichnung verantwortete.
Geprüft am 23. September 2026: EudraLex Band 4, Annex 11, Kapitel 4 und Annex 15; ICH Q9(R1); ICH Q10; NIST SP 800-82 Revision 3. Annex 11 und Kapitel 4 bleiben in der Fassung 2011 maßgeblich. Strategien, Vergleichsfragen und Beispiel sind GuideGxP-Empfehlungen für eine systemspezifische Anpassung.
