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.