Migration in Richtung Cloud: Welche Risiken gibt es und wie gehen wir damit um?

Auch bei der Migration in die Cloud gelten wie bei anderen Projekten die „üblichen“ Risiken mit den für gewöhnlich durchaus bekannten Gegenmaßnahmen. Dabei handelt es sich zum Teil um echte Risiken, welche man durch klassisches Risiko-Management in den Griff bekommen kann. Zum anderen betrifft es Auswirkungen, welche auf einer unzureichenden Planung beruhen. Letztere lassen sich größtenteils vermeiden, wenn man den Umfang und den Schwierigkeitsgrad der verschiedenen Projektaufgaben bereits von Beginn an realistisch einschätzt und sowohl die finanzielle-, als auch die zeitliche Planung des Migrationsprojektes danach ausrichtet. Wir werfen einen genaueren Blick auf mögliche Risiken und Gegenmaßnahmen.

Neben den allgemeinen Risiken, welche prinzipiell für jedes Projekt in Frage kommen, gibt es eine Reihe von speziellen Risiken und Fallstricken, welche insbesondere bei Migrationen in die Cloud verstärkt auftreten können. Deshalb sollte man sie im Risiko-Management bereits von Anfang an ausreichend berücksichtigen.

Dieser Beitrag befasst sich neben typischen Risikofeldern auch mit speziellen, die man für erfolgreiche Migrationen in die Cloud berücksichtigen muss. Wir beginnen mit den klassischen Risiken, die eine hohe Eintrittswahrscheinlichkeit haben. Nach und nach erweitern wir unsere Risikoliste dann um Themen, die mit den Bedingungen in der Cloud und mit den Schwierigkeiten bei der Migration dorthin auftreten.

Der Projektumfang wird unterschätzt 

Gründe dafür sind:

• unzureichende Mengengerüste
• eine Datenmenge, die sich während des Projektes noch stark vergrößert (Migrationsprojekte gehen oft über einen Zeitraum von mehreren Monaten oder gar Jahren)
• Ausgelassene Arbeitsschritte aufgrund unzureichender Kenntnis der ursprünglichen Umgebung
  

Die Budget- und Deadline-Risiken lassen sich praktisch immer durch eine adäquate Vorbereitung und Prognostik bei den Schätzungen minimieren. Weiterhin ist Erfahrung der entscheidende Schlüssel zum Erfolg. Nur wenn man den Verlauf von vergleichbaren Projekten kennt, hat man eine Chance, Umfang und zeitlichen Verlauf realistisch einzuschätzen.

Mangelnde Kommunikation 

• Aufgrund der üblicherweise großen Anzahl an Arbeitspaketen ist eine intensive Kommunikation sowohl zwischen den Projektteilnehmern als auch zu den Anwendern wichtig.
• Fehlende positive Darstellung des Migrationsergebnisses gegenüber den Endanwendern (mangelnde Akzeptanz)
  

Die Kommunikation sollte durch eine eigenständige Kommunikationsplanung berücksichtigt werden. Der Anteil des Projektmanagements im Verhältnis zu den Arbeitspaketen ist typischerweise relativ hoch. Darüber hinaus ist ein aktives Projekt-Marketing hilfreich.

Probleme bei der Umsetzung aufgrund unzureichender Trainings für die Projekt-Beteiligten

• Fehler bei der Bedienung von Tools
• Nicht alle Abhängigkeiten werden in Skripten und Konfigurationen berücksichtigt
• Mangel an Erfahrung wird nicht adäquat kompensiert (bei vermeintlich einfachen Aufgaben)
• Häufiger Wechsel von Projektbeteiligten (speziell bei großen Migrationen)
  

Gut ausgebildete Projektteilnehmer reduzieren die Wahrscheinlichkeit von Pannen.

Wenn die Migration die Cloud (SharePoint Online) als Ziel hat, gibt es speziellere Risiken:

Machbarkeit

Nicht jeder Anwendungsfall lässt sich einfach in die Cloud übertragen.

