IT-Administrator: IT-Verantwortliche beschreiben im Rahmen einer Migration die unternehmensinterne Kommunikation oft als größere Herausforderung als die Umstellung der Systeme selbst – deckt sich das mit Ihren Erfahrungen?

Jan Kappen: Technisch lässt sich in der Tat viel realisieren, doch die Frage ist oft eher, wer im Unternehmen möchte welchen Aspekt sehen, beziehungsweise was ist gewollt, denn häufig hat die Geschäftsführung andere Ziele als die IT und auch als die Anwender. Gerade die Nutzer werden häufig außen vor gelassen und vor vollendete Tatsachen gestellt. Das erzeugt Unzufriedenheit oder gar Frustration. Grundsätzlich führt zu wenig Kommunikation zwischen den Fachabteilungen im Unternehmen zu schlechteren Ergebnissen. Hier ist es oft so, dass Abteilungsleiter A nicht versteht, warum die IT etwas macht, weil Abteilungsleiter B diese Anforderung hat. Zu erklären, warum Dinge passieren und grundsätzlich eine gemeinsame Zielvorstellung "auszurollen", ist hier entscheidend.

Wie würden Sie Best Practices für diese Kommunikation der Fachabteilungen im Rahmen einer Migration beschreiben?

Evgenij Smirnov: Als Erstes gilt es, das Ziel, sprich den Treiber der Migration, klar zu formulieren: Warum wird diese Umstellung angestrebt? Wer hat diese neue Anforderung formuliert? Dies ist wichtig, denn die Erfahrung zeigt, dass Menschen mit unterschiedlichem technischen Wissen sich unter ein und demselben Punkt völlig unterschiedliche Dinge vorstellen. Hier ist es Pflicht, sich noch vor dem Projektstart auf eine einheitliche Terminologie zu einigen. Selbst in meinem persönlichen, technisch sehr engen Spezialgebiet des Identity Managements, sind sich technisch versierte Personen oft nicht einig, was zum Beispiel so eine einfache Aussage wie "Der User ist migriert" in der Praxis bedeutet.

Kappen: Aus Beratersicht ist es ideal, möglichst früh einbezogen zu werden, also an dem Punkt der "Begriffsdefinition", der gerade fiel. Das ist aber nicht immer der Fall, etwa wenn der Auslöser des Projekts ein Supportfall ist, zu dem ich gerufen werde. Ideal ist es natürlich, wenn der Consultant eine Firma dauerhaft betreut. Er kennt dann die IT, die Geschäftsführung und auch die User – das ist aus meiner Sicht eine wünschenswerte Best Practice, die jedoch wie angesprochen nicht die Regel ist.

Ohne den Segen des Betriebsrats ist eine Migration extrem schwer

Und wie holt der IT-Verantwortliche Endanwender am besten für ein Migrationsprojekt ab?

Kappen: Meine Erfahrung lehrt mich, dass es unmöglich ist, alle User sofort mit ins Boot zu holen. Vielmehr hat es sich bewährt, gezielt mit ausgewählten Mitarbeitern, die aus verschiedenen Hierarchiestufen stammen, zu sprechen. Das Stichwort ist hier "Key User" – also Personen aus den Fachabteilungen, die technisch versiert und auch meinungs- und kommunikationsstark sind. Richtig eingesetzt können solche "Mitspieler" des IT-Verantwortlichen das Projekt in ihrer Abteilung, aber auch an der Kaffeemaschine, positiv beeinflussen. Diesen Punkt kann ich nur besonders betonen, zumal diese Personen, wenn die IT Endanwender nicht einbezieht, nicht selten zu Gegenspielern der Migration werden können.

Smirnov: In Sachen Enduser ist es auch zentral, eine möglicherweise vorhandene Mitarbeitervertretung anzusprechen. Ohne den Segen des Betriebsrats tut sich die IT extrem schwer eine Migration durchzuführen, die den Nutzer betrifft. Davon abgesehen kann ich nur die Wichtigkeit des von Jan Kappen erläuterten Key-User-Konzepts unterstreichen. Wichtig für den Admin ist aber auch, stets zu bedenken, dass selbst die wohlmeinendsten Key-User-Aussagen, beispielsweise zur Nutzung einer Anwendung, machen, die technisch einfach nicht stimmen. Um die Verifizierung des Feedbacks auf technischer Ebene kommt die IT nicht herum.

Was war das schlimmste Skelett im Schrank, sprich eine technische Altlast, das Sie im Rahmen einer Systemumstellung entdeckt haben?

