Für alle die bereits den Microsoft Office SharePoint Server 2007 im Einsatz haben und sich fragen, wie denn der entsprechende Upgradepfad nach Microsoft SharePoint Server 2010 aussehen wird, kann ich vorweg mal vermitteln: Microsoft hat sich mehr als bemüht und bietet sehr gute Upgrademöglichkeiten.
In Farmen mit mehreren Server kann dieser Prozess dennoch komplex werden und sollte daher ausnahmslos von erfahrenen SharePoint Experten durchgeführt werden, welche sich eben intensiv mit dem Thema “Migration / Upgrade nach SharePoint 2010” beschäftigen.
Microsoft bietet mehrere Ansätze an, eine bestehende SharePoint 2007 Farm nach SharePoint 2010 zu migrieren:
Ansatz 1 | Die “In-place Upgrade” Variante
Die sogenannte In-place Migration dient dazu eine bestehende SharePoint 2007 Farm direkt nach SharePoint 2010 zu migrieren. Dabei wird SharePoint 2010 über die bestehende SharePoint 2007 Implementierung installiert. Wichtig ist, dass alle Basisvorraussetzungen und Systemanforderungen eingehalten werden und die Farm mit dem Pre-upgradechecker Tool (ab SharePoint 2007 SP2 gibts dafür einen eigenen stsadm-Befehl) in Bezug auf mögliche Problembereiche, die während einer Migration auftreten können, gegengeprüft werden kann.
WICHTIG: Sollte Ihre Umgebung nicht auf 64-Bit implementiert worden sein (wir empfehlen dies seit Jahren bei allen Kunden), müssen Sie die bestehende Farm vorher auf 64-Bit migrieren um z.B. ein In-place Upgrade durchführen zu können. Dies gilt ürbigens auch für Windows Server 2008 und SQL Server Komponenten. Es gelten eben für alle Bereiche Systemvorrausetzungen, die VOR einem In-place Upgrade durchgeführt werden müssen (ich meinte ja bereits oben, dass dies durchaus auch komplex werden kann).
Weiters gilt dies übrigens auch für Solutions / Features und WebParts bzw. kurz für alle Erweiterungen welche Sie in Ihrer Farm vorgenommen haben, d.h. alle Komponenten müssen auf jeden Fall 64-Bit fähig sein. Sind diese das nicht, müssen Sie entsprechen nachjustiert werden.
HINWEIS: Prüfen Sie somit auch alle Komponenten und WebParts, die Sie in Zukunft für Ihre SharePoint 2007 kaufen bzw. entwicklen lassen, dass diese zu 100% 64bit fähig sind. Auch dies machen wir bereits seit Jahren, da es offensichtlich war, dass Microsoft 64bit fokusieren wird (Sie kennen das ja bereits von der Exchange-Welt, wo Exchange 2010 RTM bereits verfügbar ist und seit Exchange 2007 alles 64bit ist).
Sind mal alle Voraussetzungen geschaffen und wurde auch das Pre-upgradechecker Tool über stsadm fehlerfrei aufgerufen, kann nun mit dem In-place Upgrade begonnen werden. Beachten Sie dazu bitte auch die entsprechende Reihenfolge, die Microsoft dafür vorgesehen hat (z.B. fangen Sie mit dem Server an, der die Zentraladministration implementiert hat an, usw.). Wichtig ist auch, dass der Configuration Wizard erst ausgeführt werden darf, wenn auf allen Servern das SharePoint 2010 Setup ausgeführt worden ist.
Danach läuft die SharePoint Farm mal auf SharePoint 2010 Technologie, die Webseiten und die neuen “Ribbon” Funktionalität ist jedoch noch nicht vorhanden (die Webseiten schauen so aus, wie im SharePoint 2007). Erst durch das Ausführen des Visual Upgrades werden die Webseiten mit dem neuen “Design” und dessen “Ribbon” zur Verfügung gestellt. Dieser Prozess kann sehr schön “getestet” werden. So lassen sich Webseiten mit Visual Upgrade zwischen “alten” und “neuen” Design beliebig umschalten. Dies ist ideal für Kunden, die zwar wechseln wollen und z.B. in erster Phase alle neuen Funktionalitäten nutzen wollen, den Endbenutzer aber noch nicht sofort mit dem neuem “Ribbon” überraschen wollen (z.B. weil es noch keine Schulungen gab). Das Visual Upgrade ist Webseitenorientiert und kann selbstverständlich über Powershell zu 100% gescriptet werden.
HINWEIS: Der SSP wird bei diesem Upgrade-Verfahren in einzelne Service Applications “umgewandelt” und extistiert danach somit nicht mehr. Die entsprechenden Dienset werden also dann von den jeweiligen Service Applications zur Verfügung gestellt.
Letzter Schritt wäre dann eigentlich das Prüfen der Logs und die Beseitigung von eventuellen Fehlern nach dem Migrationsvorgang.
Nach der Migration kann dann bei Bedarf mit der Restrukturierung des Portals und das einarbeiten der neuen Funktionalitäten begonnen werden. Die In-place Migrationsvariante ist für Kunden gedacht, die die bestehende Infrastruktur verwenden wollen und auch alle Inhalte entsprechend übernehmen wollen (1 zu 1). Das Problem dieser Migrationsvariante: Wenn es Probleme bei der Migration geben sollte, ist die Farm und die entsprechenden Benutzer nun mal auch betroffen davon. Aber Migrationen sind nun mal etwas für Experten und sollten auch nur von solchen durchgeführt werden!
Die In-place Migration ist ideal für kleinere und mittlere Umgebungen, in denen die Architektur der Farm möglichst gleich bleiben soll. Beachten Sie bitte, dass große und viele Inhaltsdatenbanken bei einem In-place Upgrade auf einmal übernommen werden und der Prozess durchaus auch dann lange dauern kann.
Ansatz 2 | Die “Database migration” Variante
Gehts darum eine Farm neu zu strukturieren bzw. gibt es viele und große Inhaltsdatenbanken, ist die Variante der “Database Migration” der ideale Weg, auch wenn man dafür wesentlich mehr Ressourcen benötigt. Das Prinzip ist relativ einfach: Man baut eine neue saubere SharePoint 2010 Farm auf (=daher Ressourcenintensiv) mit allen entsprechenden Vorraussetzungen und Anforderungen. Diese agiert somit völlig unabhängig von der bestehenden SharePoint 2007 Farm. Man baut somit dann auch die entsprechenden WebApplikations Architektur auf, die man benötigt und kann dann eben mit der "Database migration” beginnen. Dazu wird einfach von einer SharePoint 2007 Inhaltsdatenbank eine Sicherung erstellt und am Datenbankserver der neuen Farm online genommen.
Nun kann diese mit z.B. Powershell einer WebApplikation in der neuen SharePoint 2010 Farm hinzugefügt werden (übrigens können Sie dies auch mit stsadm durchführen, denn stsadm Befehle können weiterhin verwendet werden und der “addcontentdb” Befehl im stsadm ist ja eigentlich auch nichts neues, auch wenn Sie unbedingt Powershell lernen sollten, denn damit können Sie aus einem Portfolio von mehr als 500 neuen SharePoint Befehlen wählen und diese können sich mehr als sehen lassen). Wird nach diesem Prozedere eine Datenbank in die neue SharePoint 2010 Farm übernommen, wird diese gleich migriert und upgegraded und dessen Sitecollections gehen mit dem alten Design online. Jetzt noch alle Logs prüfen und ein Visual Upgrade bei Bedarf durchführen, fertig.
HINWEIS: Auch bei dieser Variante sollten alle vorgenommenen Erweiterungen (Solutions, Features, WebParts, usw.) VOR dem Online nehmen einer Datenbank in der neuen SharePoint 2010 Farm implementiert worden sein.
Für Kunden mit sehr vielen und großen Datenbanken ist dies wohl der bessere Weg eine Migration nach SharePoint 2010 vorzunehmen. Ein Vorteil hier ist auch, dass die neue SharePoint 2010 Farm komplett neu implementiert werden kann (=saubere Neuimplementierung ohne Übernahme von “Altlasten”). Es werden hier eben nur die entsprechenden Inhalte der Webseiten (sprich Inhaltsdatenbanken) übernommen.…
Ansatz 3 | Die Hypbrid Variante
Die Hybrid-Variante bietet von allem ein bischen was und wäre eine Kombination aus der Variante für Pre-Upgrade bzw. Database Migration. Man kann damit die Vorteile beider Varianten entsprechend nutzen.
Fazit: Kann sich wirklich sehen lassen und Planung ist das halbe Leben!
Microsoft stellt alle Tools und Anleitungen für eine erfolgreiche Migration entsprechend zur Verfügung. Mit dem Visual Upgrade hat Microsoft eine weitere Neuerung im Migrationsprozess nach SharePoint 2010 entwickelt – gefällt mir besonders gut und ist ideal für Umstellungszenarien in denen die Benutzer noch nicht mit dem neuen “Ribbon” Interface vertraut sind.
HINWEIS: Planen Sie ein Upgrade am besten mit erfahrenen Experten, da diese durchaus auch komplex sein kann. Migrationen werden immer wieder von Kunden unterschätzt: Wir werden sehr oft erst dann gerufen, wenn es massive Probleme gibt, weil eben durch die Komplexität auch Fehler gemacht werden bzw. meist gar nicht wirklich geplant wurde. Würden Sie ein Haus bauen ohne zu Planen? Leider passiert dies in der IT viel zu oft, glauben Sie mir, Planung ist wirklich das halbe Leben und in SharePoint werden nun mal wichtige unternehmensdaten gespeichert. Meist fehlt nun mal die Erfahrung, denn Kunden migrieren nur einmal im Gegensatz zu Experten, für die das quasi ein “daily job” ist.
Wir haben bereits die ersten Beratungsprojekte zum Thema Migration laufen, da eine solche Migration bei Umgebungen eben einfach gut geplant sein muss und diese Planungsphasen können idealerweise JETZT durchgeführt werden, bis dann eben die RTM Version (=Endgültige Version) von Microsoft für Endkunden verfügbar sein wird, sofern Kunden nach der RTM eben rasch auf SharePoint 2010 wechseln wollen. Es gilt: Je größer die Farm, desto mehr Planung ist nötig.
Feel free to Xing me
