Die Anforderung „vollständig ohne Cloud-Konnektivität“ schliesst Microsoft Teams faktisch aus, weil Microsoft Teams als SaaS/Cloud-Dienst konzipiert ist und keine on‑premises Version bereitstellt. Damit verschiebt sich die Problemstellung von „welches Tool ist ähnlich?“ zu „welches System lässt sich technisch, organisatorisch und regulatorisch so betreiben, dass keine Drittanbieter‑Cloud‑Services (inkl. Push‑Gateways, Telemetrie/Registrierung, Marketplace‑Zugriffe, Update‑Abhängigkeiten) im produktiven Betrieb nötig sind“.
Für ein Bank‑Setting (strenge Nachvollziehbarkeit, Identitätsintegration, Audit/Retention, HA/DR, kontrollierte Änderungen) zeigen sich zwei realistische Spitzenkandidaten, wenn „No‑Cloud“ streng interpretiert wird:
Viele Self‑Hosted‑Lösungen liefern Push über Anbieter‑Gateways oder über Apple/Google Push‑Dienste (APNs/FCM) beides ist aus strenger Sicht „Drittanbieter“. Das muss entweder (a) bewusst deaktiviert/akzeptiert, (b) durch ein explizit air‑gapped‑fähiges Produkt gelöst oder (c) über alternative Mobil‑Strategien (z. B. MDM‑Policies, „Always‑on“-Clients, ggf. Android ohne Google‑Dienste) kompensiert werden (nicht spezifiziert).
Kontext und Anforderungen
Ausgangslage und harte Randbedingung
Eine Bank benötigt einen Ersatz für Microsoft Teams, der vollständig ohne Cloud‑Konnektivität betrieben werden kann: on‑premises oder vollständig self‑hosted, ohne Abhängigkeit von Drittanbieter‑Cloud‑Services. (Interpretation: kein Betriebsteil – auch nicht Push, Lizenz‑Sync, Marketplace, Telemetrie, TURN-as-a-Service – darf zwingend ins Internet/zu Vendor‑Cloud gehen. Diese Interpretation ist als Annahme zu verstehen, weil „No‑Cloud‑Policy“ im Detail nicht spezifiziert ist.)
Dass Microsoft Teams selbst keine on‑premises Server‑Variante bietet, ist der zentrale Treiber für eine Alternativplattform.
Funktionsumfang, der im Bank‑Kontext typischerweise „Teams‑kritisch“ ist
Die von Ihnen genannten Attribute lassen sich in banktypische Muss‑/Soll‑Cluster übersetzen:
- Identität & Zugriff: AD/LDAP‑Integration, SSO (SAML/OIDC), Rollen/Privilegien, ggf. SCIM‑Provisioning.
- Kommunikation: 1:1/Group‑Chat, persistente „Channels/Streams“ inkl. Threads, Suche, Datei‑Anhänge; Audio/Video‑Meetings, Screen‑Sharing.
- Compliance: Audit Logs, Retention/Legal Hold/eDiscovery/Export‑Fähigkeit. (Teams nutzt hierfür Microsoft Purview; im on‑prem Setting braucht es Äquivalente oder SIEM‑/Archiv‑Integration.)
- Betrieb & Resilienz: HA (Knoten‑Redundanz), Backup/Restore, Disaster‑Recovery‑Plan, Monitoring, Patch‑/Update‑Prozess auch offline.
- Endgeräte: Windows/macOS/Linux, iOS/Android, Web‑Client + Browser‑Support.
Nicht spezifiziert (wird im Blog explizit als offen markiert)
Mehrere entscheidende Parameter sind in der Anfrage nicht definiert und beeinflussen Architektur, Kosten und Produktauswahl stark: Nutzeranzahl, gleichzeitige Meeting‑Last, externe Föderation/Partnerzugriff (Internet/DMZ ja/nein), Aufbewahrungsfristen, eDiscovery‑Prozess (intern/extern), MDM‑Stack, Netzsegmentierung sowie Integrationsgrad in Exchange/Outlook (reines Einladungstemplate vs. echte Presence/Calendar‑Integration).
Kandidatenanalyse
Im Folgenden werden die von Ihnen priorisierten Lösungen bewertet – mit Fokus auf „voll offline/on‑prem“ als harte Leitplanke.
Skype for Business Server (Subscription Edition) als „Microsoft‑On‑Prem“‑Pfad
Kurzbeschreibung: On‑premises UC‑Plattform mit IM/Presence, Conferencing und optional Persistent Chat (dauerhafte Chat‑Räume).
Deployment: Klassisch on‑prem (Pools/Edge). Föderation/External Access wird typischerweise über Edge‑Server bereitgestellt (DMZ‑fähig, Richtlinien‑gesteuert).
Teams‑Abdeckung:
- Stärken: Presence, klassische Enterprise‑Voice/Conferencing‑Tradition, SIP‑Föderation.
- Lücken ggü. Teams: „Modern Work Hub“ (Apps/Workflows), Datei‑Zusammenarbeit wie SharePoint/OneDrive‑Ökosystem, UX‑Erwartungen.
Compliance/Archivierung: Persistent Chat Server speichert Inhalte dauerhaft (Text/Links/Files im Chat‑Kontext), was Compliance‑Anforderungen unterstützen kann, ist aber funktional anders als Teams‑Channels.
Lizenz/Support‑Realität: Subscription Edition erfordert aktive Software Assurance bzw. passende Subscription‑Lizenzen; Microsoft positioniert die on‑prem Serverprodukte damit als „version‑less“ mit Modern Lifecycle Updates.
Eignung für eine Bank Sehr gut, wenn maximale Microsoft‑On‑Prem‑Kontinuität (AD/Exchange‑Nähe, klassische UC) im Vordergrund steht. Schwächer, wenn ein „Teams‑ähnliches“ Channel‑/App‑Modell und moderne Kollaboration erwartet wird.
Mattermost (self‑hosted)
Kurzbeschreibung: Team‑Messaging mit Channels, starker Admin‑/Compliance‑Ausrichtung und integrierten Calls (Plugin).
Deployment: Self‑hosted; Enterprise‑Features für Compliance und HA‑Clustering.
Audio/Video: Calls‑Plugin; Default‑Teilnehmerlimit ist konfigurierbar, praktische Empfehlung bis ~50 pro Call je nach Ressourcen (wichtiger Betriebs‑Hinweis für Bank‑Meetings/All‑Hands).
Compliance/eDiscovery: Explizit für Compliance‑Monitoring, Retention und eDiscovery‑Export dokumentiert; Anbindung an Archive/eDiscovery‑Drittsysteme (z. B. Smarsh, Global Relay, Proofpoint) wird genannt.
HA/DR: HA‑Cluster‑Deployment verfügbar (Enterprise); jedoch keine HA‑Topologie über mehrere Datacenter unterstützt (wichtig für echtes Active‑Active‑DR).
Clients: Desktop‑App für Windows/macOS/Linux; Web‑Experience vorhanden.
Security/Certifications: Offizieller Trust‑Bereich listet u. a. SOC 2 Type II (2025) und ISO 27001 (2022) als verfügbare Artefakte (vendor‑seitig).
Kosten (Ballpark, Schätzung):
- Lizenz: Enterprise‑Subscription (Preise i. d. R. angebotspflichtig; variiert nach User‑Tier/Support).
- Infrastruktur: typischerweise 3+ App‑Nodes + DB‑Cluster + Object/File‑Store; je nach Nutzerzahl und Call‑Last von „wenige VMs“ (Pilot) bis „dedizierte Cluster‑Ressourcen“ (Rollout).
(Bandbreite bewusst als Schätzung, da öffentlich nicht einheitlich bepreist und stark last‑/SLA‑abhängig.)
Eignung für eine Bank: Sehr stark für internen Betrieb mit Audit/Retention/eDiscovery und klaren Betriebsprozessen; Meetings >50 Teilnehmende sollten früh in einem Performance‑Proof getestet oder über externe/zusätzliche Meeting‑Komponenten (z. B. on‑prem Video) ergänzt werden.
Rocket.Chat (self‑hosted, inkl. „air‑gapped“ Modus)
Kurzbeschreibung: Collaboration‑Plattform mit Messaging, Voice/Video, Compliance‑Kontrollen, Kubernetes‑Skalierung und E2EE‑Optionen.
Deployment: Self‑managed (Docker/Kubernetes) und explizit „air‑gapped workspace“ dokumentiert; Microservices‑Architektur wird für größere Concurrency empfohlen.
Compliance:
- Audit Logs/Message Auditing Panel dokumentiert (Enterprise‑Funktionen).
- Retention Policies vorhanden (Nachrichten werden sonst „nie“ gelöscht).
E2EE: Workspace‑weit aktivierbar; verschlüsselte Räume möglich.
Bank‑Trade‑off: E2EE kann Audit/eDiscovery erschweren, wenn Prüfer Inhalte serverseitig nachvollziehen müssen (dieser Zielkonflikt ist konzeptionell).
Push‑Notifications als No‑Cloud‑Risiko: Standard‑Gateway ist gateway.rocket.chat; Dokumentation weist zudem auf Cloud‑Terms/Registrierung hin, und bei Gateway‑Abschaltung erfolgt direkte Kommunikation zu Apple/Google (APNs/FCM). Das kollidiert mit „kein Drittanbieter“ bzw. „kein Internet“.
Update/Support‑Fenster: Rocket.Chat dokumentiert, dass Versionen nur für einen begrenzten Zeitraum unterstützt werden (EOL‑Fenster); das erhöht operativen Patch‑Druck, was in Banken häufig Change‑Fenster‑/Validierungsaufwand erhöht.
Security/Certifications: ISO 27001 wird im Compliance‑Bereich ausgewiesen (Scope laut Dokumentation); zudem kommuniziert Rocket.Chat SOC 2 Type II als aktuelles Achievement (Feb 2026).
Eignung für Bank: Stark für Messaging + Compliance‑Steuerung; bei strikt offline sind Push/Registrierung/Marketplace‑Abhängigkeiten besonders sorgfältig zu designen (z. B. Mobile‑Strategie ohne Push oder mit strikt kontrollierter Ausnahme).
Element Server Suite (Matrix/Synapse) – souverän und air‑gapped
Kurzbeschreibung: Matrix‑basierte Enterprise‑Suite (Server + Clients + Conferencing via Element Call), explizit für digitale Souveränität und isolierte Netze. Matrix wird durch The Matrix.org Foundation als offener Standard geprägt; Synapse wird gemäß Projekt‑Hinweisen von Element gepflegt (Lizenz-/Maintenance‑Realität beachten).
Air‑gapped/Offline‑Fähigkeit: Element positioniert das Sovereign/air‑gapped Angebot ausdrücklich als „kein Internet nötig“ – inkl. Installation, Updates und Notifications; zudem wird eine „custom mobile push gateway“‑Option erwähnt.
Identity/SSO: Delegated Authentication unterstützt LDAP/SAML/OIDC (in ESS‑Doku beschrieben).
Conferencing: Element Call wird als Konferenz‑Komponente mit Scale‑Anspruch beschrieben (Multi‑SFU‑Architektur, „Sovereignty“‑Argumentation).
Compliance‑Kontrollen: Pricing/Feature‑Übersicht nennt Retention Policies, Auditing/Reporting und Data Export als Enterprise‑Funktionen.
Backup/DR: Element dokumentiert Backup & Restore und benennt für DR kritische Komponenten (PostgreSQL DB, Keys, Auth‑DB etc.).
Security/Certifications: Element kommuniziert ISO/IEC 27001:2022 Zertifizierung (Blog/Preis‑Seite).
Kosten (Ballpark, Schätzung):
- ESS Pro wird „per seat/month“ bepreist, Sovereign „per deployment“ (Angebotsmodell).
- Infrastruktur: typischerweise Kubernetes‑basiert (oder Standalone), Postgres + persistente Volumes; zusätzliche Komponenten für Federation‑Kontrolle/Border‑Gateway je nach Sicherheitsdomänen.
Eignung für Bank: Sehr hoch, wenn „No‑Cloud“ und isolierte Netze wirklich leitend sind und gleichzeitig moderne Messenger‑/Channel‑Funktionalität + Konferenzen gefordert werden. Besonders relevant, wenn externe Föderation/Partner‑Kommunikation perspektivisch gewünscht ist (Matrix‑Föderationsmodell, steuerbar).
Nextcloud Talk / Nextcloud Hub (Files + Talk + Groupware)
Kurzbeschreibung: Kollaborationsplattform mit starkem Schwerpunkt auf Files/Sharing; Talk bietet Chat + Audio/Video inkl. Screen‑Sharing.
Deployment: On‑prem/private cloud. Talk ist explizit als on‑prem/private Collaboration positioniert.
Dateien & On‑Prem File‑Server‑Integration: External Storage unterstützt u. a. SMB/CIFS File‑Server; Admin‑Dokumentation beschreibt SMB‑Integration.
Meetings & Skalierung: Talk High Performance Backend (HPB) enthält Signaling + WebRTC‑Gateway; Talk‑Scalability‑Doku beschreibt mit HPB typischerweise 30–50 aktive Teilnehmer und hunderte passive (bandbreitenlimitiert).
E2EE: Nextcloud dokumentiert E2EE primär für Files (Client‑seitig).
Für Talk existiert eine Capability „call‑end‑to‑end‑encryption“ (off by default bis alle Mobile‑Clients es unterstützen).
Für Talk‑Textnachrichten ist E2EE nach Community‑Aussagen derzeit nicht verfügbar (sekundäre Quelle, als Risiko/Limit zu verstehen).
Audit/Logging: Admin‑Manual erwähnt Logging und optional die admin_audit‑App für erweitertes Event‑Logging.
Vendor‑Support, SLA & Preisreferenz (transparent): Nextcloud veröffentlicht konkrete €/User/Jahr‑Preise, Reaktionszeiten und optionale Talk‑Subscriptions (z. B. Talk ab 42€/User/Jahr, Files‑Tiers ab ~71€/User/Jahr; Support‑Reaktionszeiten je Tier).
No‑Cloud‑Risiko: Push‑Notifications: Nextcloud beschreibt Push‑Notifications über eine „Nextcloud Push Proxy“ (kostenlos gehosteter Service von Nextcloud). Das ist für strikt „No‑Cloud“ ein potenzieller Show‑Stopper, sofern Mobile Push zwingend benötigt wird.
(Hinweis: Es existiert ein Portal‑Artikel „On premise push proxy server“, dessen Detailinhalt nicht öffentlich einsehbar ist; Machbarkeit/Produktereife für eine Bank ist daher in diesem Blog nicht verifizierbar.)
Eignung für eine Bank: Sehr gut, wenn der Schwerpunkt auf File‑Collaboration mit on‑prem Storage‑Integration liegt und Talk als Kommunikationslayer „gut genug“ ist – mit der zentralen offenen Frage, wie Mobile Push „cloud‑frei“ gelöst werden soll.
Jitsi (on‑prem Video‑Conferencing)
Kurzbeschreibung: Open‑Source WebRTC‑Videokonferenzen, self‑hostbar (Debian/Ubuntu Quickstart).
Deployment: Eigener Jitsi Meet‑Stack; eignet sich als „Meeting‑Engine“ ergänzend zu Chat‑Plattformen.
Security/E2EE: Jitsi beschreibt optionale End‑to‑End‑Encryption in Browsern mit Insertable Streams (Chromium‑basierte Browser; auch Electron‑Client).
Clients/Browsers: Dokumentierte Browser‑Unterstützung, inkl. iOS‑Besonderheiten.
Eignung für eine Bank: Stark als reiner Konferenz‑Baustein on‑prem; als vollständiger Teams‑Ersatz ungeeignet (kein vollwertiges Channel‑/Compliance‑System).
Cisco Meeting Server + Cisco IM & Presence (On‑Prem UC‑Stack)
Kurzbeschreibung: Premises‑basierte Meetings (Cisco Meeting Server) plus IM/Presence (Cisco Unified Communications Manager IM & Presence).
Browser/WebRTC: Cisco Meeting Server Web App erlaubt Join via WebRTC‑Browser.
Eignung für eine Bank: Sehr gut für klassische UC/Meetings on‑prem; als Teams‑Ersatz für Channels/Files meist nur in Kombination mit zusätzlicher Chat/Files‑Plattform sinnvoll.
Zulip (self‑hosted Chat/Streams)
Kurzbeschreibung: Stream‑basiertes Team‑Chat (stark für asynchrone Kommunikation, Threads), vollständig self‑hostbar.
SSO: SAML‑SSO ist auch für self‑hosted dokumentiert.
Skalierung/Requirements: Doku nennt Anforderungen und Skalierungshinweise (z. B. 100+ User: 4 GB RAM/2 CPUs als Richtgröße).
Limit: Keine native Enterprise‑Meeting‑Suite wie Teams; typischerweise Integration mit Jitsi/anderen für Video.
Eignung für eine Bank: Gut für Chat/Knowledge‑Threads; als Vollersatz nur mit zusätzlichem Meeting‑Stack.
Openfire/Prosody XMPP (mit Plugins)
Kurzbeschreibung: XMPP‑Server (Openfire/Prosody) als Basis für IM; kann via Plugins/Clients erweitert werden.
Directory‑Integration: Openfire dokumentiert AD/LDAP Integration.
Limit: Moderne Team‑UX (Channels, Files, eDiscovery, Meeting‑Scale) hängt stark von Client‑Ökosystem/Plugins ab; Integrations‑/Betriebsrisiko hoch.
Eignung für eine Bank: Eher Nische/Bestandsschutz; als Teams‑Replacement mit Bank‑UX/Compliance‑Anspruch nur mit erheblicher Engineering‑Leistung realistisch.
Wire (on‑prem/air‑gapped Secure Messenger)
Kurzbeschreibung: Secure Messenger/Collaboration mit E2EE für Messages/Calls/Files; Deployments inkl. air‑gapped möglich (Wire for Governments).
E2EE‑Eigenschaft: Wire sagt, dass Messages/Calls immer E2EE sind und nicht deaktivierbar; Schlüsselmaterial bleibt auf Endgeräten.
SSO/Provisioning: Wire dokumentiert SSO (SAML) und SCIM‑Provisioning.
Compliance‑Trade‑off: „Immer E2EE“ kann im Bankumfeld mit eDiscovery/Archivierung kollidieren, wenn die Bank inhaltliche Records rechtssicher exportieren muss (nicht ausgeschlossen, aber organisatorisch/technisch anspruchsvoll durch Key‑Ownership‑Modell).
Clients: Wire bietet Downloads/Clients (iOS etc.).
Eignung für eine Bank: Sehr gut für „High‑Security Messaging“/Krisenkommunikation in isolierten Netzen; als komplett gleichwertiger Teams‑Ersatz je nach Compliance‑/Records‑Pflicht potentiell eingeschränkt.
Vergleich und Bewertung
Feature‑Matrix „vs Teams“ (fokussiert auf No‑Cloud‑On‑Prem)
Legende: ✅ = gut/integriert, ⚠️ = möglich aber mit Einschränkungen/Zusatzkomponenten, ❌ = nicht primär vorgesehen.
| Kandidat | Voll offline ohne Dritt‑Cloud (Betrieb) | Chat + persistente Channels | Audio/Video (Meeting‑tauglich) | Screen‑Sharing | File‑Sharing + On‑Prem File‑Server‑Integration | AD/LDAP + SSO | Audit/Retention/eDiscovery | Clients (Desktop/Mobile/Web) |
|---|---|---|---|---|---|---|---|---|
| Skype for Business Server SE | ✅ (on‑prem) | ⚠️ (Persistent Chat als separates Rollenmodell) | ✅ | ✅ (Conferencing) | ⚠️ (nicht „Files‑Hub“ wie Teams) | ✅ (MS‑Ökosystem) | ⚠️ (anders als Teams‑Purview) | ⚠️ (Client‑Modell Teams‑anders) |
| Mattermost (Enterprise) | ✅ (self‑host) | ✅ | ⚠️ (Calls, realistische Empfehlung ~50) | ✅ | ⚠️ (Attachment‑Store; Integration möglich, aber nicht SMB‑Mount‑Paradigma) | ✅ (Enterprise‑Auth) | ✅ (Compliance Export/eDiscovery) | ✅ (Desktop/Web; mobile über Apps) |
| Rocket.Chat | ⚠️ (air‑gapped möglich, aber Push/Cloud‑Dienste kritisch) | ✅ | ✅/⚠️ (abhängig von Setup) | ✅ | ⚠️ (Files/Storage je nach Backend) | ✅ (Directory/SSO üblich) | ✅ (Audit Logs/Retention) | ✅ (Win/Mac/Linux/iOS/Android/Web) |
| Element Server Suite (Sovereign) | ✅ (explizit offline inkl. Updates/Notifications) | ✅ | ✅ (Element Call, E2EE) | ✅ (Konferenzen) | ⚠️ (Media Repo; File‑Server‑Integration eher via Links/Integrationen) | ✅ (LDAP/OIDC/SAML je nach Modus) | ✅ (Auditing/Retention/Data Export) | ✅ (Win/macOS/Linux/iOS/Android/Web) |
| Nextcloud Hub (Talk/Files) | ⚠️ (on‑prem ja; Mobile Push standardmässig via Nextcloud Proxy) | ⚠️ (Conversations statt Teams‑Channels) | ✅/⚠️ (HPB empfohlen für Scale) | ✅ | ✅ (SMB/CIFS External Storage) | ✅ (Enterprise‑Capabilities inkl. SAML laut Pricing) | ⚠️ (Logging + admin_audit; eDiscovery extern zu bauen) | ✅ (Desktop/Mobile/Web) |
| Jitsi (on‑prem) | ✅ | ❌ | ✅ (Video‑Stack) | ✅ | ❌/⚠️ (keine Files‑Hub‑Funktion) | ⚠️ (Auth via Konfig/SSO möglich, nicht Kern hier) | ⚠️ (Meeting‑Logs je nach Setup) | ✅ (Browser + Apps) |
| Cisco Meeting Server + IM&P | ✅ (premises‑basiert) | ⚠️ (IM&P eher klassisch, Channels anders) | ✅ | ✅ | ⚠️ | ⚠️ | ⚠️ | ✅/⚠️ (WebRTC Web App + Clients) |
| Zulip | ✅ | ✅ (Streams/Topics) | ❌/⚠️ (Integration mit Meeting‑Tool nötig) | ⚠️ | ⚠️ | ✅ (SAML self‑hosted) | ⚠️ (Export/Logs je nach Setup) | ✅ (Web + Apps üblich; Betrieb docs) |
| Wire | ✅ (air‑gapped Deployments genannt) | ⚠️ (Rooms/Teams, aber Teams‑App‑Hub anders) | ✅ (Calls/Meetings) | ✅ (typisch) | ⚠️ | ✅ (SSO/SCIM) | ⚠️/❌ (E2EE always‑on erschwert klassische eDiscovery) | ✅ (iOS/Android/Desktop/Web) |
Bewertungslogik für eine Bank (qualitativ)
Wenn eine Bank (wie viele Banken) nachweisbare Records/Exports braucht, ist ein System mit serverseitig kontrollierbaren Compliance‑Exports ein Vorteil (Mattermost stark dokumentiert; Rocket.Chat mit Audit/Retention; Element mit Retention/Auditing).
Wenn eine Bank hingegen primär maximale Vertraulichkeit bis hin zu isolierten Netzen priorisiert, steigt der Wert eines explizit air‑gapped‑fähigen Produkts (Element, Wire).
Der grösste technische „No‑Cloud“‑Stolperstein bleibt Mobile Push: Nextcloud nennt einen gehosteten Push Proxy, Rocket.Chat ein Gateway und/oder APNs/FCM, Matrix/Element verwendet Push‑Gateway‑Mechanismen (Sygnal → APNs/FCM), wodurch eine strikte Offline‑Interpretation entweder (a) Push deaktiviert oder (b) ein Produkt fordert, das Notifications ohne Internet explizit abdeckt.
Empfehlung und Implementierungsfahrplan
Finale Empfehlung
Empfehlung 1: Element Server Suite (Sovereign/air‑gapped) als „harte No‑Cloud“-Primärlösung
Begründung: Element adressiert den Offline‑Betrieb ausdrücklich „end‑to‑end“ (Installation/Updates/Notifications ohne Internet), bietet Enterprise‑Kontrollen (Retention, Auditing, Admin‑Tooling), Identity‑Integration (LDAP/OIDC/SAML je nach Modus) und eine Conferencing‑Komponente (Element Call).
Typische Bank‑Use‑Cases: interne Kommunikation in abgeschotteten Segmenten, sicherer Austausch über definierte Räume/Hierarchien, kontrollierte Föderation optional (falls später gewünscht und zugelassen), Krisenkommunikation in isolierten Betriebsnetzen.
Empfehlung 2: Mattermost (Enterprise self‑hosted) als „Compliance‑starker Teams‑Ersatz“ für den Kernbetrieb
Begründung: Mattermost liefert eine besonders klare Compliance‑Funktionalität (Compliance Monitoring, Compliance Export, eDiscovery‑Exportformate und Integrationshinweise), HA‑Cluster im Datacenter sowie eine pragmatische Calls‑Funktion inkl. Screen‑Sharing (unter Lastannahmen testen).
Typische Bank‑Use‑Cases: Daily Collaboration, Team‑Channels, Incident‑/Ops‑Kommunikation, Auditierbarkeit, definierte Retention/Export‑Pipelines in Archiv/SIEM/eDiscovery‑Tooling.
Warum nicht Nextcloud Talk als Top‑2?
Nextcloud ist sehr attraktiv als Files‑/Collaboration‑Suite mit transparenter Enterprise‑Bepreisung und starker SMB‑Integration, aber die dokumentierte Push‑Proxy‑Architektur (gehostet) ist unter strenger No‑Cloud‑Interpretation ein erheblicher Klärungsbedarf – insbesondere wenn iOS/Android Push „must‑have“ ist.
Implementierungs‑Roadmap (Phasen, grobe Timeline, Pilot‑Design)
Phase „Vorbereitung“ (ca. 2–4 Wochen)
Ziel: Anforderungen finalisieren und „No‑Cloud“ präzise operationalisieren (inkl. Mobile‑Push‑Policy), Datenklassifikation je Use‑Case, Retention‑/eDiscovery‑Zielbild, Erfolgsmetriken, Zielarchitektur (Prod/DR) und Betriebsmodell (DevSecOps vs. klassischer Bank‑Betrieb).
Phase „Foundation Build“ (ca. 4–8 Wochen)
Ziel: Aufbau der Plattform in einer produktionsnahen Staging‑Zone inkl. Identity‑Integration (LDAP/SSO), Logging/Audit‑Pipeline, Backup‑Konzept, Monitoring, Patch‑Prozess. Für Element: Backup/DR nach ESS‑Leitfaden (DB/Keys/Auth). Für Mattermost: HA‑Cluster aufsetzen und Upgrade‑Runbooks (Rolling Upgrades) definieren.
Phase „Pilot“ (ca. 6–10 Wochen)
Ziel: Pilot mit ca. 200–500 Usern (IT, Operations, Compliance‑Stakeholder, 1–2 Business‑Einheiten).
Schwerpunkte:
- Funktionale Abdeckung (Chat/Channels, Meetings + Screen‑Sharing, Files)
- Performance unter Last (Calls/Meetings; bei Mattermost Calls früh die Teilnehmer‑Last testen)
- Compliance‑Prozesse: Export‑Testläufe (Mattermost Compliance Export/eDiscovery) / Audit‑Workflows (Element Auditing/Retention)
- Security‑Tests: Hardening, Threat‑Model, PenTest‑Scope.
Phase „Migration & Rollout“ (ca. 8–16 Wochen, in Wellen)
Ziel: Staffel‑Rollout (z. B. 5–10% → 30% → 60% → 100%), Schulung, Champions‑Netzwerk, Runbooks/ITSM‑Integration, Abschaltung/Restriktion von Teams‑Use‑Cases.
Phase „Stabilisierung & Optimierung“ (laufend)
DR‑Drills, Incident‑Playbooks, Kapazitätsplanung, Upgrades kontrolliert im Bank‑Change‑Fenster.
Erfolgskriterien (messbar)
- Sicherheit/Compliance: Audit‑Trail vollständig (Admin‑Aktionen, Export‑Jobs), Retention‑Policies wirksam; eDiscovery‑Exports reproduzierbar und verfahrenskonform (Stichproben).
- Verfügbarkeit: HA‑Failover ohne Datenverlust; Restore‑Test nach Runbook erfolgreich (Element: DB/Keys/Auth‑Recovery; Mattermost: Cluster‑Failover im Datacenter).
- Performance: Definierte Meeting‑KPIs (Join‑Zeit, Audio‑Drop‑Rate, Screen‑Share‑Stabilität) in Pilot‑Lastprofilen erfüllt; bei Mattermost Calls explizit Teilnehmer‑Limits entsprechend Ressourcen validiert.
- User Adoption: definierte Aktivitätsmetriken pro Einheit (DAU/WAU), Support‑Ticket‑Rate sinkt nach Welle 2; „Shadow‑IT“-Rückgang.
Migration von Teams: pragmatische Strategie statt 1:1‑Import
Ein echter 1:1‑Umzug historischer Teams‑Chats/Channels in eine neue Plattform ist in der Praxis selten verlustfrei. Realistisches Vorgehen:
- Teams‑Daten rechtssicher exportieren und als Archiv bereitstellen (Compliance/eDiscovery‑Export): Microsoft Purview eDiscovery erlaubt Sammeln/Export von Teams‑Content.
- Automatisierte Exporte via Teams Export APIs (für definierte Scope‑/Zeiträume) – insbesondere für „Records Management“ und Übergangszeit.
- Cutover mit Koexistenz: neue Projekte/Channels in neuem System; alte Teams‑Artefakte read‑only (Policy).
- Dateien: Separat migrieren (weil Teams Files in unterschiedlichen Backends liegen). Microsoft beschreibt Teams als Hub in Microsoft 365; Dateien sind integraler Bestandteil des Ökosystems, müssen daher systematisch separat behandelt werden.
Annahmen und offene Punkte
Annahmen im Blog
- „No‑Cloud“ wurde streng interpretiert: kein Vendor‑Gateway, keine zwingende Registrierung/Telemetrie, keine Abhängigkeit von APNs/FCM oder Nextcloud Push Proxy im produktiven Soll‑Betrieb (sofern nicht explizit als Ausnahme genehmigt).
- Die Bank betreibt mindestens ein eigenes Rechenzentrum/on‑prem Infrastruktur mit Fähigkeit für HA‑Cluster und regulierte Change‑Prozesse (allgemeine Bank‑Annahme; nicht als Fakt verifiziert).
Nicht spezifizierte Anforderungen (entscheidungsrelevant)
- Nutzeranzahl (gesamt) und Peak‑Concurrency (Meetings/Calls, grosse Townhalls).
- Ob externe Föderation/Partnerzugriff erlaubt ist (DMZ/Internet) oder vollständig intern bleiben muss.
- Konkrete Aufbewahrungsfristen (z. B. Jahre) und ob „Full‑text eDiscovery“ serverseitig erforderlich ist.
- Ob PSTN/SIP Dial‑in/Dial‑out erforderlich ist (Teams‑Telephony‑Ersatz) – nur indirekt erwähnt.
- MDM‑Vorgaben (z. B. App‑Config, Zertifikate, Gerätezulassungen) und ob mobile Geräte Internetzugang haben dürfen.
- Erforderliche Security‑Zertifizierungen auf Vendor‑Ebene vs. Bank‑eigene Zertifizierung des Betriebs (SOC2/ISO‑Artefakte von Vendoren sind für Self‑Hosted nur ein Baustein und ersetzen nicht Bank‑Controls; im Blog daher nur als Due‑Diligence‑Input geführt).
