KI-Fallbeispiele
„Es läuft, also fassen wir es nicht an.“ Ein System, über das man das immer wieder sagte, lief, ehe man sich versah, unverändert seit 10 Jahren im Zentrum des Unternehmens – vielen Firmen dürfte das bekannt vorkommen. Diesmal berichten wir, wie ein 2016 veröffentlichtes Projektmanagementsystem,das auf einem Betriebssystem, dessen Support 2020 endete, weiterhin ins Internet freigegeben war,im laufenden Betrieb in eine moderne Umgebung migriert wurde. In 2 Arbeitstagen.3.623 Tickets und 4,0 GB Anhänge wurden ohne einen einzigen Verlust übernommen.
„Es läuft, also fassen wir es nicht an“ hatte 10 Jahre lang angehalten.
Gegenstand ist das interne Projektmanagementsystem (Redmine). Der Projektfortschritt, die Aufzeichnungen zur Störungsbehebung, der Verlauf des Austauschs mit Kunden – 10 Jahre haben sich hier angesammelt. Genau der Zustandman kann es nicht anhalten, also fasst man es nicht an.
Doch bei näherer Betrachtung des Innenlebens war der Zustand keineswegs einer, den man auf sich beruhen lassen durfte.
| Punkt | Vor der Migration | Nach der Migration |
|---|---|---|
| OS | CentOS 6.10 (Support endete 2020) | AlmaLinux 10.1 |
| Anwendung | Redmine 3.2.1 (2016) | Redmine 6.1.3 |
| Laufzeitumgebung | Ruby 2.2.4 | Ruby 3.3.10 |
| Datenbank | MySQL 5.7 | MariaDB 10.11 |
| Webserver | Apache 2.2 + Passenger | nginx 1.26 + puma |
Der Support des Betriebssystems war seit 6 Jahren beendet.Die in dieser Zeit veröffentlichten Sicherheitskorrekturen waren in keiner Weise eingespielt. Und all das lief weiter in einem von außen zugänglichen Zustand. Nicht „es läuft, also ist es sicher“, sondern„es läuft nur, geschützt ist es nicht“ ist die zutreffende Formulierung.
Es besteht darin, dass es intakt bleibt, während allein der Schutz stillsteht.
Über Erfolg oder Misserfolg der Migration war schon vor Beginn durch die Messung entschieden.
Vor Beginn der Migration erfassten wir den Ist-Zustand in Zahlen. Genau das hat im Ergebnis den Aufwand stark beeinflusst.
- Datenbank 38 MB / Anhänge 4,0 GB
- 20–30 Anfragen pro Tag =aktiv im Einsatz
- Erweiterungs-Plugins: null. Eigenes Design: keines
Die letzte Zeile war entscheidend. Worüber es bei Migrationen dieser Art am meisten Streit gibt, ist,ob die nachträglich hinzugefügten Erweiterungen in der neuen Version laufen. Laufen sie nicht, bleibt die Wahl zwischen „einen Ersatz suchen“, „auf die Funktion verzichten“ und „selbst reparieren“, und dort verschwinden mehrere Wochen. Diesmal existierte dieses Hindernis von Anfang an nicht.
Auf Basis dieser Messung haben wir vor Beginn drei Grundsätze festgelegt.
1. Wir verzichteten darauf, die Version Stufe für Stufe anzuheben
Ursprünglich hatten wir unter der Annahme geschätzt, schrittweise über 3.2 → 4.2 → 5.1 → 6.x anzuheben. Bei der Überprüfung zeigte sich jedoch, dass sich10 Jahre auf einmal überspringen und aktualisieren lässt. Der veranschlagte Aufwand entfiel damit vollständig.
2. Wir änderten den Datenbanktyp nicht
Um den Betrieb an andere Systeme anzugleichen, gab es auch die Idee, auf ein anderes Datenbankprodukt zu wechseln. Da jedoch das Datenformat der Quelle abweicht, wäre ein Konvertierungsschritt nötig.In „Daten, deren Verschwinden schwer zu bemerken ist“ – 3.623 Tickets und 6.071 Verlaufseinträge – bringen wir das Risiko einer Konvertierung nicht hinein.Der Vereinheitlichung des Betriebs zogen wir vor, dass kein einziger Datensatz fehlt.
3. Wir aktualisierten den bestehenden Server nicht direkt
Wir stellten separat einen neuen Server bereit und beschränkten die Umschaltung darauf, am Eingang eine einzige Konfigurationszeile zu ändern.Selbst bei einem Fehlschlag ist mit einer zurückgesetzten Zeile alles wie zuvor – diesen Zustand wollten wir bis zuletzt aufrechterhalten.
Was Zeit kostete, war nicht Redmine.
Ab hier beginnt die eigentliche Praxis. Reiht man die während der Migration aufgetretenen Probleme auf, zeigt sich klar eine Tendenz.
Von den acht,gehen nur drei auf Redmine selbst zurück. Und eines davon war zudem eine erfreuliche Fehleinschätzung im Sinne von „einfacher als gedacht“. Wirklich Mühe bereiteten nur zwei.
Der Rest – Generationsunterschied des Betriebssystems, Sicherheitsmechanismus, Kommunikationsweg, Verschlüsselung, Anbindung an externe Systeme –liegt ausnahmslos außerhalb der Anwendung.
Es ist die über 10 Jahre angesammelte „Differenz des Umfelds“.
„Mit einer Zeile zurücksetzbar“ bis zuletzt nicht aus der Hand geben.
Die Umschaltung besteht nur darin, das Weiterleitungsziel des Eingangsservers auf den neuen Server zu richten. Auch das Zurücksetzen ist eine Zeile. Unddie alte Umgebung haben wir nicht angehalten, sondern laufend belassen.
Am Tag der Umschaltung bestanden „die laufende alte Umgebung“ und „die laufende neue Umgebung“ nebeneinander, und wir hielten einen Zustand aufrecht, in dem sich mit einer Zeile zwischen beiden hin- und herwechseln lässt. Erst nachdem wir einige Tage später bestätigt hatten, dass keine Probleme auftraten, hielten wir die alte Seite an.
Wir beließen es nicht bei der Migration, sondern schlossen die Lücken von 10 Jahren.
In der neuen Umgebung haben wir zugleich das eingerichtet, was in der alten fehlte.
- Tägliche Sicherung (7 Generationen) – In der alten Umgebung gab es überhaupt keinen Sicherungsmechanismus
- Protokollierung der Zugriffsquelle – Vor der Migration sahen alle Zugriffe gleich aus, und es ließ sich nicht nachverfolgen, wer von wo kam
- Begrenzung der Login-Versuche – Da eine Standardfunktion fehlt, verstärkt auf der Seite des Webservers
- Automatische Aktualisierung der Quellcode-Anbindung – Die faktisch eingefrorene Anbindung aktualisiert sich nun alle 15 Minuten
Die im Ergebnis übernommenen Daten sind wie folgt. Wir haben bestätigt, dass die Anzahlen zwischen alter und neuer Umgebung vollständig übereinstimmen.
Auch die Anbindung von externen Systemen läuft ohne Konfigurationsänderung unverändert weiter.Aus Sicht der Nutzer ist lediglich der Login-Bildschirm neu – eine für eine Migration ideale Landung.
Wenn Sie sagen: „Auch wir haben denselben Server.“
Die Gründe, warum diese Migration in kurzer Zeit abgeschlossen war, lassen sich auf drei zusammenfassen.
- Es waren keine Erweiterungen installiert– deshalb ließen sich 10 Jahre auf einmal überspringen
- Wir haben vor Beginn gemessen– die Entscheidungsgrundlage lag in Zahlen bereit
- Wir hielten einen zurücksetzbaren Zustand aufrecht– so mussten wir am Tag der Umschaltung nicht auf gut Glück setzen
Umgekehrt heißt das:Diese drei lassen sich vor Beginn überprüfen.„Auf einem Server ohne Support läuft ein System, das nicht angehalten werden darf“ – kommt Ihnen das bekannt vor, dann sprechen Sie uns an, angefangen damit, den Ist-Zustand in Zahlen zu erfassen. Ob sich migrieren lässt, zeigt sich meist, wenn man es untersucht.
Wir unterstützen die Migration und Erneuerung von Geschäftssystemen, die auf Betriebssystemen ohne Support und alten Frameworks weiterlaufen.
Die Ist-Analyse (Version, Datenmenge, Vorhandensein von Erweiterungen, Freigabeumfang) ist kostenlos. Gemeinsam mit der Erneuerung von Legacy-Systemen (AI Re: Platform / kurz: AIR Platform) –Kontaktieren Sie uns jetzt.
Kontaktformular (bitte mit dem Hinweis „Beratung zur Legacy-Migration gewünscht“) / info@flagship-ai.jp
Serie „Legacy to AI – Praxisberichte“
- Gesamtüberblick: 22 Systeme und 246.000 Zeilen auf einem einzigen PC – ein messbarer Bericht über 3,5 Monate KI-Entwicklung
- Praxisbericht ①: Ein 20 Jahre altes Java-System in rund einer Woche vollständig erneuert
- Praxisbericht ②: Einen neuen Zugang zum Kernsystem schaffen, ohne eine einzige Zeile bestehenden Codes zu ändern
- Praxisbericht ③: Eine einmonatige Architekturprüfung mit einem Prototyp in 2 Tagen + echten Messungen
- Praxisbericht ④: Ein alter Mining-PC wird in 2 Tagen zum „internen privaten ChatGPT“
- Praxisbericht ⑤: Ein 10 Jahre altes System in 2 Tagen von einem Server ohne Support gerettet (dieser Beitrag)
* Die Zahlen in diesem Beitrag sind Messwerte mit Stand August 2026. Dauer und Arbeitsinhalt einer Migration variieren je nach Systemaufbau und Vorhandensein von Erweiterungen.