Kappen: Wo soll ich da anfangen? Was ich ganz häufig sehe, sind veraltete, nicht dokumentierte Systeme. Umgebungen, wo niemand mehr weiß, was passiert, wenn sie nicht laufen. Manchmal läuft IT auch zu stabil, das ist durchaus ein Problem und endet häufig in "Wir fahren es mal runter und gucken, ob einer schreit". Da ist selbst Windows Server 2000 nicht selten anzutreffen, auf dem alte Oracle-Datenbanken von vor 15 Jahren laufen. Im schlimmsten Fall auf Hardware betrieben, die seit zehn Jahren nicht mehr im Support ist und dennoch bildet dieses Konstrukt das Herzstück der Warenwirtschaft. Gerade in größeren Umgebungen lässt sich dafür aber auch keine Verantwortung definieren, denn die Kollegen wechseln durch und irgendwann kennt niemand mehr besagte System wirklich.

Smirnov: Ich habe in den Jahren 2011 bis 2014 sehr viele Exchange-Migrationen gemacht, von 2003 auf 2010, später dann auch 2013. Und ich würde sagen, bei Unternehmen ab einer bestimmten Größe war in sechs von zehn Fällen Exchange 5.5 dabei – zum Teil noch produktiv und bei der anderen Hälfte zwar ausgeschaltet, aber nie wirklich entsorgt. Das war natürlich dann sofort migrationsverhindernd und vor dem Hintergrund eines knappen Zeitplans, etwa aufgrund von Wartungsfenstern, war das dann immer sehr spannend. Weil das dann plötzlich Changes sind, die in eine ganz andere Richtung gehen, als die, die für die Migration vorgesehen waren.

Ein Beispiel aus jener Zeit war eine Exchange-Migration bei einem Finanzdienstleister, bei der zwei Tage vor der geplanten Umstellung die Nummerierung der Logs bei einer Datenbankgruppe aufgebraucht war. Deshalb mussten Logs von 0000 bis FFFF gerollt werden – etwas, das die IT nicht jeden Tag durchführt. Zudem hatten die Kollegen vor Ort seit Wochen Kenntnis dieser Logs und haben nichts unternommen. Und so mussten wir diese Operation dann außerhalb jeglicher Wartungsfenster im laufenden Betrieb durchführen. Das ist zwar nichts Schlimmes, aber es waren halt 2000 Postfächer eine Zeitlang offline. Und ein solcher, ungeplanter Change in einer regulierten Branche schlug dann schon Wellen.

Welche Rolle spielt Schatten-IT für Migrationen?

Kappen: Es kommt sehr häufig vor, dass bei Änderungen oder bei Migrationen Dienste einzelner Benutzer oder Abteilungen auftauchen, die überhaupt nicht auf dem Schirm waren. Die Auswirkungen variieren dabei natürlich sehr. Ein ganz einfacher Fall ist das Speichern von Dokumenten auf dem lokalen Endgerät. Dann legt der Admin im Rahmen einer Migration ein neues Profil an und die Dokumente sind erstmal weg. Das führt zu großem Geschrei der Nutzer, obwohl eine Policy besagt, wichtige Dokumente sind auf dem Fileserver abzulegen, weil nur dort ein Backup erfolgt.

Smirnov: Sehr "beliebt" sind auch App- Empfehlungen aus der Familie, die ein Anwender installieren konnte, weil die IT ihm vor 15 Jahren lokale Adminrechte auf seinem Client gegeben und nie weggenommen hat. Nun basiert der komplette Workflow auf dieser Anwendung und die Migration macht dies zunichte. Ich würde sogar sagen, dass dies künftig noch schlimmer wird wegen den KI-Systemen der Nutzer. Speziell trifft dies auf Identitätsmigrationen zu, bei denen plötzlich Claims und Integrationen weg sind, von denen nie jemand wusste.

Und das hat noch ganz andere Auswirkungen, als dass die Mitarbeiter kurz arbeitsunfähig werden – Stichwort Datensouveränität. Hier muss die Geschäftsleitung Standfestigkeit gegenüber den Arbeitnehmern zeigen und sagen "Wir sehen darüber hinweg, dass ihr Schatten-IT betrieben habt, aber jetzt endet das!" Doch bei weitem nicht jede Geschäftsleitung hat diese Stärke.

KI verschärft das Problem von Schatten-IT

Bieten sich der IT im Rahmen eines Migrationsprojekts auch Optionen, andere Themen zu optimieren, die vielleicht nur randläufig sind? Also zum Beispiel die Sicherheit.

