Autor – Michael Denzler, TSP Team Lead & Senior Technical Solutions Professional EMEA, AvePoint
Die Gründe für eine Migration – wenn Daten eines Altsystems auf ein neues System überzusiedeln sind – können vielschichtig sein. Meistens verspricht man sich von einem neuen System zusätzliche Funktionalität. Aber auch die geringe Leistungsfähigkeit des Altsystems, oder die Tatsache, dass der Hersteller das Altsystem nicht mehr pflegt oder unterstützt, spielen eine Rolle.
Diese und weitere Überlegungen bewegen Unternehmen in der SharePoint-Welt, eine Migration ins Auge zu fassen. Da es sich bei SharePoint um eine der leistungsfähigsten und flexibelsten Plattformen handelt, wird meist eine Migration von fremdartigen Systemen, wie Fileshares, Livelink, oder Lotus Notes zu SharePoint durchgeführt. Soll dieser Wechsel gelingen, muss man sich früher oder später mit diesem Thema fachlich auseinandersetzen.
Worin sich die Migration vom Upgrade unterscheidet
Handelt es sich bei dem Altsystem lediglich um eine Vorgängerversion, z.B. SharePoint Server 2010, kann es ausreichend sein, die Migration über ein sogenanntes Upgrade durchzuführen. Bei einem Upgrade wird die existierende Datenbankstruktur direkt an die neue Version von SharePoint angepasst. Wenn SharePoint ohne jegliche Anpassung zum Einsatz kam, funktioniert diese Vorgehensweise in der Regel problemlos.
Wurden jedoch Anpassungen an SharePoint vorgenommen, ist ein Upgrade nur mehr schwer möglich. In diesem Fall bleibt nur der Weg über eine Datenmigration. Bei der Datenmigration wird Datensatz für Datensatz aus der Quelle gezogen, geprüft, gegebenenfalls transformiert, und dann in das Ziel abgelegt. Dieser Vorgang nimmt naturgemäß mehr Zeit in Anspruch, da für jeden Datensatz mindestens eine, üblicherweise sogar mehrere Transaktionen stattfinden.
Was es bedeutet, eine Migration durchzuführen
Um eine Migration erfolgreich durchzuführen, muss man zunächst verstehen, was sich hinter diesem Vorgang verbirgt. Denn hinter einer Migration wird oft eine einfache Datenkopier-Aktion vermutet. Das ist jedoch nicht richtig! Wenn das Altsystem an Prozesse, Abläufe oder die Funktionalität angepasst wurden, dann ist eine Migration als komplexes Projekt zu betrachten. Häufig führt dieser Denkfehler Verantwortliche in eine Sackgasse, aus der sie nur schwer wieder herausfinden.
Hat man sich jedoch diese Grundlage erst einmal vor Augen geführt, wird ganz schnell klar, dass bei einer Migration verschiedenste Aspekte zu berücksichtigen sind. Dazu gehören beispielsweise folgende Punkte:
1. die Auswirkung der Migration auf die Benutzer
2. die Dauer der Migration
3. die Beschaffenheit der Daten
4. Metadaten
5. Berechtigungen
6. Unternehmensrichtlinien
Eine Migration ist also kein rein technisches Thema und auch nicht nur auf die IT-Abteilung beschränkt. Der Aufwand einer Migration mag zwar hoch sein, doch ist sie oft der einzige Weg, Daten von einem Altsystem in ein neues zu übertragen.
Warum Know-how über das alte und neue System wichtig ist
Es gibt unterschiedliche Gründe für fehlgeschlagene Migrations-Projekte. Ein Hauptgrund ist fehlendes Wissen über das Altsystem und/oder das neue System, gerade dann, wenn die Migration auf eine fremde Plattform ansteht. Wenn technisches Know-how zur Abbildung von Prozessen und Datentypen im Altsystem oder im neuen System fehlt, führt das unweigerlich zu Problemen.
Weniger technisch, jedoch nicht minder wichtig, ist das Verständnis, wie mit den Daten bisher gearbeitet wurde, und zukünftig gearbeitet werden soll. Benutzer sind oft enttäuscht, wenn deren konkrete Erwartungen an das neue System nicht erfüllt werden. Es macht also Sinn, sie von Anfang an in das Migrations-Projekt einzubeziehen. Da eine zukünftige Plattform in der Regel viele neue Funktionen bietet, wird darüber hinaus empfohlen, diese genau zu prüfen. Damit wird sichergestellt, dass hinterher der zusätzliche Funktionsumfang auch gänzlich zum Einsatz kommt und den Benutzern ein Mehrwert geboten wird.
Oft wird ein einzelner Mitarbeiter aus der IT-Abteilung mit der Migration beauftragt. In der Praxis entpuppt sich diese Entscheidung oft als Fehler, da das Unterfangen in Umfang und Komplexität unterschätzt wurde. Um erfolgreich zu migrieren, wird daher empfohlen, ein Team zu bilden, das idealerweise Mitarbeiter aus der IT-Abteilung, Datenschutzexperten, Vertreter der Benutzer sowie Spezialisten für Prozesse umfasst.
Warum der Zeitaufwand und die Datenmenge nicht unterschätzt werden dürfen
Bei der Beantwortung der Frage nach der geschätzten Dauer der Migration sollte man mit seiner Einschätzung vorsichtig sein. Zwar wird eine Schätzung gerne lediglich basierend auf der reinen technischen Übertragungsleistung abgegeben. Bei sehr einfachen Migrations-Projekten kann das auch durchaus ausreichen. Doch sobald eine Migration komplex wird, ist diese Kalkulation nicht mehr ausreichend, da alleine die Vorbereitung mehr Zeit und Sorgfalt in Anspruch nimmt.
Die zu migrierende Datenmenge sollte nicht unterschätzt werden. Oft verstecken sich große Datenmengen in tiefer gelegenen Hierarchien oder in Form von Dokumentversionen. Es versteht sich von selbst, dass die Datenmenge sich direkt auf die Migrationsdauer auswirkt. Daher ist es ratsam eine Analyse durchzuführen, um festzustellen, in welcher Art der Speicher verwendet wird und ob es Möglichkeiten gibt, die zu migrierende Datenmenge zu reduzieren.
Ein gutes Beispiel stammt hier aus einer SharePoint 2007-Migration. Bei SharePoint 2007 wurden standardisierte Metadaten oft mit Hilfe von Lookup-Spalten realisiert. Diese Lösung war akzeptabel, hatte aber ihre Nachteile. Die Pflege der Lookup-Spalten erforderte zusätzlichen administrativen Aufwand und stand nur einem begrenzten Bereich, zum Beispiel innerhalb eines Projekts, zur Verfügung. Mit Hilfe der Migration ist es nun möglich, diese standardisierten Metadaten als Managed Metadaten in den Term Store, den es seit der Einführung von SharePoint Server 2010 gibt, zu konvertieren. Damit wird die Verwaltung und Nutzung für die Benutzer deutlich einfacher.
In einer Migration steckt immer auch eine Chance, die Umgebung aufzuräumen. Problematisch ist nicht selten, dass SharePoint nicht von Anfang an so installiert und konfiguriert wurde, wie es notwendig gewesen wäre. Die Folge: Wildwuchs. Neue Listen, Seiten, Duplikate entstehen und machen SharePoint unübersichtlich. Basierend auf dieser Erfahrung, würden viele Unternehmen SharePoint heute ganz anders in ihrem Unternehmen einführen. Deshalb ist eine Migration die optimale Gelegenheit, die Plattform von Altlasten zu befreien und nur das zu migrieren, was man auch wirklich in die neue Umgebung mitnehmen möchte.
Wie man erfolgreich migriert
Um eine Migration erfolgreich durchzuführen, gibt es vier wichtige Teilbereiche, die es zu berücksichtigen gilt:
1. Analyse
2. Definition von Anforderungen
3. Struktur und Metadaten
4. Vorbereitung und Tests
Im Folgenden sei kurz auf die wesentlichen Aspekte eingegangen:
Analyse des Altsystems
Analyse
Bei der Analyse geht es darum, sich mit der Quell- und Zielumgebung vertraut zu machen. Es ist unbedingt notwendig zu verstehen, wie diese Systeme arbeiten, Daten aufbereiten und zur Verfügung stellen. Dabei kann es sich um Konfigurationen handeln, z.B. welche Vorlagen oder Lösungen verwendet werden. Aber auch Berechtigungen, Prozesse und Workflows spielen eine wichtige Rolle. Die Kommunikation mit den Benutzern hilft, ein Verständnis für diese und ihre Bedürfnisse zu entwickeln und gleichzeitig Einfluss auf deren Erwartungshaltung zu nehmen.
Im Rahmen der Analyse sollten bereits die ersten Leistungstests durchgeführt werden. Es ist wichtig, bereits vorab zu wissen, wie schnell Daten ausgeliefert werden, wie gut die Anbindung ans Netzwerk ist und wie sich das System unter Last verhält. Gerade der letzte Punkt ist sehr spannend. Immerhin handelt es sich bei dem Altsystem um eine Umgebung, die bereits seit mehreren Jahren in Betrieb ist und möglicherweise nicht ausreichend dimensioniert ist, um schnell viele Daten aus dem System zu laden.
Analyse der Daten & Inhalte
Definition von Anforderungen
Um die Anforderungen zu definieren, sollte man prüfen, was genau mit der Migration erreicht werden soll. Davon abhängig ergeben sich viele Anforderungen fast automatisch. Typische Standard-Anforderungen können sein:
1. Extrahieren von Metadaten aus Dokumenten
2. Migration der letzten zehn Versionen
3. Migration der Berechtigungen und eventuelle Transformation (bei Fremdsystemen!)
4. Filtern von bestimmten Dokumenten
5. Zuordnung von Vorlagen für Listen und Sites
Struktur und Metadaten
Die Struktur und Hierarche von Daten im Altsystem bildet sich im Laufe der Zeit meist aufgrund mangelnder Governance durch die Benutzer. Oft wird bei der Vorbereitung einer Migration festgestellt, dass Inhalte redundant oder in logisch inkorrekten Bereichen abgelegt wurden. In diesem Falle kann es sinnvoll sein, die bisherige Hierarchie aufzubrechen und eine völlig neue Organisationsstruktur abzubilden. Werden Hierarchien geändert, müssen geschützte Inhalte jedoch mit der entsprechenden Umsicht behandelt werden – damit sie nicht plötzlich an Stellen verfügbar werden, auf die jeder öffentlich zugreifen kann.
Metadaten bei der Migration beizubehalten oder gar erst zu generieren ist grundsätzlich eine sinnvolle Maßnahme. Allerdings ist es empfehlenswert, sich nur auf diejenigen Metadaten zu beschränken, die auch tatsächlich benötigt werden. Das entscheidend Problem ist hierbei nicht die reine Datenmenge, sondern vielmehr die Art und Weise, wie diese Metadaten in der Datenbank gespeichert werden. Leistungseinbrüche und redundante Datensätze können bei falscher Speicherung die Folge sein. Die Umwandlung von Metadaten kann von Bedeutung sein, wenn zukünftig andere oder neuartige Datentypen genutzt werden sollen. Das Konvertieren von Lookup-Listen in Managed Metadata ist ein verbreiteter Anwendungsfall, wie bereits erwähnt.
Vorbereitung und Tests
Die Vorbereitung einer Migration nimmt in der Regel einen Großteil der veranschlagten Projektzeit ein. Hierbei gilt: Je sorgfältiger die Vorbereitung, desto erfolgreicher die Migration. Einer der wichtigsten Punkte ist, bereits in dieser frühen Phase die Benutzer in die Migration zu involvieren. Hierbei können sogenannte Key-User helfen, die die Kommunikation mit anderen Mitarbeiten einfacher und effektiver machen. Zudem müssen Daten in der Quelle analysiert und auf Gruppierungsmöglichkeiten hin geprüft werden. Eine sogenannte Big-Bang-Migration ist nicht zu empfehlen. In der Praxis hat sich eine Gruppierung der zu migrierenden Daten in logische Einheiten bewährt. Ob diese Gruppierung nach Abteilung, Ort, oder Unternehmensbereich erfolgt, lässt sich nicht pauschal vorgeben und sollte für jedes Migrations-Projekt einzeln festgelegt werden. Damit kann die Umstellung in mehreren Etappen erfolgen und erlaubt eine starke Kontrolle der Migrationsprozesse.
Oft vergessen, jedoch ebenfalls von großer Bedeutung, ist anschließend die Validierung der migrierten Daten. Je nach Sensibilität eines Datenbereichs kann es ausreichend sein, mit Hilfe von Stichproben die Integrität zu prüfen, oder aber es ist die Überprüfung eines jeden einzelnen Datensatzes erforderlich. Schlussendlich müssen im Rahmen der Vorbereitungs- und Testphase Leistungsmessungen vorgenommen werden. Dabei ist zu berücksichtigen, dass Test- und Produktivsystem möglichst identisch sein sollten. Je ähnlicher sich beide Systeme sind, desto realistischer sind die Messergebnisse.
Fazit
Eine Migration durchzuführen ist eine komplexe Aufgabe. Die Vorbereitung ist dabei maßgeblich entscheidend für den Erfolg oder Misserfolg des gesamten Projekts. Es ist daher essenziell, sich während dieser Phase mit der alten und neuen Umgebung durch Analysen vertraut zu machen, die richtigen Anforderungen zu erkennen und auch die Benutzer einzubeziehen. Zudem werden in der Regel Migrations-Tools benötigt, welche ausschließlich als Werkzeuge zu betrachten sind. Die Migration wird letztendlich von einem Team aus Mitarbeiten durchgeführt, die Kompetenzen und Erfahrungswerte aus ihren jeweiligen Wirkungsbereichen mit einfließen lassen.
Referenzen:
[1] Präsentation zum Thema: http://bit.ly/migrateSharePoint
[2] Blog Michael Denzler: http://blog.denzman.com
[3] Website AvePoint: http://www.avepoint.de
[4] Migration-Tool: http://bit.ly/1qoYP8b
www.avepoint.de
Michael Denzler ist TSP Team Lead & Senior Technical Solutions Professional EMEA bei AvePoint, einem führenden Softwarehersteller von Enterprise-Class Big Data Management-, Governance- und Compliance-Lösungen für Social Collaboration Plattformen. AvePoint wurde 2001 mit Hauptsitz in Jersey City, New Jersey, gegründet und unterstützt mehr als 13.000 Organisationen weltweit.