• Intensives Customizing (SharePoint On-Premises lässt sich nicht 1:1 auf SharePoint Online übertragen, vor allem Anpassungen im Layout/Masterpage sind oft problematisch)
• Aufwand für cloud-konforme Implementierung exorbitant hoch (verglichen mit Farm Solutions)
  Oft ist hier die Erwartungshaltung, dass nur eine vollständige Abbildung einer bestehenden Plattform zum Ziel führt. Hier kann mit Augenmaß und funktionalen Lösungen ein durchaus guter Kompromiss gefunden werden. Außerdem ist es eine optimale Möglichkeit, sich von „alten Zöpfen“ zu trennen.
  

Stakeholder

Nicht alle lieben die Cloud.

• Ein Entscheider oder Einfluss-Nehmer in der passenden Position kann ein Cloud-Projekt verhindern („Cloud-Gegner“)
• Auch die Anwender müssen bereit sein, mit der Cloud zu arbeiten
  

Für ein effektives Risiko-Management ist hier in erster Linie wichtig, zu wissen, dass kontroverse Meinungen existieren. Entsprechend ist gerade bei Cloud-Migrationen eine Stakeholder-Analyse oft von unschätzbarem Wert. Positives Projektmarketing ist abgesehen davon durchaus in der Lage, bei den Anwendern einen Sinneswandel herbeizuführen. Meistens reicht es hierbei, den Usern die Angst zu nehmen, dass sie durch den Einsatz der für sie (noch) unbekannten Technologie Nachteile erleiden.

Falsche Tool-Auswahl

• Der Markt ist voll von Migrationstools
• Die Leistung von Tools ist zum Teil sehr unterschiedlich und steht nicht immer in Relation zum Preis
• Gerade bei einer komplexen Methodik sind auch „professionelle“ Tools oft überfordert (z.B. bei einer differenziellen Migration kommt es vor, dass der „Anschluss“ nicht mehr gefunden wird)
  

Tatsächlich ist hier in jedem Projekt eine individuelle Entscheidung sinnvoll, nicht nur der Preis sollte dabei entscheidend sein, sondern auch das Ergebnis und die Bedienbarkeit. Auch das Migrationstool von Microsoft gehört seit der letzten Aktualisierung klar in die engere Wahl. Am Ende ist hier entscheidend, was das Tool im Rahmen der Migration wirklich zu leisten hat.

Evergreen-Ansatz

• Was aus Sicht des Cloud-Managements ein Vorteil ist, kann bei einer Migration den gegenteiligen Effekt haben. Änderungen an der Zielplattform können zur Folge haben, dass die Ergebnisse am Ende nicht dem entsprechen, was ursprünglich geplant war. Beim Wegfall von Features ist es sogar möglich, dass die Migration an bzw. in diesem Punkt völlig scheitert.
• Durch Neuerungen im Zielsystem ist auch ein permanentes Hinterfragen der Methodik und der zeitlichen Planung erforderlich.
  

Da sich die Anpassungen der Cloud-Umgebung nicht verhindern lassen, ist die beste Strategie sich damit zu arrangieren und Änderungen, sofern erforderlich, direkt umzusetzen. Damit dies funktioniert, ist es notwendig, über Änderungen stets auf dem Laufenden zu sein. Welche Änderungen durchgeführt wurden, kann im Office 365 Portal ausfindig gemacht werden. Die Auswertung der Änderungsinformationen sollte entsprechend zu den Standard-Aktivitäten des Projektleiters gehören (sofern diese Aufgabe nicht an einen technischen Projektmitarbeiter delegiert wurde).

Bandbreite von und zur Cloud

• Sehr oft wird die Auswirkung der Bandbreite auf die Geschwindigkeit der Migration unterschätzt, so dass die Migration länger dauert als geplant.
•  Ebenfalls wird oft vergessen, dass sich Migration und Produktivbetrieb mitunter die Bandbreite teilen, wodurch eine Beeinträchtigung der Anwender entstehen kann, sofern die Migration innerhalb der Geschäftszeiten durchgeführt wird.
• Durch die Abweichungen in der Geschwindigkeit gerät zwangsläufig der Zeitplan für den Umzug von Inhalten durcheinander

Eine sorgfältige Kalkulation im Vorfeld hilft, spätere Engpässe zu vermeiden. Zur Vermeidung einer gegenseitigen Beeinflussung empfiehlt sich unabhängig davon, eine aktive Steuerung der Bandbreiten für ein ausgewogenes Verhältnis zu nutzen.

