FACHWISSEN · AUTOMATISIERUNG & TRANSFORMATION

Systemmodernisierung in Etappen: Die unterschätzte Rolle der Datenhoheit

Ein Altsystem muss nicht immer in einem einzigen Termin vollständig ersetzt werden. Eine schrittweise Modernisierung kann einzelne Funktionen nacheinander verlagern. Sie reduziert jedoch nur dann Risiken, wenn klar bleibt, welches System für welche Daten und Entscheidungen zuständig ist.

Funktionen gezielt aus dem Bestand lösen

Ein bekanntes Architekturprinzip lässt alte und neue Funktionen während einer Übergangszeit nebeneinander bestehen. Anfragen werden schrittweise auf neue Komponenten gelenkt. Das kann die Umstellung kleiner machen, erzeugt aber vorübergehend zusätzliche Schnittstellen und Betriebsaufgaben.

Aus dem Prinzip folgt nicht, dass jede Modernisierung zwingend Microservices benötigt. Auch ein klar abgegrenztes Modul oder ein neuer Dienst für einen einzelnen fachlichen Bereich kann eine überprüfbare Etappe bilden. Die technische Form muss zum Vorhaben passen.

Ein konkretes Übergangsszenario

Ein fiktiver Betrieb möchte die Angebotsbearbeitung modernisieren, während Auftragsabwicklung und Stammdaten zunächst im Bestand bleiben. Die neue Oberfläche darf Angebote erstellen, liest Kundendaten aber aus dem führenden System. Für Änderungen an diesen Stammdaten bleibt zunächst der bisherige Weg zuständig.

Würden beide Systeme dieselbe Adresse unabhängig ändern, entstünden Konflikte. Deshalb wird je Datenbereich festgelegt, wo Änderungen erfolgen dürfen, wie sie verteilt werden und welcher Stand bei einem Widerspruch maßgeblich ist. Die Übergangsarchitektur braucht damit ebenso fachliche Regeln wie die Zielarchitektur.

Der Zwischenzustand ist ein eigenes Produkt

Während der Koexistenz müssen Überwachung, Fehlerbehandlung und Zuständigkeiten beide Welten abdecken. Ein neuer Prozess kann technisch gesund aussehen, obwohl seine Datenübernahme aus dem alten System seit Stunden verzögert ist. Reine Verfügbarkeitsprüfungen reichen daher nicht aus.

Für jede Etappe sollte eine Abschlussbedingung vorliegen. Beispielsweise: Alle neuen Angebote werden im neuen Modul angelegt, relevante Altangebote bleiben lesbar, die Übernahme ist abgeglichen und der alte Schreibzugang ist für diesen Funktionsbereich nicht mehr nötig. Konkrete Kriterien verhindern einen unbegrenzten Dauerbetrieb zweier Lösungen.

Rückfallmöglichkeiten realistisch bewerten

Eine Anfrage wieder auf die alte Oberfläche zu lenken ist etwas anderes, als inzwischen im neuen System erzeugte Daten zurückzuführen. Vor dem Umschalten ist deshalb zu prüfen, welche Änderungen reversibel sind und welcher Abgleich für einen Rückfall erforderlich wäre.

Eine Modernisierung in Etappen verteilt Aufwand und Erkenntnisgewinn. Sie ersetzt weder eine saubere Schnittstellenplanung noch Tests. Ihr Vorteil liegt in kleineren überprüfbaren Übergängen, deren Wirkung fachlich und technisch nachvollzogen werden kann.

A legacy system does not always need to be replaced completely at a single cutover. Incremental modernisation can move individual functions one at a time. It only reduces risk, however, when responsibility for data and decisions remains clear.

Move defined functions out of the existing system

A well-known architecture pattern allows old and new functions to coexist during a transition. Requests are gradually directed to new components. That can make each change smaller, but temporarily creates additional interfaces and operational work.

The principle does not mean every modernisation requires microservices. A clearly bounded module or a new service for one business area can also be a verifiable stage. The technical form needs to fit the initiative.

A concrete transition scenario

A fictional business wants to modernise quotation handling while order processing and master data initially remain in the existing system. The new interface may create quotations but reads customer data from the authoritative system. Changes to that master data still use the established route.

If both systems independently changed the same address, conflicts would arise. For each data area, define where changes may be made, how they are distributed and which state takes precedence in a disagreement. The transition architecture needs business rules just as the target architecture does.

The intermediate state needs its own design

During coexistence, monitoring, error handling and responsibilities must cover both worlds. A new workflow may look technically healthy even when its data transfer from the old system has been delayed for hours. Availability checks alone are therefore insufficient.

Define an exit condition for each stage. For example: all new quotations are created in the new module, relevant older quotations remain readable, the transfer has been reconciled and the old write path is no longer needed for that function. Specific criteria prevent two solutions from running indefinitely.

Assess recovery realistically

Routing a request back to the old interface is different from transferring data created in the new system back to the old one. Before cutover, establish which changes are reversible and what reconciliation a rollback would require.

Incremental modernisation spreads effort and learning over time. It does not replace sound interface planning or testing. Its benefit is smaller, verifiable transitions whose technical and business effects can be traced.

