Mail Migration gegen Managed Services

Managed Services klingen nach einer guten Idee. Jeder macht, was er kann. Der Kunde kümmert sich um sein Kerngeschäft. Die IT-Services kauft er bei einem Provider ein. Der Provider bietet Netzwerk, Application Server, Mail Server, File Server, Storage, virtuell und als Blech, alles gewürzt mit einer fetten Prise Firewalls und Proxys, ein Schuß MDM dazu und oben drauf noch Identity Management. Hochverfügbar im Tier-4-Rechenzentrum.

Ein bisschen kniffliger wird dann der Leistungskatalog. Grundprinzip des Kunden: Ich will alles! Zumindest Kulanz und Flexibilität.Grundprinzip des Providers: Wir machen nur, was im Leistungskatalog beschrieben ist. Wenn der Leistungskatalog aus Sicht des Kunden schlecht verhandelt ist, wird jeder zweite Handgriff des Providers gesondert abgerechnet. Kulanz ist da eher nicht das prägende Stichwort.

Das mag dennoch alles ganz nett funktionieren, wenn das Service Konstrukt im eingeschwungenen Zustand ist, und keiner daran rüttelt. Ein kleiner Change Request hier, eine kleine Erweiterung des Leistungskataloges dort. Leben und leben lassen.

Was vermutlich in keinem Leistungskatalog steht, kann aber passieren. Der Kunde bestellt eine „Mail Migration Notes/Domino nach Outlook/Exchange/O365“. Anfangs denken alle Beteiligten noch „lass kommen“. Die Puzzlesteine werden sich schon irgendwo im Leistungskatalog finden. Aber dann stellt sich heraus, dass das Projekt an den Grundfesten der Managed Services rüttelt.

Das Projektteam fordert:

  • Vollzugriff auf das Active Directory
  • Vollzugriff auf das Domino Directory
  • Vollzugriff auf die Domino Server
  • Vollzugriff auf die Exchange Infrastruktur oder die Cloud-Komponenten
  • Vollzugriff auf Migrationsmaschinen
  • Ein Change Request Window für den gesamten Projektzeitraum
  • Öffnen von Firewalls für neue Ports und Maschinen
  • und, und, und …

Der Provider sagt: „Geht nicht, gibt´s nicht!“. Und schon steckt das Projekt im Sand. Die Dauerschleife heißt dann: Bedarfe formulieren (die man unter anderen Bedingungen in 5 Minuten umsetzen könnte), diskutieren, verhandeln, beschließen oder auch nicht, warten, warten, warten. Der Provider besteht aus Sicht des Projektteams aus einer Ansammlung von grauen Männern, die einem die Zeit stehlen. Abgeschottet durch den Stellverteter des „Systems“, den Service Delivery Manager. Da kommt tägliche Freude auf.

Wenn das Migrationsziel die Cloud ist, läutet zusätzlich eine Vielzahl von Alarmglocken bei allen Beteiligten: Wie sind wir sicher? Wer ist in Zukunft für was verantwortlich? Was macht Microsoft? Was war eine Illussion, weil es Microsoft nicht macht? Sind wir „cloud ready“?

Der Kunde selbst trägt natürlich auch mit seinen Befindlichkeiten zum Versanden bei. Als Höhepunkt fordert das Projektteam noch den Zugriff auf die Mailboxen, auch die des Vorstandes. „Das haben wir jetzt so nicht gewußt!“. Aber wie soll man sonst Mails migrieren? Mancher Kunde kommt einem vor wie der Patient beim Arzt, der über eine klaffende Wunde am Oberschenkel klagt, sich aber weigert die Hose auszuziehen.

Unterm Strich würde ich sagen: „Managed Services bei einem externen Provider verdoppeln oder verdreifachen die Projektkosten und die Laufzeit des Migrationsprojektes.“ Wer sich das leisten kann und will, der sei beglückwünscht. Wer nicht, dem sollte das Projektteam sehr frühzeitig den vollen Umfang des Dilemmas offenbaren. Ansonsten wird das zur Schnitzeljagd mit Grabenkämpfen und endet in Frustration und endlosen Vorwürfen.

