Datenintegrität

Datenmigration im validierten Umfeld: Der Nachweis, dass die Daten nach dem Umzug stimmen

Der Systemwechsel ist entschieden, die Prozesse sind konfiguriert, der Cutover steht. Dann fragt der Auditor, woran Sie erkennen, dass die Chargenhistorie aus dem Altsystem vollständig und unverändert im neuen ERP liegt. Wer darauf mit einem Screenshot und dem Satz „die Daten sind drin“ antwortet, hat keinen Nachweis, sondern eine Behauptung.

Validierung von Dynamics 365 bei AENUMA · Systemwechsel und Migration

Die Migration ist eine kontrollierte Änderung

Eine Datenmigration verändert den Inhalt eines Systems, das Qualitätsaufzeichnungen führt. Damit ist sie eine Änderung im Sinne des Qualitätsmanagementsystems und gehört in die Change Control, mit geplantem Umfang, dokumentierter Durchführung, bewerteter Auswirkung und formaler Freigabe vor dem Produktivstart.

Die Anknüpfungspunkte sind eindeutig. Artikel 10 Absatz 9 der MDR verlangt ein Qualitätsmanagementsystem, das unter anderem ein Konzept zur Einhaltung der Regulierungsvorschriften einschließlich des Managements von Änderungen, die Produktrealisierung und die Überprüfung der UDI-Zuteilung abdeckt. ISO 13485:2016 fordert in Abschnitt 4.1.6 die Validierung von Computersoftware, die im Qualitätsmanagementsystem eingesetzt wird, und in Abschnitt 4.2.5 die Lenkung von Aufzeichnungen über die vom Hersteller festgelegte Lebensdauer des Produkts. Der EU-GMP-Leitfaden formuliert es in Annex 11, Abschnitt 4.8, am direktesten: „If data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process.“

Annex 11 gehört zum EU-GMP-Leitfaden, ist also eine Leitlinie im Arzneimittelbereich und für einen reinen Medizinproduktehersteller nicht verbindlich. Nach unserer Projekterfahrung begegnen uns diese Erwartungen aber auch in Audits Benannter Stellen, und er wird verbindlich, sobald an einem Standort Arzneimittel unter GMP hergestellt werden. Bei Arzneimittel-Produkt-Kombinationen ist im Einzelfall abzugrenzen, welcher Teil GMP-reguliert ist. Wie der Migrationsschritt sauber in den übergeordneten Validierungsplan für Dynamics 365 eingehängt wird, entscheidet über den Prüfaufwand am Ende.

„Die Daten sind drin“ ist kein Nachweis

Ein erfolgreicher Importlauf bedeutet: Die Sätze haben die technischen Prüfungen des Zielschemas passiert. Er bedeutet nicht, dass alle Sätze übernommen wurden, dass die Feldinhalte dieselbe Bedeutung tragen und dass keine Transformation stillschweigend einen Status verändert hat.

Das Data Management Framework in Dynamics 365 Finance und Supply Chain Management lädt Quelldaten zunächst in Staging-Tabellen und von dort in die Zieltabellen. Microsoft beschreibt für die Performance-Optimierung ausdrücklich, dass die Optionen „Run business validations“ und „Run business logic in insert or update method“ abgeschaltet werden können, wenn der Migrationsprozess ausgereift ist. Genau hier entsteht das Risiko: Wer die Prüfungen zugunsten des Cutover-Fensters deaktiviert, muss die Prüfung an anderer Stelle nachweisbar wieder aufnehmen. Diese Entscheidung ist zu treffen, zu begründen und zu dokumentieren, nicht dem technischen Team zu überlassen.

ALCOA+ auf die Migration angewendet: was gilt, was analog gilt

ALCOA+ steht für Attributable, Legible, Contemporaneous, Original, Accurate sowie Complete, Consistent, Enduring, Available. Die Begriffe stammen aus dem GxP-Umfeld der Arzneimittelaufsicht. Die MHRA-Leitlinie „GxP Data Integrity Guidance and Definitions“ führt sie in Abschnitt 3.10 auf, stellt in Abschnitt 2.4 aber selbst fest, dass sie sich nicht auf Medizinprodukte erstreckt. Wer ALCOA+ gegenüber einem Medizinproduktehersteller als geltendes Recht verkauft, argumentiert falsch.

