Kostenbewertung vor einem Tool-Wechsel: sechs Prüfungen und ein Übergang in drei Phasen

Ein Wechsel des Tools zur Umgebungsverwaltung wirkt auf den ersten Blick einfach: Software installieren und Daten exportieren.

Zeit kostet jedoch vor allem das, was im Alltag leicht übersehen wird: Lassen sich die Zuordnungen zwischen Dutzenden von Konten und Umgebungen übernehmen? Müssen Umgebungskonfigurationen komplett neu aufgebaut werden? Gelten die bisherigen Arbeitsabläufe des Teams weiter? Kann die alte Umgebung wirklich am selben Tag abgeschaltet werden? Wenn diese Fragen in der Entscheidungsphase nicht geklärt sind, führt die Migration schnell zu Nacharbeit.

Zuerst prüfen, ob Konten und Umgebungen korrekt zugeordnet werden können

Migriert werden nicht die Zugangsdaten an sich, sondern die gesamte Zuordnung: Welches Konto läuft in welcher Umgebung und welcher Netzwerk-Ausgang ist an diese Umgebung gebunden? Lässt sich diese Zuordnung nicht exportieren, muss sie bei der Migration manuell neu aufgebaut werden. Bei Dutzenden oder Hunderten von Konten sind Fehler dann nahezu unvermeidlich.

Die Prüfung ist einfach: Sehen Sie sich im alten Tool die Exportfunktion an und kontrollieren Sie, ob die exportierten Felder Umgebungskennungen und Netzwerkkonfigurationen enthalten. Werden nur Konten und Passwörter exportiert, hilft der Export für die eigentliche Zuordnung kaum weiter.

Umgebungskonfigurationen neu aufbauen statt kopieren

Fingerprint-Parameter, Zeitzone und Sprache sowie der gebundene Netzwerk-Ausgang bilden den Kern einer Umgebung. Die Parametersysteme verschiedener Tools sind jedoch nicht direkt kompatibel. Wer versucht, jeden Wert einzeln zu übertragen, stellt oft fest, dass Angaben fehlen oder nicht sauber zusammenpassen.

Praktischer ist es, die beabsichtigte Konfiguration zu dokumentieren, etwa Region USA, Windows-System und eine bestimmte Hardwareklasse, und die Umgebung im neuen Tool anhand dieser Vorgaben neu aufzubauen. Ziel ist eine in sich stimmige, nutzbare Umgebung und keine exakte Kopie der alten.

Cookies und Anmeldestatus

Bei Konten, die angemeldet bleiben müssen, entscheidet die Übertragbarkeit des Sitzungsstatus darüber, ob nach der Migration eine erneute Anmeldung nötig ist. Ein leicht übersehener Punkt: Wenn sich Dutzende Konten am selben Tag neu anmelden, ist das bereits ein auffälliges Muster. Die Umstellung sollte daher zeitlich gestaffelt und nicht auf einmal durchgeführt werden.

Ist die Bindung des Netzwerk-Ausgangs kompatibel?

Wenn der Ausgang an eine Umgebung gebunden ist, muss geprüft werden, ob das neue Tool dasselbe Protokoll und dieselbe Bindungsmethode unterstützt. Ist das nicht der Fall, muss die gesamte Netzwerkkonfiguration neu erstellt werden. Dieser Aufwand gehört bereits in die Migrationsplanung.

Werden die Arbeitsgewohnheiten des Teams unterbrochen?

Sind die Berechtigungsmodelle vergleichbar? Können Teammitglieder arbeiten, ohne Passwörter untereinander weiterzugeben? Sind Aktivitätsprotokolle weiterhin verfügbar? Diese drei Punkte bestimmen, wie viel Lern- und Umstellungsaufwand für das Team entsteht. Je größer das Team, desto höher die Kosten.

Sollte die alte Umgebung noch eine Zeit lang bestehen bleiben?

Eine Migration muss nicht in einem einzigen Schritt abgeschlossen werden. Die alte Umgebung noch einige Wochen verfügbar zu halten, ist oft wertvoller als erwartet: Sie dient als Vergleich zur neuen Umgebung, hilft bei Problemen mit einzelnen Konten während der Migration und bietet einen Rückfallpunkt, falls im neuen Tool unerwartete Schwierigkeiten auftreten.

Den Übergang planen

In den ersten ein bis zwei Wochen sollten zunächst fünf bis zehn weniger kritische Konten testweise migriert und der gesamte Geschäftsprozess durchlaufen werden. Dabei geht es darum zu prüfen, ob das neue Tool reale Arbeitslasten bewältigt, nicht darum, wie lang seine Funktionsliste ist.

Darauf folgt eine Beobachtungsphase von zwei bis vier Wochen. Die operativen Abläufe bleiben möglichst nah am bisherigen Vorgehen, während Stabilität der Konten, Häufigkeit von Verifizierungen und Erfolgsquote von Aufgaben auf beiden Seiten verglichen werden. Schneidet die neue Umgebung in dieser Phase deutlich schlechter ab, sind die Kosten eines Rückfalls noch niedrig.

Anschließend erfolgt die Migration in Gruppen nach geschäftlicher Bedeutung. Neuanmeldungen innerhalb derselben Gruppe sollten nicht alle zum gleichen Zeitpunkt stattfinden. Während der Migration sollten außerdem möglichst keine weiteren Variablen geändert werden, etwa gleichzeitig die Inhaltsstrategie. Andernfalls lässt sich bei Problemen kaum feststellen, wodurch sie verursacht wurden.

Häufige Fehlentscheidungen

Eine Migration nur anhand des Softwarepreises zu entscheiden, bedeutet, sichtbare Kosten mit den Gesamtkosten zu verwechseln. Personalaufwand, Schwankungen im Geschäft während des Übergangs und mögliche Kontoverluste übersteigen zusammen häufig die eingesparten Lizenzkosten.

Ein weiterer Fehler ist eine Migration um der Migration willen. Wenn das bestehende Tool die Anforderungen erfüllt, rechtfertigen zusätzliche Funktionen eines neuen Tools allein den Wechsel oft nicht. Zuerst sollte klar benannt werden, wo das aktuelle Tool konkret an Grenzen stößt, und anschließend geprüft werden, ob das neue Tool genau diese Probleme löst.

Am riskantesten ist es, alle Konten gleichzeitig umzustellen. Damit konzentriert sich das gesamte Risiko auf einen einzigen Zeitpunkt. Tritt dann ein Problem auf, bleibt keine Ausweichmöglichkeit.

Vor der Entscheidung drei Fragen beantworten

Welche konkreten Probleme gibt es mit dem aktuellen Tool? Die Antwort sollte sich auf konkrete Szenarien beziehen und nicht nur auf ein allgemeines Gefühl. Kann das neue Tool diese Probleme nachweislich lösen, idealerweise bereits in der Testmigration? Und was kostet ein Fehlschlag der Migration: Ist ein Rückfall möglich und wie lange würde er dauern?

Erst wenn alle drei Fragen klar beantwortet sind, sollte die Migration beginnen.