Wenn sich ein Produkt verändert, kann sich auch ändern, wie es seine Daten abbildet: Ein Feld erhält einen neuen Namen, eine Entität wird aufgeteilt oder eine neue Geschäftsregel kommt hinzu. Die Entscheidung ist nicht rein technischer Natur. Es gilt zu wählen, ob vorhandene Datensätze aktualisiert, Daten bei jeder Abfrage angepasst oder während einer Übergangsphase beide Formate unterstützt werden.
Die entscheidende Frage lautet: Wann sollten Daten migriert und wann beim Lesen transformiert werden? Die Antwort hängt davon ab, wer die Informationen nutzt, welche Konsistenz das Produkt benötigt und wie hoch der laufende Wartungsaufwand ist. Keine der beiden Vorgehensweisen ist immer die bessere. Ziel ist, die jeweiligen Kompromisse offenzulegen und festzulegen, wie sich der Erfolg überprüfen lässt.
Was sich bei den beiden Ansätzen ändert

Bei einer dauerhaften Migration werden gespeicherte Daten so verändert, dass sie dem neuen Modell entsprechen. Je nach Umfang, Infrastruktur und Verfügbarkeitsanforderungen kann dies in einem kontrollierten Vorgang oder in einzelnen Chargen geschehen. Anschließend arbeiten Abfragen mit der neuen Darstellung. Während des Übergangs müssen sie möglicherweise jedoch auch ältere Datensätze erkennen.
Bei einer Transformation zur Lesezeit bleiben die ursprünglichen Daten erhalten und werden erst bei der Ausgabe angepasst. Eine Zugriffsschicht, ein Dienst oder eine Abfrage kann das alte Format in die Struktur umwandeln, die der aktuelle Verbraucher erwartet. Diese Form der Kompatibilität vermeidet eine sofortige Massenänderung, verursacht aber zusätzlichen Aufwand bei Lesevorgängen und bringt Logik mit sich, die dauerhaft gepflegt werden muss.
Eine Zwischenlösung besteht darin, beide Formate vorübergehend zu unterstützen und schrittweise umzustellen. Die Anwendung kann beispielsweise zuerst das neue Format lesen und, falls dieses nicht vorhanden ist, das alte umwandeln. Neue Schreibvorgänge speichern bereits im aktualisierten Format. Dafür braucht es klare Regeln, damit nicht jeder Verbraucher seine eigene Variante implementiert.
Kriterien für die Entscheidung
Beschreiben Sie zunächst die Änderung als konkreten Bedarf: Welche Daten ändern sich, wer verwendet sie und welches Verhalten muss erhalten bleiben? Bewerten Sie anschließend die folgenden Kriterien:
- Konsistenz: Wenn alle Verbraucher denselben Wert und dieselben Regeln sehen müssen, kann eine gemeinsame dauerhafte Darstellung Abweichungen verringern. Ist die Umwandlung dagegen nur für eine bestimmte Oberfläche oder einen einzelnen Verbraucher gedacht, kann eine Leseebene besser passen.
- Häufigkeit und Kosten der Lesevorgänge: Eine wiederholte Transformation auf einem stark genutzten Pfad kann Latenz und Ressourcenverbrauch erhöhen. Bei seltenen Lesevorgängen oder kleinen Datenmengen ist dieser Aufwand möglicherweise akzeptabel. Messen Sie ihn im tatsächlichen Einsatz.
- Umfang und Betrieb: Eine vollständige Migration kann Zeit, Fehlerkontrolle und ausreichend Kapazität erfordern, damit Datensätze ohne Unterbrechung des Dienstes verarbeitet werden. Bei großen Datenmengen sollten Sie Chargen und eine Fortschrittskontrolle einplanen, statt von der Sicherheit eines einzigen Vorgangs auszugehen.
- Anzahl der Verbraucher: Bei mehreren Diensten, Anwendungen, Berichten oder Integrationen kann eine Änderung der Speicherung Kettenreaktionen auslösen. Ermitteln Sie, wer vom Schema abhängt und ob alle Beteiligten koordiniert aktualisiert werden können.
- Umkehrbarkeit: Eine Transformation beim Lesen bewahrt die Quelldaten und kann damit die Rückkehr zum vorherigen Verhalten erleichtern. Bei einer destruktiven Migration sind eine Sicherung oder ein erprobter Wiederherstellungsmechanismus sowie ein Plan für nachfolgende Änderungen erforderlich.
- Geschäftsregeln: Wenn die Umwandlung von Entscheidungen abhängt, die sich ändern können, lassen sich die ursprünglichen Daten später neu bewerten. Stellt die neue Form dagegen eine stabile, für alle notwendige Tatsache dar, kann ihre dauerhafte Speicherung das System vereinfachen.
Vergleichen Sie nicht nur die Kosten der Migration mit denen für einen Adapter. Berücksichtigen Sie auch den laufenden Aufwand: komplexere Abfragen, Beobachtbarkeit, Tests, Unterstützung älterer Versionen und die spätere Abschaffung der Kompatibilität.
Wann eine Migration sinnvoll sein kann
Eine dauerhafte Migration wird meist attraktiver, wenn das neue Modell über längere Zeit die maßgebliche Darstellung sein soll, viele Verbraucher dieselbe Umwandlung benötigen oder die Anpassungslogik die Latenz messbar beeinträchtigt. Sie kann ebenfalls die bessere Wahl sein, wenn sich die Leselogik auf mehrere Stellen verteilt hat und es keine einzige verlässliche Definition mehr gibt.
Eine Transformation beim Lesen kann dagegen sinnvoll sein, wenn die Änderung vorübergehend ist, das alte Format erhalten bleiben muss, nur wenige kontrollierte Verbraucher existieren oder die Regeln des neuen Modells noch überprüft werden. Sie ist auch hilfreich, wenn die Kosten oder Risiken einer umfassenden Schreiboperation in der Produktion den unmittelbaren Nutzen übersteigen – vorausgesetzt, die Leistung bleibt akzeptabel und die Kompatibilität ist klar begrenzt.
Es gibt Warnsignale dafür, dass eine Übergangslösung zur technischen Schuld wird: Bedingungen für jede historische Version, Abfragen, die Formate ohne gemeinsame Regel vermischen, unterschiedliche Fehler bei verschiedenen Verbrauchern und Tests, die nicht alle Varianten abdecken. Tauchen solche Anzeichen auf, genügt es nicht, einen weiteren Sonderfall hinzuzufügen. Legen Sie fest, welches Format maßgeblich ist, und bestimmen Sie einen überprüfbaren Termin oder eine Bedingung, unter der ältere Formate abgeschafft werden.
Eine schrittweise Umstellung durchführen
Eine schrittweise Migration senkt das Risiko, indem die Bereitstellung der Anwendung von der Verarbeitung sämtlicher Datensätze getrennt wird. Ein praktikabler Plan kann folgende Schritte umfassen:
- Abhängigkeiten erfassen. Ermitteln Sie Produzenten, Verbraucher, geplante Aufträge, Berichte und Integrationsverträge, die das betroffene Modell verwenden. Klären Sie, wer für jeden Bereich verantwortlich ist.
- Kompatibilität festlegen. Dokumentieren Sie, welche Formate akzeptiert werden, welche Quelle maßgeblich ist und was bei fehlenden Feldern oder unerwarteten Werten geschieht. Vermeiden Sie stillschweigende Schlussfolgerungen, die ungültige Daten verbergen.
- Kompatible Leser bereitstellen. Stellen Sie sicher, dass die Anwendung alte und neue Daten verarbeiten kann, bevor sie beginnt, das neue Format zu schreiben. So wird verhindert, dass eine ältere Version an bereits aktualisierten Datensätzen scheitert.
- Schreibvorgänge umstellen. Sorgen Sie dafür, dass neue Vorgänge das Zielformat erzeugen. Werden für eine Übergangszeit beide Darstellungen geschrieben, legen Sie fest, welche Vorrang hat und wie Abweichungen erkannt werden.
- Vorhandene Daten verarbeiten. Führen Sie die Migration kontrolliert durch und protokollieren Sie Fortschritt und Fehler. Wählen Sie für das System geeignete Chargen und gestalten Sie den Vorgang so, dass er ohne doppelte Auswirkungen fortgesetzt werden kann.
- Kompatibilität entfernen. Beenden Sie das Lesen des alten Formats erst, wenn Messwerte und Prüfungen zeigen, dass keine Verbraucher und Datensätze mehr davon abhängen.
Die genaue Reihenfolge kann variieren. Bei Systemen mit hohen Verfügbarkeitsanforderungen werden Lese- und Schreibfunktionen häufig zunächst kompatibel bereitgestellt, bevor die Daten geändert werden. Berücksichtigen Sie dabei auch ältere Versionen, die während einer Bereitstellung noch aktiv sein können.
Ergebnisse prüfen und Rückweg vorbereiten
Testen Sie die Umwandlung vor der vollständigen Migration mit repräsentativen Daten und vergleichen Sie die Ergebnisse. Prüfen Sie Datensatzanzahlen, Pflichtfelder, Grenzwerte, Beziehungen zwischen Entitäten und Geschäftsregeln. Eine identische Anzahl allein beweist nicht, dass die Transformation korrekt ist. Vergleichen Sie auch Werte und Verhalten in relevanten Fällen.
Führen Sie, sofern möglich, zunächst einen Vergleich durch, ohne das Ergebnis für Nutzer zu verändern. Protokollieren Sie Unterschiede zwischen der alten und der neuen Darstellung, ordnen Sie Abweichungen ein und legen Sie Akzeptanzschwellen fest, bevor Sie den Prozess ausweiten. Beobachten Sie Fehler, Latenz und Auslastung während des Vorgangs und bestimmen Sie, wer über eine Pause entscheidet.
Bei der Rückabwicklung müssen auch Schreibvorgänge berücksichtigt werden, die nach der Änderung stattgefunden haben. Eine ältere Sicherung einzuspielen kann gültige Aktualisierungen löschen. Klären Sie deshalb, ob sich zum alten Leser zurückkehren lässt, ohne die Daten zurückzusetzen, oder ob eine Strategie zum Abgleich von Änderungen nötig ist. Testen Sie diesen Weg, bevor Sie sich darauf verlassen.
Checkliste für die Entscheidung