Die Substanz dahinter ist trotzdem verbindlich, nur über andere Normen: über die Aufzeichnungslenkung der ISO 13485, über die Dokumentations- und Rückverfolgbarkeitspflichten der MDR und der IVDR, und für den US-Markt über 21 CFR Part 11, das in 11.10 für geschlossene Systeme unter anderem die Fähigkeit verlangt, „accurate and complete copies of records“ zu erzeugen, Aufzeichnungen über den gesamten Aufbewahrungszeitraum abrufbar zu halten und Änderungen so aufzuzeichnen, dass sie frühere Einträge nicht verdecken. Part 11 greift dabei nur für Aufzeichnungen, die eine Predicate Rule verlangt; für Medizinproduktehersteller ist das 21 CFR 820, seit der Neufassung als Quality Management System Regulation mit ISO 13485:2016 als in Bezug genommener Norm. ALCOA+ ist damit ein brauchbares Prüfraster, keine Rechtsgrundlage. Diese Unterscheidung sollte in Ihrem Validierungsplan auch so stehen.

Zwei Punkte brechen bei jedem Systemwechsel strukturell:

• Original. Der Satz im neuen System ist eine Kopie, oft eine transformierte. Das Original bleibt der Datensatz im Altsystem. Behandlung: die Transformationsregel dokumentieren, den Ursprungsbezug im Zielsystem als Feld mitführen und die Quelle entweder als geprüfte Kopie oder im Altsystem verfügbar halten.
• Attributable und Contemporaneous. Nach der Übernahme steht in der Änderungshistorie ein technischer Migrationsbenutzer mit dem Ladezeitpunkt. Behandlung: ursprünglicher Ersteller und ursprünglicher Zeitstempel werden als eigene Felder übernommen, migrierte Sätze werden als solche gekennzeichnet, und der Audit Trail des Altsystems bleibt lesbar erhalten.

Der Migrationsvalidierungsplan

Der Plan ist ein eigenes, freigegebenes Dokument. Er enthält:

1. Scope und Abgrenzung. Welche Mandanten, welche Zeiträume, welche Objekte werden übernommen, welche bewusst nicht, und mit welcher Begründung?
2. Datenobjekte mit Kritikalitätseinstufung. Die Einstufung folgt der Produktsicherheit und der regulatorischen Nachweispflicht, nicht dem Datenvolumen.
3. Mapping-Spezifikation. Feld für Feld, inklusive Transformationsregeln, Default-Werten, Rundungen, Zeichensatz und Umgang mit Feldern ohne Entsprechung im Zielsystem.
4. Akzeptanzkriterien. Quantitativ und vor dem ersten Testlauf festgelegt, zum Beispiel Abweichung null bei Satzzahlen und Mengensummen je Objekt.
5. Testfälle und Testmigrationen. Mindestens ein vollständiger Probelauf auf einer Produktionsdatenkopie unter realistischen Bedingungen.
6. Abweichungsbehandlung. Wer bewertet? Wer entscheidet? Wie werden Korrektur und Wiederholung des betroffenen Laufs nachgewiesen?
7. Freigabe. Namentliche Rollen aus Fachbereich, Qualitätsmanagement und IT, mit Datum und Unterschrift.

Die Tiefe der Prüfung skaliert mit dem Risiko. Das ist derselbe Gedanke, der hinter dem Unterschied zwischen CSV und Computer Software Assurance steht: Aufwand dorthin, wo ein Fehler den Patienten oder die Konformität trifft.

Verifikationsmethoden, die vor einem Audit standhalten