Un sistema legacy non deve sempre essere sostituito interamente in un unico passaggio. Una modernizzazione graduale può spostare una funzione alla volta. Riduce però i rischi soltanto se rimane chiaro quale sistema sia responsabile dei diversi dati e delle decisioni.

Separare funzioni definite dal sistema esistente

Un noto modello architetturale permette a funzioni vecchie e nuove di coesistere durante la transizione. Le richieste vengono indirizzate gradualmente ai nuovi componenti. Ogni cambiamento può così essere più piccolo, ma temporaneamente aumentano interfacce e attività operative.

Il principio non significa che ogni modernizzazione richieda microservizi. Anche un modulo ben delimitato o un nuovo servizio per un singolo ambito operativo può rappresentare una fase verificabile. La forma tecnica deve essere adatta all’iniziativa.

Uno scenario concreto di transizione

Un’impresa ipotetica vuole modernizzare la gestione delle offerte, lasciando inizialmente nel sistema esistente ordini e dati anagrafici. La nuova interfaccia può creare offerte, ma legge i dati dei clienti dal sistema di riferimento. Per modificarli rimane inizialmente responsabile il percorso consolidato.

Se entrambi i sistemi modificassero indipendentemente lo stesso indirizzo, sorgerebbero conflitti. Per ogni area di dati si definisce quindi dove possano avvenire le modifiche, come vengano distribuite e quale stato prevalga in caso di disaccordo. L’architettura di transizione richiede regole operative quanto quella finale.

Lo stato intermedio richiede una progettazione propria

Durante la coesistenza, monitoraggio, gestione degli errori e responsabilità devono coprire entrambi gli ambienti. Un nuovo flusso può sembrare tecnicamente sano anche se il trasferimento dei dati dal vecchio sistema è in ritardo da ore. I soli controlli di disponibilità non bastano.

Ogni fase richiede una condizione di completamento. Per esempio: tutte le nuove offerte sono create nel nuovo modulo, quelle precedenti rilevanti rimangono leggibili, il trasferimento è stato riconciliato e il vecchio percorso di scrittura non è più necessario per quella funzione. Criteri concreti impediscono di mantenere due soluzioni indefinitamente.

Valutare realisticamente il ritorno alla situazione precedente

Reindirizzare una richiesta alla vecchia interfaccia è diverso dal riportare nel vecchio sistema i dati creati nel nuovo. Prima del passaggio si deve quindi stabilire quali modifiche siano reversibili e quale riconciliazione richiederebbe un ritorno.

La modernizzazione per fasi distribuisce nel tempo impegno e apprendimento. Non sostituisce una buona pianificazione delle interfacce né i test. Il vantaggio consiste in transizioni più piccole e verificabili, i cui effetti tecnici e operativi possono essere ricostruiti.

Un sistema heredado no siempre tiene que sustituirse por completo en un único cambio. Una modernización gradual puede trasladar funciones una a una. Sin embargo, solo reduce riesgos cuando sigue estando claro qué sistema es responsable de cada dato y decisión.

Separar funciones definidas del sistema existente

Un patrón de arquitectura conocido permite que funciones antiguas y nuevas convivan durante una transición. Las solicitudes se dirigen gradualmente a componentes nuevos. Esto puede reducir el tamaño de cada cambio, pero crea temporalmente interfaces y tareas operativas adicionales.

El principio no significa que toda modernización necesite microservicios. Un módulo claramente delimitado o un servicio nuevo para un área de negocio también puede ser una etapa verificable. La forma técnica debe ajustarse a la iniciativa.

Un escenario concreto de transición

Una empresa hipotética quiere modernizar la gestión de ofertas mientras los pedidos y los datos maestros permanecen inicialmente en el sistema existente. La nueva interfaz puede crear ofertas, pero lee los datos de clientes del sistema de referencia. Los cambios en esos datos siguen utilizando de momento la vía establecida.

Si ambos sistemas modificaran de forma independiente la misma dirección, surgirían conflictos. Por ello, para cada ámbito de datos se define dónde pueden realizarse cambios, cómo se distribuyen y qué estado prevalece en caso de discrepancia. La arquitectura de transición necesita reglas de negocio igual que la arquitectura objetivo.

El estado intermedio necesita su propio diseño

Durante la coexistencia, la supervisión, la gestión de errores y las responsabilidades deben cubrir ambos entornos. Un flujo nuevo puede parecer técnicamente sano aunque la transferencia de datos desde el sistema antiguo lleve horas retrasada. Por ello no bastan las comprobaciones de disponibilidad.

Cada etapa necesita una condición de finalización. Por ejemplo: todas las ofertas nuevas se crean en el módulo nuevo, las antiguas relevantes siguen siendo legibles, la transferencia está conciliada y la vía antigua de escritura ya no es necesaria para esa función. Los criterios concretos evitan mantener dos soluciones indefinidamente.

Evaluar de forma realista la vuelta atrás

Redirigir una solicitud a la interfaz antigua no es lo mismo que devolver al sistema anterior los datos creados en el nuevo. Antes del cambio debe determinarse por tanto qué modificaciones son reversibles y qué conciliación requeriría una reversión.

La modernización por etapas distribuye el esfuerzo y el aprendizaje en el tiempo. No sustituye una planificación adecuada de interfaces ni las pruebas. Su ventaja está en transiciones más pequeñas y verificables cuyos efectos técnicos y de negocio pueden rastrearse.