Beruhigend wirkt dann lediglich, wenn die Projektleitung sagt: “ Wir halten am Abschlußtermin des Projektes fest und Nachtragsbudgets sind leider nicht möglich!“

Cloud Erwartungshaltung

Im Migrationsgeschäft gibt es immer wieder größeren oder kleineren Klärungsbedarf. Angefangen vom Mißverständnis man könne Notes Applikationen durch Umbenennen der File Extension von NSF auf was auch immer einem SharePoint Server unterschieben, bis zu dem Irrglauben, dass eine Mailmigration für zigtausend User mal schnell am Freitagabend zu machen sei. Selbstverständlich vollkommen verlustfrei.

Eine anderes Mißverständnis besteht bei den Human Cloud Services. Mancher Kunde glaubt an das Wunder aus der Cloud. Wenn er denn schon brav, zukunftssicher und innovativ seine Mailboxen in die Cloud migriert hat, dann hofft er damit auch alle lästige Administrationstätigkeit und den HelpDesk in die Cloud verschoben zu haben.

Die maximale Erwartungshaltung ist, dass damit auch die User-Administration in der Cloud liegt. Microsoft macht das irgendwie. Über Tickets an cloud@microsoft.com. Ist sicher im E3-Preis drin.

Und den internen HelpDesk kann man auflösen. Telefon 0800 MICSOFT. Vanity Number. Wenn dann ein User eine Mail versehentlich in den Trash Folder geschoben hat oder der Finger zwische A und S in der Tastatur stecken geblieben ist, dann hilft ihm der O365 HelpDesk in 129 Landessprachen und 245 lokalen Dialekten wie Pfälzisch, Fränkisch, Cockney oder Lousiana Creole French. Und Gott ist ja in der Cloud auch nicht so weit weg.

Mail Migration Factory

Unsere Tagesgeschäft in den vergangenen drei Jahren und vermutlich auch in den nächsten beiden Jahren ist die Mail-Migration von Notes/Domino nach Outlook/Exchange, wobei die Variante Office365 mehr und mehr genutzt wird.

Wir nähern uns der Mail Migration Factory.

Ziel ist selbstverständlich immer: Optimaler Komfort! Möglichst schnell! Keine Collateralschäden! Billig!

Der Komfort, d.h. die Qualität des für den Endanwender sichtbaren Ergebnisses, ist stark skalierbar. Zwischen Greenfield Approach, besonders beliebt beim Management solange sie nicht selbst davon betroffen sind, und dem Transfer des letzten Archives aus der letzten Serverecke besteht ein Unterschied in Aufwand und Ergebnis. Zum Erzielen von Komfort und optimaler Akzeptanz braucht man Erfahrung und eigene Tools. Es geht sehr viel, wenn man Ahnung hat und sich Mühe gibt. Zum Schnell-sein und zur Vermeidung von Collateralschäden braucht man auch Erfahrung und vielleicht noch eine Schippe persönliches Engagement.

Bei manchen Kunden können wir aber trotzdem den gleichen Leistungsumfang erheblich billiger erbringen als bei einem anderen Kunden. Optimal ist: Leistungsfähige Hardware beim Kunden, eine schöne site-to-site-VPN-Verbindung und das Vertrauen des Kunden, das sich in großzügigen Zugängen zu allen beteiligten Systemen für die beteiligten holistic-net-Mitarbeiter darstellt. Dann kann man auch mal eine Migration, für die man 30 Tage eingeplant hat, in 15 Tagen durchziehen.

Auch wenn wir an einem solchen Projekt weniger Geld verdienen, flockig arbeiten macht erheblich mehr Spaß als der Kampf gegen die Windmühlen im Providergestrüpp und den organisatorischen Formalkram im IT-Business. Das nächste Projekt wartet ja bereits.