Rafael Pfister

Consulting

Totemomail-Migration: neues Betriebssystem oder Kiteworks EPG

Totemomail-Installationen laufen oft seit vielen Jahren und tragen ein gewachsenes Regelwerk, Schlüsselmaterial aus mehreren Zertifikatsgenerationen und WebMail-Konten externer Empfänger. Ob die bestehende Installation auf eine neue, unterstützte Betriebssystem-Basis umzieht oder der Wechsel zum Kiteworks Email Protection Gateway ansteht: Ich plane und begleite beide Wege, mit Abnahmetests auch für historische Nachrichten.

  • totemomail
  • Kiteworks EPG
  • OS-Migration
  • S/MIME & OpenPGP
  • WebMail
  • Apache James

Zwei Migrationswege

Bei der OS-Migration bleibt totemomail das Produkt, ersetzt wird die Basis darunter. Konfiguration, Datenbank, Keystores, Zertifikate und Lizenz ziehen auf ein neues System um, Knoten für Knoten und mit Rückweg. Beim Wechsel zu Kiteworks EPG ändert sich die Plattform: Kiteworks überträgt die Daten aus der totemomail-Datenbank automatisiert in die Datenbank der Hardened Virtual Appliance. Regeln, Integrationen und Betriebsabläufe müssen jedoch gegen die neue Plattform geprüft und teilweise neu aufgebaut werden.

Leistungen

  • BestandsaufnahmeRegeln, Trigger, Prioritäten, Domains, Connectoren, Schlüssel und Lizenzmetrik inventarisieren; nicht mehr genutzte Regeln und abgelaufene Zertifikate vor der Migration bereinigen.
  • OS-MigrationNeues System aufbauen, Konfiguration, Datenbank und Keystores übernehmen, Cluster-Knoten einzeln umstellen und den alten Knoten erst nach der Abnahme abschalten.
  • Wechsel zu Kiteworks EPGMigrationsumfang festlegen, Datenübernahme vorbereiten und prüfen, Regelwerk und Integrationen wie Verzeichnis, SIEM und Archiv auf EPG abbilden.
  • Routing und Microsoft 365Connectoren in Exchange Online oder Exchange Server, MX, TLS-Vorgaben und Allowlisten auf das neue Gateway umstellen, ohne Zustell-Lücke.

Ablauf

  1. Inventur und BereinigungWas aktiv genutzt wird, wird übernommen; was niemand mehr braucht, bleibt zurück.
  2. ParallelaufbauDas neue System läuft parallel und wird mit Testdomänen und Testempfängern geprüft, bevor produktiver Verkehr umgestellt wird.
  3. UmstellungRouten einzeln und rückholbar umstellen, Mailflow und Queues eng überwachen.
  4. Abnahme und RückbauNeue und historische Nachrichten je Verschlüsselungsart testen, danach das alte System aus DNS, Connectoren, Allowlisten und Monitoring entfernen.

Beispiele aus der Praxis