Die Lotus Notes Migration – 1177

1. Das Problem

“Never ever change a running system” – so lautet die eiserne Grundregel in der IT – und so lässt sich auch erklären, das z.B. in der Finanzbranche noch viele Systeme in COBOL laufen – eine Programmiersprache aus der Steinzeit der elektronischen Datenverarbeitung und noch in Keilschrift.

Nun gibt es aber verschiedene Gründe, die über den change eines running system zumindest nachdenken lassen – z.B. läuft der Support der eingesetzten Version durch den Hersteller aus, sehr beliebt bei MS.

Doch wieso sollte man jetzt eine stabil laufende Notes Umgebung durch Exchange und AD ersetzen?

Klar, Notes ist in der Optik der Oberfläche hässlich wie die Nacht und eine Migration zu MS ist wie der Austausch von Oma Grabowski durch Heidi Klum.

Doch weiter – mit Exchange und AD findet man sich auf einmal in der erstaunlichen Welt von MS und Azure Cloud wieder. Die neue Exchange Groupwarelösung kann sich nahtlos in die neuen Möglichkeiten von SaaS, PaaS und IaaS in dieser Cloud einfügen – konkret winken da als neue Verwandtschaft Office365, SharePoint und viele weitere Highlights – eine enorme Steigerung von Möglichkeiten!

2. Privacy und DSVGO

Bleibt nur noch die Frage, in wieweit man diese Auslagerung der eigenen Daten in diese Cloud vorantreiben möchte.

Zuerst kann man sein seine Systemlandschaft vollständig abgeben an MS Azure – mit vielen Grüßen der drei Buchstaben Agentur und dem US Privacy Shield – oder man lässt einfach alles on prem im eigenen RZ weiterlaufen, wenig sinnvoll.

Der dritte Weg liegt in einer Hybridlösung! Wichtige oder personenbezogene Daten bleiben on prem im eigenen RZ, alles andere geht raus in die Cloud und nach Azure – fertig!

Nebenbei soll noch erwähnt werden, dass MS auch noch die Nutzung einer besonders vertrauenswürdigen und sicheren Deutschland Cloud anbietet. Betrieben von der Telekom werden hier besonders sensible Daten in Rechenzentren DSVGO konform mit Standort FFM oder Magdeburg gespeichert – wobei es dem nordkoreanischen Hacker von Büro 39 sicherlich reichlich egal ist, wo denn der Server jetzt im Netz hängt.

3. Big Bang oder Move Groups?

Diese Frage ist eher rein theoretischer Natur und betrifft die Umsetzung eines Change. Zuerst einmal kann ich das betroffene System in einem Big Bang – also an einem Wochenende auf einmal – umstellen. Alle User finden sich dann am nächsten Arbeitstag in der neuen Systemumgebung wieder – komplex, hat nicht unerhebliche Risiken und ist in großen Umgebungen mit einer hohen Useranzahl auch nicht mehr durchführbar.

Hier greift der klassische Move Group Ansatz, pro Wochenende wird eben nur eine Abteilung, Niederlassung oder Zweigstelle umgestellt und schon hat man eine agile Migration. Jetzt kann man einfach aus den Fehlern des letzten Wochenendes lernen und die Umstellung am nächsten Wochenende besser gestalten – leider dumm nur für den, der zuerst dran war.

Wichtig in diesem Zusammenhang und im Vorgriff auf noch folgende Details ist hier die Stellvertreterregelung. Als Stellvertreter kann man mit seinem eigenen Email Account im Namen eines anderen Accounts Mails versenden, so z.B. bei funktionalen Accounts, klar.

So gibt es z.B. den Account “bewerbung@firmaxyz.de”, alle Mitarbeiter der Personalabteilung sind als Stellvertreter eingerichtet und können jetzt Mails mit genau dieser Absenderadresse versenden, eine feine Sache. Ist jetzt jedoch der eine Part einer solchen Stellvertretung migriert, der andere aber noch nicht, so ist diese Stellvertreterregelung im Eimer.

In der Konsequenz müssen also geplante Move Groups genau auf diese Vertretungen untersucht und evtl. angepasst werden – der User hasst nichts mehr als wenn auf einmal etwas nicht mehr funktioniert, was vorher funktioniert hat.