• Vollzähligkeitsabgleich. Satzzahlen je Datenobjekt, Mandant und Zeitraum, dazu Kontrollsummen über Mengen, Werte und Bestände. Quelle und Ziel werden gegenübergestellt, die Differenz ist null oder erklärt.
• Stichprobenbasierte Feldprüfung. Der Stichprobenumfang wird vor der Prüfung festgelegt und begründet, etwa über einen Attributprüfplan nach ISO 2859-1. „Wir haben einige Sätze angesehen“ ist kein Verfahren.
• Vollprüfung kritischer Objekte. Bei kleinen, hochkritischen Mengen wie gesperrten Chargen oder aktiven Lieferantenfreigaben ist eine Vollprüfung schneller als die Diskussion über die Stichprobe.
• Vier-Augen-Prüfung. Wer migriert hat, gibt das eigene Ergebnis nicht selbst frei.
• Negativtests. Ein gesperrter Bestand darf im Zielsystem nicht disponierbar sein. Ein abgelaufener Lieferantenstatus darf keine Bestellung zulassen.
• Reconciliation-Report. Maschinell erzeugt, wiederholbar, mit Zeitstempel und Lauf-ID archiviert.

Datenobjekte mit erhöhtem Risiko

In Dynamics 365 Finance und Supply Chain Management schreibt das Database Logging Einfüge-, Änderungs- und Löschvorgänge ausgewählter Tabellen in die Tabelle sysdatabaselog und protokolliert Transaktionen mit elektronischer Signatur standardmäßig mit. Microsoft weist allerdings darauf hin, dass Database Logging nicht für Batch-Verarbeitung und lange laufende Datenimporte ausgelegt ist. Der Nachweis über die Migrationsläufe selbst wird deshalb in der Regel über den Reconciliation-Report und die Auftragshistorie geführt, nicht über das Database Logging. Diese Entscheidung ist vor dem Ladelauf zu treffen und zu begründen. Wie tief die Verkettung reichen muss, hängt vom Produkt ab: Details dazu in unserem Beitrag zur Chargenrückverfolgbarkeit im ERP.

Das Altsystem: abschalten oder aufbewahren

Artikel 10 Absatz 8 der MDR verlangt, technische Dokumentation, EU-Konformitätserklärung und Bescheinigungen mindestens zehn Jahre nach dem letzten Inverkehrbringen verfügbar zu halten, bei implantierbaren Produkten mindestens fünfzehn Jahre. Artikel 25 verpflichtet Wirtschaftsakteure, gegenüber den Behörden zu benennen, an wen sie ein Produkt geliefert und von wem sie es bezogen haben. Artikel 27 Absatz 8 verlangt, die UDI gelieferter und bezogener Produkte vorzugsweise elektronisch zu speichern, zunächst verbindlich für implantierbare Produkte der Klasse III. Diese Pflichten enden nicht mit der Abschaltung eines Servers.

Drei Wege sind vertretbar, jeder mit dokumentierter Begründung:

• Altsystem im Lesezugriff weiterbetreiben. Erhält das Original, kostet aber weiter Lizenzen, Betrieb und Sicherheitspflege und verlangt zusätzlich eine begründete Aussage, warum das eingefrorene System noch vertrauenswürdig ist.
• Strukturierte Archivierung. Extraktion in ein definiertes, langfristig lesbares Format mit nachgewiesener Vollzähligkeit. Die archivierten Daten werden auf Zugänglichkeit, Lesbarkeit und Integrität geprüft, und diese Prüfung wird wiederholt, nicht einmalig abgehakt.
• Übernahme in das Zielsystem plus Archivkopie des Audit Trails. Der Regelfall bei Stamm- und Bestandsdaten, wenn die Historie fachlich weiterlebt.

Für Hersteller mit US-Marktzugang setzt 21 CFR Part 11 den zusätzlichen Rahmen: Aufzeichnungen müssen über den gesamten Aufbewahrungszeitraum genau und jederzeit abrufbar bleiben. „Der Wartungsvertrag lief aus“ ist nach unserer Erfahrung keine Begründung, die ein Auditor akzeptiert. Wer den Weg von einer älteren Plattform aus geht, findet die typischen Stolperstellen im Beitrag zum Wechsel von Dynamics NAV auf Business Central.