„unerwartete“ Anforderungen an den Betrieb

• Backup und Restore – wird oft in dem Glauben vernachlässigt, dies sei in der Cloud eine Standard-Leistung
•  Exit-Szenario – Oft ist die Möglichkeit zum Ausstieg aus einer laufenden Nutzung ebenso wichtig, wie die Migration selbst. Gründe hierfür sind mitunter Compliance, sowie Vorgaben von Regulierungsbehörden

Auch in diesem Punkt ist Erfahrung nur sehr schwer zu ersetzen. Während man bei On-Premises Projekten häufig über Service Level Agreements und Redundanz spricht, gilt es in der Cloud tatsächlich Ansätze zu finden, die dem „Milieu“ von Anwendungsfällen und Unternehmensanforderungen optimal entsprechen. Nicht selten bedeutet dies, über den Tellerrand zu schauen und auch „exotische“ Faktoren zu berücksichtigen, um den neuen Realitäten gerecht zu werden.

Altlasten in Form von proprietären Lösungen und/oder Customizing

• RAD („Rapid Application Development“) Tools, deren „Produkte“ nicht ohne Weiteres in der Cloud weiterbetrieben werden können oder sollen (Beispiel: 3rd Party für Workflows) – Oft hat man hier nur die Wahl zwischen neu bauen, oder den zugehörigen Dienst in der Cloud zu buchen. Dies ist zwar kein Show-Stopper, allerdings können hier die Aufwände und Kosten so stark explodieren, dass die Rentabilität des Projektes selbst auf den Prüfstand gestellt werden muss
• Eine erfolgreiche Übernahme von Site-Inhalten wird oft auch durch nicht dokumentierte Anpassungen an den Seiten verhindert, dabei spielt es kaum eine Rolle, ob dafür Java-Script oder Änderungen an den Masterpage-Definitionen verantwortlich sind.
  

Am besten lassen sich Altlasten einschätzen, wenn man diese bereits bei der Bestandsaufnahme identifiziert und die notwendigen Maßnahmen in die Projektkalkulation aufnimmt. Anstelle einer Übernahme von kostspieligen Lösungen ist es ratsam, den künftigen Bedarf zu hinterfragen und im Zweifelsfall auf einfachere Lösungsszenarien umzusteigen. Das Festhalten an nicht zukunftsfähigen Lösungen verursacht in vielen Fällen mehrfach Kosten.

Umbau von Strukturen

• Dass im Zuge einer Migration gleichzeitig die Strukturen von Informationen umgebaut werden, ist nur auf den ersten Blick eine gute Idee. Versucht man dies in der Praxis, ist es schon fast vorprogrammiert, dass man schnell nicht mehr unterscheiden kann, ob ein Effekt durch die Migration, oder durch den (relativen) Umzug von Daten zu Stande kommt. Speziell komplexe Systeme oder Prozessabläufe können dadurch im schlimmsten Falle komplett außer Gefecht gesetzt werden.
  Hier hilft tatsächlich nur Vermeiden und Linearisieren, mit anderen Worten, zuerst die Migration durchzuführen, und sich im Anschluss daran der Restrukturierung zu widmen. Die Ausnahme davon bilden Prozesse, die vollständig neugestaltet werden sollen.
  

Fehlende Lizenzen

• Gerne wird vergessen, dass beim Betrieb von zusätzlichen oder neueren Systemen ggf. eine Anpassung der Lizenzierung erforderlich ist.
  Durch eine weitsichtige Planung lässt es sich leicht vermeiden, durch die Migration den Pfad der Legalität zu verlassen.
  

Natürlich lässt sich diese Liste noch fortführen, wenn man jedoch die oben beschriebenen Risiken hinreichend berücksichtigt, steht einem erfolgreichen Migrationsprojekt nach SharePoint Online kaum noch etwas im Wege. Damit keine Schritte oder Überprüfungen vergessen werden, empfiehlt es sich, schon früh im Projekt einen detaillierten Cut-Over-Plan zu erstellen, der speziell für die produktive Migration klar vorgibt, wann welche Aktionen gezielt auszuführen sind, um eine erfolgreiche Migration sicherzustellen.