Migration Microsoft Project Server – Wie gehe ich vor?

Veröffentlicht am 02.12.2015 | Lesezeit 4 Min.

Seit dem 13.10.2015 bekommen Sie für Ihr Microsoft Project Server 2010 nur noch Sicherheitsaktualisierungen (s. dazu auch Blog von Christoph Mülder). Microsoft Produkte fallen in der Regel nach fünf Jahren aus dem Mainstream Support, nach fünf weiteren Jahren wird der Extended Support ebenso beendet. Spätestens dann wird eine Migration auf eine aktuellere Version notwendig. Die Migration ist allerdings nicht nur eine technische Frage. Die Oberfläche ändert sich, neue Features kommen dazu, und der produktive Betrieb soll so wenig wie möglich durch diese Änderungen gestört werden. Was ist bei einem Migrationsprojekt zu beachten?

Voraussetzungen

Bevor Sie mit dem Migrationsprojekt starten, müssen Sie bestimmte Voraussetzungen beachten. Dazu gehört:

  • Die Rechner der Anwender müssen gewisse Voraussetzungen erfüllen:
    • Ist Ihr Standardbrowser kompatibel mit dem neuen Project Server?
    • Kann die neue Version von Microsoft Project Professional für alle Projektleiter ausgerollt werden oder ist Ihr Betriebssystem vielleicht zu alt?
      Wenn ja, müssen Sie auf ein unternehmensweites Migrationsprojekt des neuen Betriebssystems warten, oder kann eine Einzelfallregelung getroffen werden?
  • Haben Sie Erweiterungen oder Add-ons im Einsatz? Vom kleinen Makro bis zur SAP-Schnittstelle, die Kompatibilität mit der neuen Version muss geprüft werden. Häufig müssen Individuallösungen bearbeitet oder gar neu entwickelt werden. Falls Sie Add-ons gekauft haben, prüfen Sie beim Hersteller, ob eine kompatible Version bereits entwickelt wurde.
  • Haben Sie bereits die passende Hardware für die zukünftigen Test- und Produktivumgebungen? Wenn nicht, wie ist der Prozess, um die Hardware bestellen zu lassen?

Alle diese Aspekte können unter Umständen ein Migrationsprojekt um 6 bis 12 Monate verzögern. Deswegen sollten sie so früh wie möglich geprüft werden, um eine realistische Planung sicherzustellen.

Testmigration

Grundsätzlich sind zwei Vorgehen für die Migration des Project Servers möglich:

  • Die Datenbankmigration ist der klassische Weg. Dabei werden die Datenbanken des Altsystems kopiert und auf das neue System kopiert. Dort werden die Datenbanken migriert und eine neue Project Web App-Instanz wird generiert. Alle Ihre Daten und Einstellungen bleiben erhalten.
  • Bei der Einzelprojektmigration wird eine neue, leere Project Web App-Instanz erstellt und konfiguriert. Dann werden die Projekt- und Ressourcendaten der alten Instanz exportiert und in die neue Instanz importiert. Dafür können Sie zum Beispiel das Drittanbieter-Tool FluentBooks verwenden.

In der Regel wird eine Datenbankmigration durchgeführt. Das Vorgehen wird von Microsoft beschrieben (https://technet.microsoft.com/de-de/library/ee662496.aspx) und sorgt dafür, dass sowohl die Konfiguration als auch die Daten vollständig übertragen werden. In bestimmten Fällen kann aber eine Einzelprojektmigration zu empfehlen sein, zum Beispiel

  • wenn bei der Testmigration technische Schwierigkeiten auftreten, die mit einer Datenbankmigration nicht zu umgehen sind.
  • wenn der alte Project Server viele unnötige Daten enthält oder die Konfiguration zum großen Teil obsolet geworden ist. In diesem Fall kann man mit einer Einzelprojektmigration einen frischen Start auf dem neuen Server machen und nur die nötigen Elemente transferieren.

Eine Big Bang Migration ist in der Regel zu empfehlen: Alle Daten werden gleichzeitig migriert. Eine alte und neue Umgebung parallel laufen zu lassen, um nur einen Teil der Projekte oder der Abteilungen zu migrieren, würde viele Schwierigkeiten mit sich bringen. Die meisten Mitarbeiter arbeiten für mehr als nur ein Projekt und viele Stakeholder brauchen eine übergreifende Übersicht über alle Projekte.

Schulungen und Kommunikation

Die betroffenen Anwender sollten möglichst früh über das Migrationsprojekt informiert werden. Sie sollten wissen, was sie erwartet, und wann die Produktivmigration voraussichtlich stattfindet. Außerdem müssen sie lernen, mit der neuen Version zu arbeiten. Die Kommunikation zur neuen Version kann über unterschiedliche Wege laufen:

  • Rundmails, kurze Statusinfos in Teammeetings oder sogar Flyer sorgen dafür, dass alle informiert sind.
  • Upgrade-Schulungen helfen Ihren Anwendern, die neue Umgebung kennenzulernen. Schulungen sollten möglichst nah am Go Live Termin durchgeführt werden.
  • Mit „Quick Guides“ können Sie die wichtigsten Informationen zusammenfassen und die Anwender in den ersten Tagen nach der Migration unterstützen.

Nicht nur die direkten Anwender des Project Servers müssen informiert werden. Andere wichtige Personenkreise dürfen nicht vergessen werden, zum Beispiel:

  • IT Support: Sie werden angerufen, sobald etwas nicht funktioniert. Deshalb müssen sie unbedingt rechtzeitig geschult werden.
  • Betriebsrat/Personalrat: Bei Änderungen einer bestehenden Anwendung muss häufig der Betriebsrat/Personalrat seine Zustimmung geben. Die relevanten Kontaktpersonen müssen möglichst früh involviert werden.

Go Live Termin

Bei der Terminierung des Go Lives sollten Sie daran denken:

  • Ferienzeiten sollte man ausschließen. Viele Anwender müssen in diesem Zeitraum geschult werden. Das funktioniert nur bedingt während der Sommerferien.
  • Die Migration unterbricht die Arbeit mit der Anwendung für mindestens zwei Tage (Downtime).
    Planen Sie den Termin zwischen zwei Reporting-Perioden, nicht drei Tage vor dem Monatsabschluss.
  • Anwender müssen sich zuerst an die neue Version gewöhnen, was die Arbeit kurzfristig verlangsamt.
    Planen Sie das Go Live deshalb nicht zu einer Zeit, in der bei Ihnen Stress und Hektik zu erwarten sind, wie z.B. Weihnachtsgeschäft oder Ende des Geschäftsjahrs.

Wenn Sie weitere Fragen zum Thema Migration haben oder sich für das Produkt FluentBooks interessieren, nehmen Sie gerne Kontakt mit uns auf.