Abgrenzung

AENUMA ist keine Benannte Stelle und kein Auditor. Wir erstellen keine Konformitätsbewertungen und sprechen keine Zertifizierungen aus. Wir bauen die Nachweisführung, die Ihr Qualitätsmanagementsystem und Ihre Benannte Stelle prüfen. Dieser Beitrag gibt allgemeine fachliche Hinweise und ersetzt keine Rechtsberatung und keine Prüfung des Einzelfalls.

FAQ zur Datenmigration im validierten Umfeld

Reicht es, das Zielsystem zu validieren?
Nein. Die Validierung des Systems zeigt, dass die Funktionen bestimmungsgemäß arbeiten. Sie sagt nichts darüber, ob der konkrete Ladelauf Ihre Daten vollständig und unverändert übertragen hat. Beides sind getrennte Nachweise.

Wie groß muss die Stichprobe bei der Feldprüfung sein?
Es gibt keine regulatorisch vorgegebene Zahl. Entscheidend ist, dass der Umfang risikobasiert festgelegt, vor der Prüfung dokumentiert und nach einem anerkannten Verfahren begründet wird. Bei kritischen Objekten ist die Vollprüfung meist der günstigere Weg.

Gilt ALCOA+ für Medizinproduktehersteller verbindlich?
Nicht als solches. ALCOA+ stammt aus dem GxP-Umfeld der Arzneimittelaufsicht, und die MHRA-Leitlinie schließt Medizinprodukte ausdrücklich aus ihrem Anwendungsbereich aus. Die inhaltlichen Anforderungen an Vollständigkeit, Zuordenbarkeit und Aufbewahrung ergeben sich für Sie aus ISO 13485, MDR und IVDR sowie für den US-Markt aus 21 CFR Part 11.

Dürfen wir das Altsystem nach dem Go-live abschalten?
Nur wenn die aufbewahrungspflichtigen Aufzeichnungen anderswo vollständig, lesbar und über die gesamte Frist abrufbar vorliegen und dieser Zustand nachgewiesen ist. Die Entscheidung gehört mit Begründung in die Change Control und in den Migrationsvalidierungsbericht.

Der richtige nächste Schritt

Wenn ein Systemwechsel ansteht, entscheidet sich die spätere Auditfähigkeit nach unserer Erfahrung in den Wochen vor dem ersten Testladelauf, nicht im Cutover-Wochenende. Der schnellste Einstieg ist eine nüchterne Bestandsaufnahme: Welche Datenobjekte sind nachweispflichtig, welche Nachweise existieren bereits, und wo klafft die Lücke zwischen technischem Plan und regulatorischem Anspruch?

Nächster Schritt: Validation Health Check oder Validierung von Dynamics 365.

Weiterlesen: Traceability Matrix für Dynamics 365
Alle Fachbeiträge im Überblick

Quellen

Verordnung (EU) 2017/745 über Medizinprodukte (MDR), EUR-Lex
Verordnung (EU) 2017/746 über In-vitro-Diagnostika (IVDR), EUR-Lex
EudraLex Volume 4, Annex 11: Computerised Systems, Europäische Kommission
MHRA, GxP Data Integrity Guidance and Definitions
21 CFR Part 11, Electronic Records; Electronic Signatures, eCFR
FDA, Computer Software Assurance for Production and Quality Management System Software
ISO 13485:2016, Medizinprodukte, Qualitätsmanagementsysteme, Anforderungen für regulatorische Zwecke
Microsoft Learn, Data management overview
Microsoft Learn, Optimize data migration for finance and operations apps
Microsoft Learn, Configure database logging

Dieser Beitrag gibt den Rechts- und Produktstand vom 21. August 2026 wieder. Er ersetzt keine Rechtsberatung und keine Prüfung des Einzelfalls. Maßgeblich ist der Wortlaut der jeweils geltenden Fassung der zitierten Rechtsakte und Normen.

AENUMA Redaktion · Stand: 21. August 2026 · Wie diese Beiträge entstehen