Zusätzlich sollte zwischen zwei Move Groups bzw. Migrationen die UX [user experience] abgefragt werden – also die erste Erfahrung und Meinung des Users mit dem neuen System – und entsprechende Änderungen am neuen System in der nächsten Move Group vorgenommen werden – und auch hier wieder: leider dumm für den, der zuerst dran war.

4. Koexistenz – SMTP oder rich?

Der Ansatz einer schrittweisen Migration führt unweigerlich zur Koexistenz von altem und neuem System und dazu müssen jetzt entsprechende technische Vorkehrungen getroffen werden.

Zuerst einmal muss der User immer unter der gleichen Email Adresse erreichbar sein, egal ob sein Account jetzt auf Domino oder Exchange liegt – also egal, ob er bereits migriert wurde oder nicht. Dazu richtet man ein SMTP Forwarding ein, beide Systeme leiten jetzt eingehende Mails einfach an das andere System weiter – Alt und Neu synchronisieren sich einfach.

In der technischen Umsetzung kann man das z.B. mit einem einem einfachen PowerShell Script realisieren [weitere Details würden hier jetzt den Rahmen sprengen], einige Informationen gehen dabei allerdings verloren wie z.B Kalender oder free / busy Einträge – eben Simple Mail Transfer Protocol. Hier hilft dann nur noch ein Drittanbieter Tool wie z.B. CMTc von binary tree solutions und gewährleistet eine rich Koexistenz.

Und auch hier gilt wie immer: zuerst testen, testen, nochmal testen und Key User einbeziehen, bevor man ein solches Skript oder Tool auf die Menschheit loslässt!

5. Daten filtern!

Mit der Migration bietet sich natürlich auch die Möglichkeit endlich mal aufzuräumen und sich von Altlasten zu trennen – müssen wirklich alle Mails der letzten hundert Jahre in das neue System übernommen werden oder reichen vielleicht die Mails der letzten drei Jahre?

Eine politische Entscheidung und vielleicht spielen auch noch Compliance Gründe mit, die das Vorhalten von Kommunikation der letzten zehn Jahre vorschreiben.

Was auf jeden Fall migriert werden sollte und auch keine allzu hohe Datenlast erzeugt sind Kontakte und Kalender, klar.

Von technischer Seite her kann man ein Postfach auch schon im Vorfeld auf das neue System überspielen, ohne gleich umzustellen. Kommt dann der Tag der Umstellung, muss man nur noch eine Delta Migration – also eine Migration der neu hinzugekommenen Daten – durchführen – geht dann eben schneller.

6. User Acceptance

Das Wichtigste zum Schluß: der Erfolg eines IT Projekts oder einer Migration steht und fällt eben nicht mit einer raffinierten und ausgeklügelten technischen Implementierung – sondern mit der user acceptance!

Der User fragt sich zu Recht: “Wieso soll ich jetzt mit dem neuen System arbeiten, wo ich doch gerade mal mit dem alten System halbwegs klar komme?”. OK, verständlich.

Im Vorfeld – oder besser weit im Vorfeld – muss daher eine proaktive Kommunikation, ja sogar ein Marketing für das neue System aufgebaut werden! Wie nun? Ganz einfach!

So kann man z.B. weit im Vorfeld einen wöchentlichen Newsletter an alle User rausschicken, der jeweils einen besonderen Vorteil oder eine Arbeitserleichterung der neuen Lösung vorstellt und besonders herausstellt. Der User freut sich dann nach einer Weile schon auf die Migration!

Und man bietet im Vorfeld schon Schulungen für das neue System an, gleich verpflichtend für alle PowerUser und VIPs.

Auch danach darf man den User nicht im Regen stehen lassen. Hier reicht die Range von einer klassischen KnowledgeBase im Intranet über Chat Forum bis hin zu einer dedizierten Hotline nur für Fragen zum neuen System. Ebenso einsetzen kann man Floorwalker – also IT Mitarbeiter, die für Frage und Antwort direkt greifbar vor Ort – auf dem Flur sozusagen – persönlich zur Verfügung stehen.

So, ich habe fertig und mir fällt – erst einmal – nichts mehr ein.

Vielen Dank – big THX,

Markus