Migrationsleitfaden Version 3.0

Administration, mehr Schulungsbedarf und unzureichenden Support entgegenstehen,
haben keine Gültigkeit.
Aufwand für Support, Wartung und Pflege der Software hängen von den jeweiligen Systemen
und ihrer Nutzung ab, wie oft und welche Änderungen und Erweiterungen an Konfiguration,
Aufbau und Funktionalitäten durchgeführt werden müssen, welche Tools und
welches Know-how zur Verfügung stehen, wie die verfügbaren Lizenzmodelle gestaltet
sind, ob Lizenzkosten anfallen und unter welchen Bedingungen und in welcher Höhe.
Diese und noch viel mehr Faktoren sind ausschlaggebend für die Folgeaufwendungen
eines gewählten Migrationspfades.
Dies macht deutlich, dass prinzipiell alle sinnvollen und machbaren Varianten hinsichtlich
der Wirtschaftlichkeit zu prüfen sind, wobei die mittel- bis langfristigen Folgekosten so
gut und umfassend wie möglich zu berücksichtigen sind.
In diesem Zusammenhang wird empfohlen, auch einen Blick auf die in diesem Leitfaden
diskutierten strategischen Aspekte zu werfen (siehe I.A 1) und die Aspekte der Herstellerabhängigkeit
und der Verwendung von offenen Standards bei der Prüfung dringend zu
berücksichtigen.
2.2.2 Nachfolgender Migrationsbedarf
Nicht selten legt bereits die aktuell durchgeführte Migration einen Grundstein für die
Nachfolgende. Das gilt natürlich besonders für die Migrationspfade, an deren Ziel ein
bestimmtes Produkt eines Herstellers steht.
Da es im Interesse des Herstellers liegt, auch die Folgeversionen seiner Produkte zu
verkaufen, wird zwangsläufig der Support für ein bestimmtes Produkt nach einem gewissen
Zeitraum eingestellt. Dieser grundsätzlich abzusehende Migrationsbedarf wird noch
dadurch zusätzlich ungünstig beeinflusst, dass durch den kommerziellen Charakter der
herstellerspezifischen Produkte auch der zeitliche Abstand zwischen den Migrationen
sowie der Umfang der einzelnen Migrationen fast vollständig außerhalb der eigenen
Kontrolle liegt.
Eine erneute Migration wird also dann notwendig, wenn das gewählte Produkt nicht
mehr weiterentwickelt wird. Diese Situation kann auch bei Open Source Software eintreten,
zum Beispiel durch eine Abnahme des Interesses bei den Entwicklern und der nachfolgenden
Auflösung der entsprechenden OSS-Entwicklergemeinde. Die Erfahrungen
zeigen jedoch, dass erfolgreiche OSS-Projekte langfristig bestehen, auch wenn vielleicht
einzelne Entwickler aus dem Kernteam sich anderen Interessen zuwenden. In den meisten
Fällen findet sich Ersatz.
Darüber hinaus kann man dem entgegen wirken, indem man einen geeigneten und zuverlässigen
Support-Partner verpflichtet und im Vorfeld die Bestandsfähigkeit und Zuverlässigkeit
der Entwicklergemeinde prüft, so wie man dies auch bei der Beschaffung von
proprietärer Software durch Prüfung der Leistungsfähigkeit des Dienstleisters und des
Softwareherstellers tut.
2.2.3 Auswirkungen auf spätere Migrationen
Wird eine Migrationsentscheidung aufgrund der Tatsache getroffen, dass nur ein bestimmtes
proprietäres Produkt die Anforderungen vollumfänglich erfüllt, ist es offensich-
Seite 146