totemomail migration: new operating system or Kiteworks EPG
totemomail installations often run for many years and carry a rule set that has grown over time, key material from several certificate generations and WebMail accounts of external recipients. Whether the existing installation moves to a new, supported operating system base or the move to the Kiteworks Email Protection Gateway is due: I plan and support both routes, with acceptance tests that also cover historical messages.
- totemomail
- Kiteworks EPG
- OS Migration
- S/MIME & OpenPGP
- WebMail
- Apache James
Two migration routes
In an OS migration, totemomail remains the product; what gets replaced is the base underneath. Configuration, database, keystores, certificates and licence move to a new system, node by node and with a way back. When moving to Kiteworks EPG, the platform changes: Kiteworks transfers the data from the totemomail database to the database of the Hardened Virtual Appliance in an automated process. Rules, integrations and operating procedures, however, have to be checked against the new platform and in part rebuilt.
Services
- InventoryInventorying rules, triggers, priorities, domains, connectors, keys and the licence metric; cleaning up unused rules and expired certificates before the migration.
- OS migrationBuilding the new system, carrying over configuration, database and keystores, switching cluster nodes one at a time and shutting down the old node only after acceptance.
- Move to Kiteworks EPGDefining the migration scope, preparing and verifying the data transfer, mapping the rule set and integrations such as directory, SIEM and archive to EPG.
- Routing and Microsoft 365Switching connectors in Exchange Online or Exchange Server, MX, TLS requirements and allowlists to the new gateway, without a delivery gap.
How an engagement runs
- Inventory and clean-upWhat is actively used is carried over; what nobody needs any more stays behind.
- Parallel buildThe new system runs in parallel and is tested with test domains and test recipients before production traffic is switched over.
- CutoverSwitching routes one at a time and reversibly, closely monitoring mail flow and queues.
- Acceptance and decommissioningTesting new and historical messages for each encryption type, then removing the old system from DNS, connectors, allowlists and monitoring.
Real-world examples
- KB: totemomail and Kiteworks EPG: architecture, migration scope and acceptance tests at a glance.
- Mail routing between totemomail and Exchange Online: which connectors and routes a move has to take along.
- Rebuilding Apache James rule sets structurally: cleaning up the rule set before it moves to a new system.
- Renewing a totemomail certificate: 4096-bit key, PKCS#12 import and restart per node.