- Sind das maßgebliche Format und die Quelle der Wahrheit eindeutig festgelegt?
- Wie viele Verbraucher hängen vom Schema ab, und wer ist für jeden verantwortlich?
- Wurde die Auswirkung der Transformation beim Lesen auf Latenz und Ressourcen gemessen?
- Ist die Übergangslogik zentralisiert und getestet, und gibt es klare Bedingungen für ihre Abschaffung?
- Kann die Migration angehalten und fortgesetzt werden, und lassen sich fehlgeschlagene Datensätze erkennen?
- Sind Vergleiche, Akzeptanzschwellen und Verantwortliche für die Ergebnisprüfung festgelegt?
- Gibt es eine sichere Rückabwicklung, die neue Schreibvorgänge berücksichtigt?
Wählen Sie die Transformation beim Lesen, wenn die Kompatibilität begrenzt, umkehrbar und betrieblich tragbar ist. Entscheiden Sie sich für eine Migration, wenn das neue Modell dauerhaft und einheitlich sein soll, sich einfacher nutzen lässt und ein sicherer Plan zur Aktualisierung der Daten besteht. Besteht noch Unsicherheit, setzen Sie auf eine vorübergehende Umstellung mit Messwerten, einer verantwortlichen Person und einem klaren Ausstiegskriterium: Eine Migration aufzuschieben kann eine sinnvolle Entscheidung sein; sie ohne Termin und Kontrolle aufzuschieben, macht die Kompatibilität dauerhaft.
