Zugschlusbeobachtungen

Migrationen von einem alten System auf ein neues System sind etwas, was ich besonders gut kann. Ich bekomme es immer wieder hin, mit ein wenig Planung vorab die Migration mit deutlich kürzerer Downtime hinzubekommen, als es bei der naiven Vorgehensweise wäre. Dabei habe ich wenig Angst, einen Bauzustand mit vielleicht nichtmal sechzigprozentiger Funktionalität online gehen zu lassen, wenn mich das bei der Durchführung der Restarbeiten nicht behindert - frei nach "lieber ein wenig Funktionalität als gar keine".

Da mein "Lieblings"-Firewallhersteller seine Produkte Gott sei Dank Ende 2009 aus dem Support laufen lässt, habe ich in den letzten Monaten nicht nur ein Firewallmigrationsprojekt bei und mit Endkunden durchgeführt. Dabei ist natürilch das eine oder andere schiefgelaufen, und in der folgenden Artikelreihe "Zugschlus' kleiner Migrationsleitfaden" versuche ich diese neuen oder nicht mehr ganz so neuen Erfahrungen so aufzuarbeiten, dass vielleicht auch Ihr etwas davon habt.

Entgegen der landläufigen Meinung ist eine Migration übrigens erheblich komplexer und schwieriger als die Inbetriebnahme eines ganz neuen Systems ohne Vorgänger. Bei einer Migration hat man einen Ausfall eines Dienstes, von dem vielleicht Teile der Kundenorganisation abhängen, man muss Daten übernehmen, und hat es plötzlich und akut mit Befindlichkeiten von Benutzern und kleinen Fürsten zu tun, denen Funktionalität kurzfristig (im Rahmen der Umbauarbeiten) oder langfristig (weil das neue System vielleicht manche Dinge nicht mehr kann) verloren geht. Ein Projektstopp bedeutet bei einer Migration in aller Regel weitere Arbeiten, um auf den Ursprungszustand zurückzukommen, während man bei einer Neueinführung einfach alles stehen lassen kann.

Die Artikel sind mit "zkmlf" getagged und können jederzeit gesammelt aufgerufen werden. Es gibt auch einen RSS feed.