Kappen: Ja, es ist nicht selten so, dass ein Migrationsprojekt ein Starter für andere Themen ist. Ich war zum Beispiel zuletzt in einem Projekt, wo es sich herauskristallisierte, dass es sinnvoll ist, das AD anzuheben, ein Tiering-Modell einzuziehen und eine Netzwerksegmentierung – was alles nicht Teil des eigentlichen Projekts war. Das hatte natürlich seinen Preis, doch die Geschäftsleitung war sehr affin, was das Thema IT und auch Sicherheit angeht und hat die Investition durchgewunken. So wurde aus einer gewachsenen Infrastruktur, die 25 Jahre lief, eine deutlich sicherere Umgebung. Das ist aber natürlich ein sehr positives Beispiel. Aber es gibt auch die andere Seite, wo die Verantwortlichen bei jeder Empfehlung sagen: Nein, das ist nicht projektrelevant, wird nicht gemacht. Oft findet sich auch ein Mittelweg, wo sich mit überschaubarem Aufwand gewisse Zusatzaspekte einbauen lassen.

Smirnov: Ich würde dem noch zwei Gedanken hinzufügen: Zum einen muss ich als Berater auch in der Lage sein zu argumentieren, dass die Migration gewisser Systeme keinen Sinn ergibt. Beziehungsweise den Beteiligten zu verdeutlichen, dass die von ihnen angestrebte Umstellung auf einem falschen Verständnis der jeweiligen Technologie beruht. Was zusätzliche Aspekte bei einer Migration betrifft, ist neben mehr Sicherheit oder anderen technischen Finessen auch ein gutes Argument zu sagen: "Wollt ihr die Straße alle drei Jahre aufreißen, oder jetzt einmal richtig tief buddeln und dann ein Fundament bauen, dass 25 Jahre trägt?" Vernünftig argumentiert kommt so etwas in der Regel gut bei der IT und Geschäftsführung, aber auch bei der Beschäftigtenvertretung an.

Kappen: Den ersten Punkt kann ich nur unterstützen: Ich habe häufig erlebt, dass Abteilungen oder gewisse Führungspersonen Dinge haben wollten, weil "es gerade so gemacht wird". Cloud war so ein Riesenthema, gerade ist es KI. Jeder sieht es, es ist omnipräsent und dann wird halt irgendwas migriert. Mein bemerkenswertester Fall aus diesem Umfeld war eine IT-Abteilung, die PBytes an Daten in Azure hosten wollte, indem sie den zentralen Fileserver in ein Azure-Rechenzentrum umzieht. Auf meine Frage nach der Sinnhaftigkeit bekam ich die Antwort, dass der Geschäftsleiter gehört habe, das sei jetzt so üblich.

Trotz Rollback-Szenario gibt es in der Praxis von Migrationen oft einen "Point of no Return" – was sich natürlich widerspricht. Wie sind Ihre Erfahrungen im Umgang mit solchen Rollbacks?

Kappen: Die übliche Planung beschreibt immer bis zu einem gewissen Punkt Möglichkeiten, zurückzugehen. So hat die IT, sollte irgendwas unerwartet nicht funktionieren, eine gewisse Absicherung. Gleichzeitig gibt es aber irgendwann diesen Punkt, wo das Unternehmen letztendlich durchziehen muss. Zum Beispiel, wenn wir über Hardware sprechen: Systeme werden ja nicht immer komplett neu angeschafft, ein Teil ist recycelt, neu installiert und wieder in Betrieb genommen. Da ist es nur logisch, dass es zu einem gewissen Zeitpunkt nicht mehr zurück geht. Und das ist durchaus kritisch, denn treten nun Probleme auf, macht sehr schnell die Schuldfrage die Runde. Doch oft gibt es keinen Schuldigen, es ist einfach der Situation bedingt – so entsteht Frustration im Projekt.

Vielen Dank für das Gespräch.

Weitere spannende Artikel rund um IT-Migration finden Sie in Ausgabe 06/26

IT-Administrator Juni 2026: Migration & Transformation

Nichts ist so beständig wie der Wandel – gerade in der IT. Im Juni dreht sich IT-Administrator deshalb um den Schwerpunkt "Migration & Transformation". Darin werfen wir unter anderem einen Blick auf die Umwälzungen, die uns die künstliche Intelligenz in der Arbeitswelt beschert. Außerdem schauen wir uns den Dauerbrenner der IPv6-Migration an und wie sich Hyper-V-Hosts auf Windows Server 2025 umziehen lassen.

Bestellen Sie hier das Einzelheft – gedruckt oder digital. 
Abonnenten finden alle Artikel außerdem im Heftarchiv.