{ "site": "DATANALYSIS", "id": "DATA-MODERNISATION-N1-20261110", "locale": "de", "status": "release_ready", "version": "1.0.0", "robots": "index, follow", "preparedAt": "2026-11-10", "updatedAt": "2026-11-10", "publishedAt": "2026-11-10", "title": "Eine Datenplattform modernisieren, während das Unternehmen weiterarbeitet", "description": "Die Umstellung einer Datenplattform vorbereiten: zu erhaltende Verwendungen, kohärenter Umfang, Vergleich mit expliziter Referenz, Freigabeentscheidung und Rückweg mit neuen Schreibvorgängen, mit Migrationskarte.", "lede": "Eine neue Plattform kann technisch bereit sein, während die Anwendungen und Teams, die von ihren Daten abhängen, noch nicht bereit sind, umzustellen. Das Lieferdatum der neuen Umgebung und das Umstellungsdatum der Verwendungen sind zwei verschiedene Entscheidungen.", "intro": [ "Um die zweite vorzubereiten, muss man betrachten, was die Daten erzeugt, was sie transformiert und was sie nutzt. Die folgende Methode schlägt fünf Entscheidungen vor, die für einen ersten Umfang zu dokumentieren sind. Sie schreibt weder eine vollständige Migration noch ein bestimmtes Werkzeug vor." ], "sections": [ { "id": "verwendungen-erhalten", "heading": "1. Von den Verwendungen ausgehen, die weiterlaufen müssen", "blocks": [ { "p": "Ein Datensatz kann eine Anwendung, eine Fakturierungsverarbeitung, einen Partnerexport und ein Reporting speisen. Diese Konsumenten haben nicht unbedingt dieselben Anforderungen an Fristen, Format oder Verfügbarkeit." }, { "p": "Die Kartierung muss daher Anwendungen, Datenflüsse, Regeln und Verantwortliche verbinden. Sie muss auch noch unbekannte Verwendungen kennzeichnen. Ein manuell weiterverarbeiteter Export oder eine wenig dokumentierte Altverarbeitung erscheint unter Umständen nicht in den ersten technischen Ansichten." }, { "p": "Die AWS-Empfehlungen zur Vorbereitung einer Umstellung betonen Abhängigkeiten, Tests, Verantwortlichkeiten und den Ablauf des Übergangs. [1] Für unsere Abgrenzung ist das erwartete Ergebnis eine verwertbare Liste: Welche Verwendung muss erhalten bleiben, wer gibt sie frei und welcher Nachweis zeigt, dass sie nach der Änderung funktioniert?" } ] }, { "id": "kohaerenter-umfang", "heading": "2. Einen kohärenten Umfang wählen", "blocks": [ { "p": "Der erste Schritt ist nicht unbedingt die kleinste Tabelle oder die am wenigsten sichtbare Anwendung. Er muss ein Ganzes bilden, das das Team migrieren und prüfen kann, ohne wesentliche Abhängigkeiten außen vor zu lassen." }, { "p": "Ein schrittweises Vorgehen kann den Umfang jeder Umstellung begrenzen, fügt aber eine Phase der Koexistenz hinzu. Dann müssen die Schnittstellen gepflegt werden, es muss klar sein, welches System maßgeblich ist, und mögliche Unterschiede zwischen beiden Wegen müssen behandelt werden. Eine gebündelte Umstellung kann nötig sein, wenn Komponenten eng gekoppelt sind. Die Wahl hängt von der Architektur und den Anforderungen des Geschäftsbetriebs ab. [2]" }, { "p": "Die nützliche Entscheidung lautet also nicht „alles migrieren oder nichts tun“, sondern „welche Verwendungen können gemeinsam vorankommen, mit welchen Prüfungen und welchen Abbruchbedingungen?“" } ] }, { "id": "vergleich-referenz", "heading": "3. Auf Grundlage identifizierter Regeln und Daten vergleichen", "blocks": [ { "p": "Zwei Summen zu vergleichen, reicht nicht, wenn Zeiträume, Regeln oder Ausgangsdaten abweichen. Vor der Abnahme muss das Team die zeitliche Referenz, die Filter, die Einheiten und die Sonderfälle festlegen, die das erwartete Ergebnis definieren." }, { "p": "Eine Abweichung kann von der neuen Verarbeitung stammen, von einer Aktualisierung der Quelle oder von einer fachlichen Regel, die während des Projekts geändert wurde. Ohne explizite Referenz läuft das Team Gefahr, all diese Änderungen als eine einzige Anomalie zu behandeln." }, { "p": "Die Prüfungen müssen die Ergebnisse abdecken, aber auch Verfügbarkeitszeiten, Berechtigungen und das Verhalten der konsumierenden Anwendungen. Daten, die in der Plattform korrekt sind, können trotzdem in der falschen Einheit gelesen werden oder für eine Verwendung zu spät ankommen." } ] }, { "id": "umstellungsentscheidung", "heading": "4. Die Umstellungsentscheidung zuweisen", "blocks": [ { "p": "Die Freigabe darf sich nicht auf „die Verarbeitungen sind grün“ beschränken. Man muss wissen, welche technischen und fachlichen Freigaben erwartet werden, welche vorliegen und welche Vorbehalte offen bleiben." }, { "table": { "caption": "Umstellungsentscheidungen und zu dokumentierende Elemente", "head": [ "Entscheidung", "Zu dokumentierendes Element" ], "rows": [ [ "Umfang", "Anwendungen, Datenflüsse, Verwendungen und Ausschlüsse." ], [ "Referenz", "Datensätze, Zeiträume und Regeln, die dem Vergleich dienen." ], [ "Validierung", "Erwartetes Ergebnis und verantwortliche Person jeder Prüfung." ], [ "Freigabe", "Entscheidungsbefugte Person, Kriterien und akzeptable Vorbehalte." ], [ "Überwachung", "Sofortige Prüfungen nach der Umstellung, Beobachtungsdauer und Empfänger der Warnungen." ], [ "Abbruch oder Rückweg", "Auslöser, verantwortliche Person und Behandlung bereits erzeugter Daten." ] ] } }, { "p": "Der Ablauf muss die Reihenfolge der Schritte festlegen und die Punkte, an denen die Änderung unterbrochen werden kann. Eine Probe in einer geeigneten Umgebung erlaubt es, den Plan mit den realen Abhängigkeiten abzugleichen; sie verwandelt die verbleibenden Annahmen nicht in Garantien." } ] }, { "id": "rueckweg-neue-schreibvorgaenge", "heading": "5. Den Rückweg mit den neuen Schreibvorgängen vorbereiten", "blocks": [ { "p": "Zum alten Code zurückzukehren, reicht nicht immer. Nach der Umstellung können Vorgänge gespeichert worden sein. Es muss entschieden werden, wie sie aufbewahrt, abgeglichen oder erneut eingespielt werden, ohne Verlust und ohne Duplikate." }, { "p": "Die Strategie muss auch die bereits an Anwendungen und Partner verteilten Ausgaben abdecken. Eine Korrektur in der Plattform zieht eine versendete Datei oder eine auf Basis eines falschen Ergebnisses getroffene Entscheidung nicht automatisch zurück." }, { "p": "Die Leitfäden zur Umstellung betonen, dass der Rückweg und die Behandlung geänderter Daten vorzusehen sind. [1][2] Das Projekt muss den Punkt bestimmen, ab dem ein einfacher Rückweg nicht mehr angemessen ist und ein Wiederanlauf- oder Korrekturverfahren nötig wird." } ] }, { "id": "karte-erster-schritt", "heading": "Die Karte in einen ersten Arbeitsschritt verwandeln", "blocks": [ { "p": "Die zugehörige Migrationskarte dient dazu, ein Treffen zwischen Anwendungsverantwortlichen, Datenteam, Betrieb und Fachbereichen vorzubereiten. Sie bündelt Umfang, erwartete Nachweise, Freigaben und Bedingungen für den Rückweg." }, { "p": "Sie kann zeigen, dass ein als Migration dargestelltes Problem zunächst eine Definition, einen Datenfluss oder eine schlecht beherrschte Abhängigkeit betrifft. Diesen Punkt zu behandeln, kann der erste Schritt des Projekts werden, ohne den gesamten Weg vorwegzunehmen." } ] } ], "body_markdown": "## 1. Von den Verwendungen ausgehen, die weiterlaufen müssen\n\nEin Datensatz kann eine Anwendung, eine Fakturierungsverarbeitung, einen Partnerexport und ein Reporting speisen. Diese Konsumenten haben nicht unbedingt dieselben Anforderungen an Fristen, Format oder Verfügbarkeit.\n\nDie Kartierung muss daher Anwendungen, Datenflüsse, Regeln und Verantwortliche verbinden. Sie muss auch noch unbekannte Verwendungen kennzeichnen. Ein manuell weiterverarbeiteter Export oder eine wenig dokumentierte Altverarbeitung erscheint unter Umständen nicht in den ersten technischen Ansichten.\n\nDie AWS-Empfehlungen zur Vorbereitung einer Umstellung betonen Abhängigkeiten, Tests, Verantwortlichkeiten und den Ablauf des Übergangs. [1] Für unsere Abgrenzung ist das erwartete Ergebnis eine verwertbare Liste: Welche Verwendung muss erhalten bleiben, wer gibt sie frei und welcher Nachweis zeigt, dass sie nach der Änderung funktioniert?\n\n## 2. Einen kohärenten Umfang wählen\n\nDer erste Schritt ist nicht unbedingt die kleinste Tabelle oder die am wenigsten sichtbare Anwendung. Er muss ein Ganzes bilden, das das Team migrieren und prüfen kann, ohne wesentliche Abhängigkeiten außen vor zu lassen.\n\nEin schrittweises Vorgehen kann den Umfang jeder Umstellung begrenzen, fügt aber eine Phase der Koexistenz hinzu. Dann müssen die Schnittstellen gepflegt werden, es muss klar sein, welches System maßgeblich ist, und mögliche Unterschiede zwischen beiden Wegen müssen behandelt werden. Eine gebündelte Umstellung kann nötig sein, wenn Komponenten eng gekoppelt sind. Die Wahl hängt von der Architektur und den Anforderungen des Geschäftsbetriebs ab. [2]\n\nDie nützliche Entscheidung lautet also nicht „alles migrieren oder nichts tun“, sondern „welche Verwendungen können gemeinsam vorankommen, mit welchen Prüfungen und welchen Abbruchbedingungen?“\n\n## 3. Auf Grundlage identifizierter Regeln und Daten vergleichen\n\nZwei Summen zu vergleichen, reicht nicht, wenn Zeiträume, Regeln oder Ausgangsdaten abweichen. Vor der Abnahme muss das Team die zeitliche Referenz, die Filter, die Einheiten und die Sonderfälle festlegen, die das erwartete Ergebnis definieren.\n\nEine Abweichung kann von der neuen Verarbeitung stammen, von einer Aktualisierung der Quelle oder von einer fachlichen Regel, die während des Projekts geändert wurde. Ohne explizite Referenz läuft das Team Gefahr, all diese Änderungen als eine einzige Anomalie zu behandeln.\n\nDie Prüfungen müssen die Ergebnisse abdecken, aber auch Verfügbarkeitszeiten, Berechtigungen und das Verhalten der konsumierenden Anwendungen. Daten, die in der Plattform korrekt sind, können trotzdem in der falschen Einheit gelesen werden oder für eine Verwendung zu spät ankommen.\n\n## 4. Die Umstellungsentscheidung zuweisen\n\nDie Freigabe darf sich nicht auf „die Verarbeitungen sind grün“ beschränken. Man muss wissen, welche technischen und fachlichen Freigaben erwartet werden, welche vorliegen und welche Vorbehalte offen bleiben.\n\n| Entscheidung | Zu dokumentierendes Element |\n|---|---|\n| Umfang | Anwendungen, Datenflüsse, Verwendungen und Ausschlüsse. |\n| Referenz | Datensätze, Zeiträume und Regeln, die dem Vergleich dienen. |\n| Validierung | Erwartetes Ergebnis und verantwortliche Person jeder Prüfung. |\n| Freigabe | Entscheidungsbefugte Person, Kriterien und akzeptable Vorbehalte. |\n| Überwachung | Sofortige Prüfungen nach der Umstellung, Beobachtungsdauer und Empfänger der Warnungen. |\n| Abbruch oder Rückweg | Auslöser, verantwortliche Person und Behandlung bereits erzeugter Daten. |\n\nDer Ablauf muss die Reihenfolge der Schritte festlegen und die Punkte, an denen die Änderung unterbrochen werden kann. Eine Probe in einer geeigneten Umgebung erlaubt es, den Plan mit den realen Abhängigkeiten abzugleichen; sie verwandelt die verbleibenden Annahmen nicht in Garantien.\n\n## 5. Den Rückweg mit den neuen Schreibvorgängen vorbereiten\n\nZum alten Code zurückzukehren, reicht nicht immer. Nach der Umstellung können Vorgänge gespeichert worden sein. Es muss entschieden werden, wie sie aufbewahrt, abgeglichen oder erneut eingespielt werden, ohne Verlust und ohne Duplikate.\n\nDie Strategie muss auch die bereits an Anwendungen und Partner verteilten Ausgaben abdecken. Eine Korrektur in der Plattform zieht eine versendete Datei oder eine auf Basis eines falschen Ergebnisses getroffene Entscheidung nicht automatisch zurück.\n\nDie Leitfäden zur Umstellung betonen, dass der Rückweg und die Behandlung geänderter Daten vorzusehen sind. [1][2] Das Projekt muss den Punkt bestimmen, ab dem ein einfacher Rückweg nicht mehr angemessen ist und ein Wiederanlauf- oder Korrekturverfahren nötig wird.\n\n## Die Karte in einen ersten Arbeitsschritt verwandeln\n\nDie zugehörige Migrationskarte dient dazu, ein Treffen zwischen Anwendungsverantwortlichen, Datenteam, Betrieb und Fachbereichen vorzubereiten. Sie bündelt Umfang, erwartete Nachweise, Freigaben und Bedingungen für den Rückweg.\n\nSie kann zeigen, dass ein als Migration dargestelltes Problem zunächst eine Definition, einen Datenfluss oder eine schlecht beherrschte Abhängigkeit betrifft. Diesen Punkt zu behandeln, kann der erste Schritt des Projekts werden, ohne den gesamten Weg vorwegzunehmen.", "closing": "Prüfen wir einen Modernisierungsumfang mit DATANALYSIS. Bringen Sie die betroffenen Anwendungen, die zu erhaltenden Verwendungen und die geplante Änderung mit. Wir können die Abhängigkeiten, die Freigaben und einen kohärenten ersten Schritt abstecken.", "cta": { "label": "Meinen Modernisierungsumfang prüfen", "url": "https://datanalysis.re/contact?lang=de" }, "worksheet": { "label": "Migrationskarte öffnen (druckbares HTML)", "url": "https://datanalysis.re/ressources/data-engineering/datenplattform-modernisieren-laufender-betrieb/migrationskarte", "fields": [ [ "Umfang und Verwendungen", "Ein Datensatz, der eine Anwendung, eine Fakturierungsverarbeitung, einen Partnerexport und ein Reporting speist; zu erhaltende Verwendungen, Ausschlüsse und noch unbekannte Verwendungen gekennzeichnet." ], [ "Abhängigkeiten und Verantwortliche", "Anwendungen, Datenflüsse, Regeln und Verantwortliche verbunden; manuell weiterverarbeiteter Export und wenig dokumentierte Altverarbeitung zu prüfen; eine benannte freigebende Person je Verwendung." ], [ "Referenz und Tests", "Zeitliche Referenz, Filter, Einheiten und Sonderfälle vor der Abnahme festgelegt; Prüfungen von Ergebnissen, Verfügbarkeitszeiten, Berechtigungen und Verhalten der konsumierenden Anwendungen." ], [ "Ablauf und Freigabe", "Reihenfolge der Schritte und Unterbrechungspunkte; entscheidungsbefugte Person, Kriterien, erhaltene Freigaben und akzeptable Vorbehalte; Probe in einer geeigneten Umgebung." ], [ "Abbruch, Rückweg und neue Schreibvorgänge", "Auslöser und verantwortliche Person; nach der Umstellung gespeicherte Vorgänge aufbewahrt, abgeglichen oder erneut eingespielt, ohne Verlust und ohne Duplikate; bereits verteilte Ausgaben; Punkt, ab dem ein Wiederanlauf- oder Korrekturverfahren nötig wird." ], [ "Überwachung, Nachweise und Datum", "Sofortige Prüfungen nach der Umstellung, Beobachtungsdauer und Empfänger der Warnungen; erwarteter Nachweis je Prüfung; Prüfdatum (fiktives Beispiel: kein reales Datum)." ] ], "pdf": "https://datanalysis.re/downloads/data-modernisation-carte.de.pdf" }, "pdf": { "article": "https://datanalysis.re/downloads/data-modernisation-article.de.pdf", "worksheet": "https://datanalysis.re/downloads/data-modernisation-carte.de.pdf", "pack": "https://datanalysis.re/downloads/data-modernisation-pack-fr-en-de.zip" }, "related_articles": [ { "title": "Wenn Daten ihre Bedeutung ändern: Änderungen zwischen Anwendungen vorbereiten", "url": "https://datanalysis.re/ressources/data-engineering/daten-bedeutung-aenderungen-zwischen-anwendungen" }, { "title": "Einen Datenfluss wieder aufnehmen, ohne seine Wirkungen zu vervielfachen", "url": "https://datanalysis.re/ressources/data-engineering/datenfluss-wiederaufnehmen-ohne-doppelte-wirkungen" } ], "sources": [ { "n": 1, "label": "AWS Prescriptive Guidance | Migration cutover best practices: pre-cutover stage", "url": "https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/pre-cutover-stage.html", "note": "Vorbereitung der Umstellung: Abhängigkeiten, Tests, Verantwortlichkeiten, Übergangsablauf und Rückweg" }, { "n": 2, "label": "AWS Prescriptive Guidance | Migration cutover best practices: cutover stage", "url": "https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html", "note": "Ablauf der Umstellung, Rückweg und Behandlung geänderter Daten" } ], "sources_note": "Quellen am 10. November 2026 eingesehen. Karte und Formulierungen sind eine didaktische Anpassung von Grundsätzen der Vorbereitung und Kontrolle. Sie stellen ohne Prüfung Ihrer Umgebung keinen ausführbaren Migrationsplan dar.", "canonical": "https://datanalysis.re/ressources/data-engineering/datenplattform-modernisieren-laufender-betrieb", "alternates": { "fr": "https://datanalysis.re/ressources/data-engineering/moderniser-plateforme-data-continuite-activite", "en": "https://datanalysis.re/ressources/data-engineering/modernising-data-platform-while-business-runs", "de": "https://datanalysis.re/ressources/data-engineering/datenplattform-modernisieren-laufender-betrieb" } }