BEKOM OPEN PROMicrosoft 365 ExitSouverän statt lizenzgebunden
Microsoft 365 strukturiert ablösen: DMA-Trigger, Teams-Entbündelung und Lizenz-Eskalation als Anlass. BEKOM begleitet die Stufen-Migration zu Open-Source-Alternativen.
Auslöser für einen Microsoft-365-Exit
Microsoft 365 wurde im Mittelstand und in Konzernen über Jahre als alternativlose Office-Plattform etabliert. Mit dem Digital Markets Act (DMA) der Europäischen Union, anhaltenden Lizenz-Anpassungen und wachsenden Datensouveränitäts-Anforderungen prüfen heute zunehmend Geschäftsführungen, Aufsichtsorgane und IT-Verantwortliche, ob die Plattform langfristig tragbar bleibt. Drei Trigger führen Organisationen erfahrungsgemäß zur strategischen Bewertung — sie unterscheiden sich in regulatorischem Anlass, kommerzieller Wirkung und Risiko-Exposition.
Ein Microsoft-365-Exit betrifft geschäftskritische Kommunikations- und Kollaborationsprozesse sowie die auditfähige Auftragsverarbeitung in cloudbasierten Office-Umgebungen. Die regulatorischen Anforderungen des Digital Markets Act und anhaltende Lizenz-Anpassungen machen eine strategische Bewertung zur Compliance-Voraussetzung.
DMA und Teams-Entbündelung als regulatorischer Anlass
Der DMA hat in kurzer Zeit verändert, was bislang als gegeben galt: Bündelung, Vertragslogik und Funktions-Verteilung innerhalb der Office-Suite stehen rechtlich auf neuer Grundlage. Bestehende Lizenzverträge müssen daraufhin neu strukturiert werden.
Wesentliche Veränderungen seit Inkrafttreten:
Teams aus Office-Bundle herausgelöst – Microsoft Teams ist nicht mehr automatisch in Office-Bundles enthalten und wird separat lizenziert; bestehende Bundle-Annahmen verlieren ihre Grundlage
Vertragsanpassung bei Verlängerung erforderlich – Renewal-Termine erzwingen die Neusortierung von Lizenz-Beständen, CAL-Strukturen und Add-on-Kombinationen ohne Übergangsautomatik
Funktions-Verschiebungen zwischen Lizenzstufen – Einzelne Features wandern zwischen E3-, E5- und Add-on-Plänen; was gestern enthalten war, kann morgen Aufpreis erfordern
Marktöffnung für Alternativen erleichtert – DMA-Vorgaben zur Interoperabilität und Datenportabilität verbessern die strukturellen Voraussetzungen für einen Plattformwechsel
Für IT-Leitung und Geschäftsführung entsteht damit ein dokumentierbarer Anlass, eine strukturierte Bewertung der Optionen einzuleiten — unabhängig davon, ob am Ende Wechsel, Anpassung oder Verbleib steht.
Lizenz-Eskalation und kommerzielle Planungsunsicherheit
Parallel zu den regulatorischen Veränderungen wirken Preisanpassungen, Bündel-Verschiebungen und Vertragsbedingungen auf die langfristige Planbarkeit. Geschäftsführungen erkennen die Microsoft-365-Kostenkurve nicht mehr ohne weiteres im IT-Budget der Folgejahre.
Treibende Faktoren auf der Lizenz-Ebene:
Preisanpassungen bei E3- und E5-Plänen – wiederkehrende Erhöhungen, häufig kombiniert mit Funktions-Verschiebungen, die ein Upgrade erforderlich erscheinen lassen
Add-on-Lizenzierung für ehemals enthaltene Funktionen – Compliance-Module, Power-Platform-Bausteine und erweiterte Sicherheits-Features werden zunehmend separat ausgepreist
Software-Assurance- und Subscription-Mechanismen – komplexe Mobility-Rechte, Renewal-Stufen und Kündigungs-Pfade erschweren die Vertragsanalyse vor Verlängerungen
Drittanbieter-Tools für Backup und Archiv – externe Lösungen für Compliance-Backup, Long-Term-Archiv und eDiscovery summieren sich zur monatlichen Subscription
Eine belastbare Mehrjahres-Planung wird damit von einer Tabellenkalkulations-Aufgabe zu einer strategischen Bewertung, die Geschäftsführung und Aufsichtsorgan einbeziehen.
Datensouveränität und Compliance-Anforderungen
Branchen mit DSGVO-relevanten oder regulatorisch geschützten Daten — Kanzleien, Steuerberatung, Gesundheitswesen, Behörden, Finanzdienstleister — bewerten zunehmend, ob US-Cloud-Plattformen die langfristige Daten- und Auskunftslage tragen.
Compliance-Treiber im Mittelstand:
DSGVO-Auskunftsfähigkeit und Datenexport – Anforderung, Daten vollständig und in offenen Formaten exportieren zu können, ohne Plattform-Lock-in
US-CLOUD-Act und Drittstaaten-Übermittlung – Zugriffsmöglichkeit US-amerikanischer Behörden auf Daten in US-Anbieter-Plattformen wird in Risikoanalysen zunehmend berücksichtigt
Branchen-Anforderungen mit eigener Tiefe – BRAO §43a für Kanzleien, SGB V und PDSG im Gesundheitswesen, KRITIS-Anforderungen, BaFin-Vorgaben für Finanzdienstleister
Audit-Vorgaben für ISO 27001 und TISAX – nachvollziehbare Datenstandorte, dokumentierte Sub-Auftragsverarbeiter und prüfbare Zugriffsketten als Bestandteil der Zertifizierung
Diese Trigger summieren sich zu einem dokumentierbaren Anlass, eine geordnete Bewertung der Microsoft-365-Abhängigkeit anzustoßen — ohne damit das Ergebnis vorwegzunehmen.
Funktionsbereiche und Open-Source-Alternativen
Ein vollständiger M365-Exit umfasst typischerweise vier funktionale Bereiche, die einzeln migriert werden können. Welche Bereiche zuerst angegangen werden, hängt von Geschäftskritikalität, Regulatorik und vorhandenen Schnittstellen ab. Für jeden Bereich existieren etablierte Open-Source-Alternativen, die seit Jahren in Enterprise-Umgebungen produktiv im Einsatz sind und im Rahmen von BEKOM OPEN PRO Applications als bewährte Standardlösungen betrieben werden.
E-Mail und Kalender als Exchange-Online-Alternative
Exchange Online ist häufig der erste oder letzte Migrations-Schritt — selten ein Zwischenschritt. Open-Source-Mail-Plattformen decken Enterprise-Anforderungen an Mail, Kalender, Kontakte und Mobile-Sync vollständig ab.
Bewährte Open-Source-Mail-Plattformen:
Open-Xchange App Suite als Enterprise-Mail – integrierte Web-Oberfläche für Mail, Kalender, Kontakte und Aufgaben mit Active-Sync für mobile Endgeräte und Branding-Optionen
Zimbra Collaboration Suite als Alternative – etablierte Plattform mit langer Provider-Historie, eigene Web-Oberfläche, S/MIME, ActiveSync und SOAP-API für Drittanbieter-Integrationen
Migration über IMAP, EWS und PST-Import – etablierte Werkzeugketten für vollständige Postfach-Übertragung inklusive Ordnerstruktur, Kalendern und Kontakten ohne Datenverlust
Identitätsabgleich während Parallelphase – beide Systeme laufen parallel mit Mail-Routing über bestehende MX-Records bis zum Cutover je Stufe
Welche Plattform passt, hängt von Bestand, Mobile-Sync-Anforderungen und Schnittstellen-Tiefe ab und wird im Assessment geklärt.
Datei und Office als Ersatz für SharePoint, OneDrive und Office-Suite
OneDrive, SharePoint, Word, Excel und PowerPoint bilden zusammen den am tiefsten eingebetteten Microsoft-365-Bereich. Die Open-Source-Kombination Nextcloud plus Office-Suite deckt diese Schichten auditfähig und mit kontrollierter Datenhaltung ab.
Plattformen für Datei und Office:
Nextcloud als auditfähige Datei-Plattform – File-Sync, Sharing-Workflows, Versionierung, externes Sharing mit Zeit- und Passwort-Schutz und Audit-Logs als Standard
Collabora Online als browserbasierte Office-Suite – Texte, Tabellen und Präsentationen direkt im Browser, kompatibel mit OOXML-Formaten und LibreOffice-Engine
OnlyOffice als alternative Office-Plattform – eigene OOXML-Engine mit hoher Microsoft-Office-Kompatibilität, integrierbar in Nextcloud oder als eigenständige Plattform
OOXML-Kompatibilität als Migrations-Pfad – Bestandsdokumente in .docx/.xlsx/.pptx werden ohne Konvertierung übernommen, externe Empfänger erhalten gewohnte Formate
SharePoint-Bibliotheken werden im Rahmen der Stufen-Migration nach Nextcloud überführt; Berechtigungen und Versionierung werden geprüft und so weit wie möglich erhalten.
Chat und Konferenz als Teams-Alternative
Teams ist über Jahre tief in Geschäftsprozesse integriert — Chat, Konferenz, Webinare und Datei-Freigaben in einem Werkzeug. Eine schrittweise Ablösung ist die Regel, nicht der harte Schnitt; Funktionen werden auf spezialisierte Plattformen verteilt.
Plattformen für Kommunikation und Konferenz:
Rocket.Chat oder Element für Chat – Team-Channels, Direktnachrichten, Threading und Bridges zu anderen Plattformen mit Federation-Optionen für externe Gespräche
Jitsi als Audio- und Video-Konferenz – browserbasierte Konferenz-Plattform mit niedriger Einstiegshürde, ohne Client-Installation und mit eigener Plattform-Bereitstellung
BigBlueButton für Webinare und Schulungen – Konferenz-Plattform mit Whiteboard, Breakout-Rooms und Aufzeichnungs-Funktion, eingesetzt im Bildungs- und Behörden-Umfeld
Federation und Bridges in der Übergangsphase – Matrix-Bridges und SIP-Gateways erlauben gemischten Betrieb zwischen Teams und Open-Source-Plattformen während der Stufe
Komplexere Power-Platform-Integrationen oder spezifische Branchen-Apps im Teams-Store werden in der Bestandsaufnahme identifiziert und im Pilot validiert.
Identity als Entra-ID-Alternative
Identity-Migration ist einer der heikelsten Bereiche eines M365-Exits — Single Sign-On, Mehrfaktor-Anmeldung und Berechtigungs-Strukturen wirken in alle anderen Schichten hinein. Keycloak hat sich als Open-Source-Identity-Provider in Enterprise-Umgebungen durchgesetzt.
Identity-Bausteine im M365-Exit:
Keycloak als zentraler Identity-Provider – Open-Source-IdP mit User-Management, Realms, Rollen, Gruppen und Theming, eingesetzt in Branchen mit hoher Compliance-Tiefe
SAML, OIDC und OAuth 2.0 als Standards – Standard-Protokolle für SSO und API-Authentifizierung; Anwendungen werden ohne Vendor-spezifische Erweiterungen angebunden
SCIM für automatisierte Provisionierung – User-Lifecycle-Verwaltung über System for Cross-domain Identity Management mit Drittsystemen wie HR-Systemen
Federation mit Entra ID in Übergangsphase – beide Systeme laufen parallel mit Trust-Beziehung; migrierte Workloads nutzen Keycloak, noch nicht migrierte weiterhin Entra ID
Die Doppel-Phase ist bewusst eingeplant — erst nach dem letzten Cutover wird Entra ID vollständig zurückgebaut.
Migrationspfad in vier Phasen
Ein M365-Exit ist keine Stichtagsaktion, sondern ein strukturierter Prozess über mehrere Quartale. Die Reihenfolge orientiert sich an der Geschäftskritikalität, an den vorhandenen Daten-Volumina und an den Lizenz-Renewal-Terminen. BEKOM begleitet die Migration im Rahmen von Migration und Exit als strategische Aufgabe als wiederverwendbares Vorgehensmodell.
Phase 1: Bestandsaufnahme und Strategie
In Phase 1 wird der vollständige Microsoft-365-Footprint dokumentiert und das Zielbild gemeinsam mit den Fachbereichen erarbeitet. Das Ergebnis ist eine schriftliche Strategie als Grundlage für Geschäftsführung, Aufsichtsorgan und IT-Leitung.
Inhalte der Phase im Überblick:
Lizenz-Inventur und Vertragslage – aktive Lizenzen, Bundle-Strukturen, Add-on-Lizenzen, Software-Assurance-Status und Renewal-Termine als Grundlage für die Migrations-Planung
Workload-Mapping nach Geschäftskritikalität – aktive Nutzung pro Funktionsbereich, Daten-Volumina, Mobile-Sync-Anforderungen und besondere Schmerzpunkte aus Anwender-Sicht
Schnittstellen- und Drittsystem-Erfassung – Power-Automate-Workflows, Power-Apps, Branchen-Anwendungen mit M365-Anbindung, Marketplace-Add-ons und PowerShell-/Graph-API-Skripte
Strategie-Dokument und Stufen-Plan – schriftliche Phasen-Reihenfolge, identifizierte Risiken, vorgeschlagene Open-Source-Plattformen und Service-Design-Skizze als Verhandlungs-Grundlage
Der Übergang in Phase 2 erfolgt erst nach Freigabe durch Geschäftsführung und IT-Leitung — Strategie ist ein abgegrenztes Paket mit eigener Abnahme.
Phase 2: Pilot in einer Abteilung oder Funktion
In Phase 2 wird ein eingegrenzter Bereich pilotiert. Häufig ist dies die IT-Abteilung selbst oder ein klar abgegrenzter Geschäftsbereich. Der Pilot validiert Annahmen, identifiziert übersehene Schnittstellen und liefert Schulungs-Material für die Stufen-Migration.
Inhalte der Pilot-Phase:
Pilot-Bereich-Auswahl mit Geschäftsführung – Auswahl nach Risiko-Toleranz, Komplexität und Lerneffekt für die spätere Stufen-Migration; Personalrat ist eingebunden
Daten-Test-Migration und Validierung – Postfächer, Dateien, Kalender, Kontakte und Berechtigungen werden migriert und auf Vollständigkeit geprüft
Anwender-Schulung und Onboarding-Material – Schulungs-Inhalte, FAQ-Sammlungen und kontextbezogene Anleitungen entstehen aus dem Pilot und werden für die Stufe wiederverwendet
Pilot-Auswertung und Strategie-Anpassung – Ergebnisse werden dokumentiert und mit der Geschäftsführung abgestimmt; offene Punkte fließen in die Stufen-Planung der Phase 3 ein
Der Pilot ist ein eigenes Auftrags-Paket mit definiertem Umfang — die Investitions-Entscheidung für die Stufen-Migration fällt erst nach Pilot-Abschluss.
Phase 3: Stufen-Migration nach Geschäftsbereich
In Phase 3 erfolgt die eigentliche Migration in Stufen. Jede Stufe umfasst einen Geschäftsbereich oder Standort und durchläuft denselben strukturierten Prozess. Microsoft 365 läuft parallel weiter, bis alle Stufen abgeschlossen sind.
Inhalte je Stufe:
Stufen-Definition nach Geschäftsbereich – Reihenfolge nach Kritikalität, Abhängigkeiten und Saisonalität; jede Stufe ist ein eigener Auftrags-Block mit definiertem Lieferumfang
Daten-Migration mit Vollständigkeits-Prüfung – Postfächer, SharePoint-Bibliotheken, OneDrive-Inhalte und Berechtigungen werden überführt und auf Vollständigkeit geprüft
Cutover und Hypercare im Wartungsfenster – produktiver Umstieg in vereinbartem Fenster, anschließende Hypercare-Phase mit erhöhter Bereitschaft für Anwender-Fragen
Parallelbetrieb bis zum letzten Cutover – Microsoft 365 und Open-Source-Plattformen laufen parallel, Identity ist über Federation gekoppelt, Mail-Routing pro Domäne dokumentiert
Die Stufen-Reihenfolge ist im Strategie-Dokument festgelegt und kann zwischen den Stufen anhand der Lerneffekte angepasst werden.
Phase 4: Cutover und Lizenz-Reduktion
Nach Abschluss aller Stufen folgt der finale Cutover. Microsoft-365-Lizenzen werden gestaffelt zurückgegeben, parallel laufende Systeme abgeschaltet und Daten-Archive auf der Open-Source-Plattform konsolidiert.
Inhalte der Konsolidierungs-Phase:
Finaler Cutover und Identity-Rückbau – Entra ID wird vollständig zurückgebaut, Keycloak übernimmt alleinige Identity-Hoheit, Federation wird abgeschaltet und dokumentiert
Lizenz-Rückgabe nach Renewal-Logik – Microsoft-365-Lizenzen werden gestaffelt zurückgegeben, abhängig von Vertragsende und tatsächlicher Nutzungs-Reduktion pro Bereich
Daten-Konsolidierung und Archiv-Strategie – historische Bestände aus Exchange, SharePoint und OneDrive werden auf der Open-Source-Plattform konsolidiert oder in Read-Only-Archiv überführt
Service-Übergabe und DSGVO-Auskunftsfähigkeit – Service-Design für den laufenden Betrieb wird übergeben, Datenexport ist vollständig dokumentiert, Auskunfts-Anfragen sind im neuen System abbildbar
Die letzte Phase sichert, dass aus der Migration keine Altlasten bleiben und die Open-Source-Plattformen als vollwertige Basis arbeiten.
Was unterscheidet den BEKOM-Pfad von einem reinen Anbieter-Wechsel
Ein Microsoft-365-Exit kann in unterschiedlichen Konstellationen umgesetzt werden: mit dem eigenen IT-Team, durch einen Wechsel zu einem anderen Cloud-Anbieter (z. B. Google Workspace) oder durch einen strukturierten Open-Source-Pfad mit einem deutschen Betriebspartner. Drei Merkmale prägen die Zusammenarbeit mit BEKOM in diesem Kontext — sie betreffen die Portabilität der Zielplattform, die Reversibilität zwischen den Phasen und den deutschen Vertrags- und Datenraum.
Open-Source-Pfad statt Re-Lock-in beim nächsten Anbieter
Ein Anbieter-Wechsel zu Google Workspace oder einer anderen proprietären Cloud ersetzt die Lizenz-Bindung an Microsoft nur durch eine andere Bindung. Ein Open-Source-basierter Exit hingegen schafft strukturelle Datensouveränität — die Plattformen können im deutschen Rechenzentrum, bei einem zertifizierten Cloud-Partner oder On-Premise betrieben werden.
Was Portabilität in der Praxis bedeutet:
Datenportabilität als Architektur-Prinzip – offene Datenformate (Maildir, OOXML, JSON-Exports) und dokumentierte Schnittstellen statt Proprietary-Lock-in mit eigenen Datentypen
Wechsel zwischen Betriebsmodellen ohne Datenneuanlage – Übergang zwischen On-Premise, deutschem Rechenzentrum und zertifiziertem Cloud-Partner ohne erneute Migration
Keine erneute Lizenz-Eskalation in fünf Jahren – Investition liegt in Migration und laufendem Plattform-Betrieb statt in steigenden Subscription-Preisen eines proprietären Anbieters
Methodische Migration statt Hopping – ein Exit, dokumentiert und auditfähig, statt periodischer Plattformwechsel mit jeweils neuem Migrations-Aufwand
Damit wird die Strategie-Frage „raus aus M365 — wohin?" nicht durch eine zweite Anbieter-Bindung beantwortet, sondern durch eine strukturelle Architektur-Entscheidung.
Strukturierte Phasen mit Reversibilität zwischen den Schritten
Eine Microsoft-365-Ablösung ist eine wesentliche Investitions-Entscheidung. BEKOM strukturiert den Pfad in abgegrenzten Paketen, sodass die Geschäftsführung nach jeder Phase neu entscheidet — ohne sich vorab auf den Gesamtumfang festzulegen.
Reversibilität zwischen Phasen:
Strategie-Phase als eigenständiger Auftrag – schriftliche Strategie ist abnahmefähig auch ohne Folge-Auftrag und dient der internen Verhandlung in Geschäftsführung und Aufsichtsorgan
Pilot vor Stufen-Entscheidung – Pilot ist abgegrenztes Paket mit eigener Abnahme; nach Pilot-Auswertung entscheidet die Geschäftsführung über Umfang der Stufen-Migration
Stufen-Pakete mit eigenem Lieferumfang – jede Stufe ist ein eigener Auftrags-Block; Stufen können verzögert, neu sortiert oder ausgesetzt werden, wenn Geschäftslage oder Lizenz-Lage es erfordert
Dokumentiertes Service-Design für laufenden Betrieb – Service-Beschreibung mit Verantwortungsmatrix ist Bestandteil jeder Stufe, sodass auch ein Teil-Exit auditfähig dokumentiert bleibt
Damit bleibt die Investitions-Entscheidung modular — eine Eigenschaft, die ein Big-Bang-Wechsel zu einem anderen Cloud-Anbieter strukturell nicht bietet.
Deutscher Vertrags- und Datenraum mit dokumentierter Sub-Auftragskette
Vertrag, Service-Beschreibung und technische Eingriffe erfolgen in deutschem Recht und in deutscher Sprache. Datenstandorte und Sub-Auftragsverarbeiter sind dokumentiert; Eskalationen erfolgen ohne Zeitzonen-Verzögerung und ohne Übersetzungs-Schleifen.
Praktische Auswirkungen im Alltag:
Server, Speicher und Backups in deutschen BEKOM-Rechenzentren – mit dokumentiertem Standort, kontrolliertem physischem Zugriff und ohne Datenweitergabe an Anbieter mit US-CLOUD-Act-Bindung
Sub-Auftragsverarbeiter-Liste als Vertrags-Bestandteil – jeder Sub-Auftragnehmer im deutschen Rechtsraum; Änderungen werden im definierten Verfahren angekündigt und sind kündbar
Vertragstexte, SLAs und Support in Deutsch – kein Übersetzungs-Abgleich nötig, keine Rechtsraum-Brüche im Streitfall, klare Auslegungs-Praxis nach deutschem Recht
Eskalation ohne Zeitzonen- oder Sprach-Verzögerung – Ansprechpartner mit Erfahrung in mittelständischen Betriebsrealitäten, direkte Erreichbarkeit ohne internationales Ticket-Routing
Das unterscheidet sich strukturell von einer Hyperscaler-Migration mit globalem Support-Modell und ist für Organisationen mit Compliance- oder Datenschutz-Anforderungen ein dokumentierbares Kriterium gegenüber Aufsichtsorgan und Auditoren.
Kostenstruktur eines M365-Exits
Ein M365-Exit wirkt auf drei Kostenebenen über den Lebenszyklus. Pauschale Einsparungen verspricht BEKOM nicht — ein strukturiertes Assessment ordnet die Ebenen gegen die heutige Ausgangslage und liefert eine belastbare Vergleichsgrundlage. Die tatsächliche Kostenwirkung hängt von Lizenz-Bestand, Daten-Volumen, Schnittstellen-Komplexität und Renewal-Terminen ab und wird pro Organisation ermittelt.
Bestandsseite – heute Microsoft 365
Auf der Bestandsseite wirken nicht nur die monatlichen Lizenzkosten, sondern auch gebundenes Personal, Drittanbieter-Tools und Compliance-Aufwände. Ein vollständiger Vergleich erfasst alle vier Treiber statt nur den sichtbaren Lizenz-Anteil.
Kostentreiber im laufenden Microsoft-365-Betrieb:
Lizenzkosten pro Nutzer und Monat – E3- oder E5-Pläne mit jährlichen Preisanpassungen und Funktions-Verschiebungen zwischen Lizenzstufen
Add-on-Lizenzen für Teams, Power Platform, Compliance-Module – seit DMA und Bundle-Auflösung zunehmend separat ausgepreist, mit eigener Renewal-Logik
Drittanbieter-Tools für Backup und Long-Term-Archiv – externe Subscriptions für Compliance-Backup, eDiscovery und Archiv-Pflichten außerhalb der Standard-Microsoft-Retention
Personalkapazität für Administration und Compliance-Reporting – gebundene Stunden für Lizenz-Pflege, CAL-Zählungen, Audit-Vorbereitung und Reporting an Aufsichtsorgan
Im Assessment werden diese Treiber gegen den heutigen Bestand gerechnet und ergeben die Bestandsseite des Vergleichs.
Migrationsphase – einmalige Aufwände
Während der Migration entstehen einmalige Aufwände, die als abgegrenzte Pakete vereinbart werden. Der Vorteil: jede Phase hat eigenen Umfang und eigene Abnahme — Investitions-Entscheidung bleibt zwischen den Phasen reversibel.
Einmalige Migrations-Aufwände:
Strategie-Entwicklung mit Geschäftsführung – Lizenz-Inventur, Workload-Mapping, Schnittstellen-Erfassung und Stufen-Plan; ein eigenständiges Beratungs-Paket mit Abnahme
Pilot in einer Abteilung mit Auswertung – Aufbau der Open-Source-Plattformen, Daten-Test-Migration und Anwender-Schulung in eingegrenztem Bereich
Daten-Migration je Stufe und Schulung – pro Stufe Postfächer, Dateien, Berechtigungen und Anwender-Schulung mit dokumentierter Vollständigkeits-Prüfung
Parallel-Lizenzierung während der Übergangsphase – Microsoft 365 läuft bis zum letzten Cutover weiter; Doppel-Kosten in der Übergangsphase werden im Stufen-Plan berücksichtigt
Die Anteile werden im Angebot getrennt ausgewiesen, sodass interne Budgetbegründungen und spätere Vergleiche sauber möglich bleiben.
Zielseite – laufender Open-Source-Betrieb
Auf der Zielseite verschieben sich die Treiber von Lizenz- zu Plattform-Kosten. Der Lizenz-Anteil ist niedriger oder entfällt; dafür entstehen Kosten für Plattform-Betrieb, Speicher und optional Beratung.
Kostenebenen im laufenden Betrieb:
Monatliche Plattform-Service-Pauschale – abhängig von Anzahl Nutzern, Plattform-Umfang (Mail, Datei, Office, Chat, Identity), SLA-Stufe und Service-Modell (Fully Managed oder Co-Managed)
Speicher- und Backup-Kosten im deutschen Rechenzentrum – nach tatsächlichem Volumen, mit definierten Aufbewahrungs-Fristen je Datenklasse und protokollierten Restore-Tests
Vertragliche Modularität pro Plattform – Mail, Datei, Office, Chat und Identity sind als Bausteine separat oder kombiniert vereinbar; spätere Erweiterungen sind ohne Komplettanpassung möglich
Optional ergänzende Beratungs-Pakete – Schulungen, Architektur-Reviews und Compliance-Begleitung sind als getrennte Pakete buchbar, ohne in der monatlichen Pauschale zu wachsen
Pauschale Einsparungs-Versprechen vermeidet BEKOM bewusst — die belastbare Aussage entsteht erst aus dem Bestands-Vergleich des konkreten Falls.
Häufige Fragen zum M365-Exit
Wir nutzen Microsoft 365 seit Jahren — wo fangen wir an?
Der Einstieg ist eine Bestandsaufnahme der aktuellen Microsoft-365-Nutzung: aktive Lizenzen, eingesetzte Workloads, Schnittstellen und regulatorisch relevante Datenbestände. Diese Aufnahme liefert eine schriftliche Strategie mit priorisierten Migrations-Stufen. Anschließend startet ein Pilot in einer eingegrenzten Abteilung. Erst nach erfolgreichem Pilot beginnt die Stufen-Migration der gesamten Organisation, abgestimmt mit Geschäftsführung und Personalrat.
Können wir Teams ablösen, ohne Produktivität zu verlieren?
Ein Teams-Ersatz hängt davon ab, welche Funktionen tatsächlich genutzt werden. Chat-Funktionen lassen sich mit Rocket.Chat oder Element ablösen, Konferenzen mit Jitsi oder BigBlueButton, Datei-Freigaben mit Nextcloud. Komplexer wird es bei tiefen Power-Platform-Integrationen oder spezifischen Branchen-Apps im Teams-Store. Diese werden in der Bestandsaufnahme identifiziert und im Pilot validiert. Eine schrittweise Ablösung ist die Regel, nicht der harte Schnitt.
Was passiert mit unseren bestehenden SharePoint-Daten?
SharePoint-Daten werden im Rahmen der Stufen-Migration nach Nextcloud überführt. Bibliotheks-Strukturen, Berechtigungen, Versionierung und Metadaten werden geprüft und so weit wie möglich erhalten. Daten-Migration ist ein eigenständiger Schritt jeder Stufe und wird mit Test-Migrationen vor dem Cutover abgesichert. Archivische SharePoint-Bestände können separat in einer Read-Only-Plattform aufbewahrt werden, sodass historische Zugriffe weiter möglich sind.
Wie lange dauert eine M365-Ablösung typischerweise?
Die Dauer hängt von Organisation, Daten-Volumen und Phasen-Reihenfolge ab. Strategie- und Pilot-Phase erstrecken sich über einige Monate; die Stufen-Migration erfolgt im Anschluss bereichsweise. Der Gesamtzeitraum von Strategie bis Lizenz-Reduktion verteilt sich typischerweise über mehrere Quartale. Ein verbindlicher Zeitrahmen wird im Service-Design pro Stufe festgelegt — ohne pauschale Versprechen vorab. Geschäftsführungen erhalten dadurch Planungssicherheit ohne harte Vorab-Bindungen.
Welche Open-Source-Alternativen sind enterprise-tauglich?
Nextcloud, Open-Xchange, Collabora Online, OnlyOffice, Rocket.Chat, Element und Keycloak sind seit Jahren in Enterprise-Umgebungen produktiv im Einsatz. BEKOM betreibt diese Plattformen als bewährte Standardlösungen im Rahmen von BEKOM OPEN PRO Applications. Die Auswahl im konkreten Projekt richtet sich nach Anwendungsfall, Schnittstellen und Compliance-Anforderungen — nicht jeder Mittelständler benötigt jede Plattform. Die Strategie-Phase klärt die optimale Kombination für die jeweilige Organisation.
Wir sind in einem laufenden M365-Enterprise-Vertrag — wann ist der Einstieg sinnvoll?
Der Einstieg orientiert sich am Renewal-Termin und an der Geschäftslage. Strategie-Phase und Pilot werden häufig vor der nächsten Vertragsverlängerung gestartet, sodass die Stufen-Migration parallel zum letzten Vertragsjahr läuft und Lizenzen gestaffelt zurückgegeben werden. Bei längerer Restlaufzeit kann der Pilot-Start auch unabhängig vom Renewal erfolgen, um die Strategie-Annahmen frühzeitig zu validieren. Die Abstimmung erfolgt im Strategiegespräch unter Berücksichtigung aktueller Vertragslage.
Wie ist die Kostenstruktur des laufenden Plattform-Betriebs nach der Migration?
Die Kosten setzen sich aus einer monatlichen Plattform-Service-Pauschale zusammen, deren Höhe sich nach Anzahl Nutzern, Plattform-Umfang (Mail, Datei, Office, Chat, Identity), SLA-Stufe und Service-Modell richtet. Hinzu kommen Speicher- und Backup-Kosten im deutschen Rechenzentrum nach tatsächlichem Volumen. Im Rahmen des Assessments erstellt BEKOM eine individuelle Kalkulation auf Basis der Anforderungen. Alle Leistungen sind im Service-Design-Dokument dokumentiert.
Welche M365-Daten lassen sich beim Exit übernehmen, welche müssen neu strukturiert werden?
Übernommen werden in der Regel: Postfächer mit Ordnerstruktur und Anhängen (IMAP/EWS-Export), OneDrive-/SharePoint-Inhalte mit Versionen und Berechtigungen, Kalender und Kontakte (CalDAV/CardDAV bzw. ICS/VCF), Teams-Chat-Verläufe und gemeinsam genutzte Dateien (Graph-API-Export), Identitäten und Gruppen (Entra-ID-Export → IdP der neuen Plattform). Neu strukturiert werden müssen typischerweise: Power-Automate-Flows, Power-BI-Modelle, M365-spezifische App-Berechtigungen, Compliance-Labels und Retention-Policies sowie Funktionen, die kein direktes Open-Source-Pendant haben. Im Service-Design-Dokument steht vor dem Cut-Over fest, welche Funktionen 1:1 abgebildet, welche durch Äquivalente ersetzt und welche bewusst abgeschaltet werden.
Microsoft-365-Exit-Assessment anfragen
Der Einstieg ist ein strukturiertes Assessment der aktuellen Microsoft-365-Landschaft. Auf Basis der Bestandsaufnahme entsteht eine schriftliche Migrations-Strategie mit priorisierten Stufen, identifizierten Risiken und einem belastbaren Phasen-Plan — als Grundlage für Geschäftsführung, IT-Leitung und Aufsichtsorgan. Das Assessment ist ein eigenständiges Paket mit eigener Abnahme; die Investitions-Entscheidung über Pilot und Stufen-Migration fällt erst nach Strategie-Freigabe.
Ein Microsoft-365-Exit-Assessment verschafft Klarheit über die technische Umsetzbarkeit und regulatorische Konformität Ihres Ausstiegsszenarios. BEKOM erstellt eine detaillierte Bestandsaufnahme Ihrer aktuellen Office-365-Landschaft, entwickelt eine Architektur-Empfehlung für Open-Source-Alternativen und definiert den konkreten Betriebsumfang für eine DMA-konforme Lösung. Das Service-Design dokumentiert Migrations-Pfade, Datenportabilität und Übergangsszenarien für eine souveräne IT-Strategie.
Bestandsaufnahme der M365-Landschaft
In einem ersten Termin erfasst BEKOM die aktuelle Microsoft-365-Landschaft: aktive Lizenzen, genutzte Workloads, Drittsystem-Anbindungen und Compliance-Anforderungen. Sie erhalten eine strukturierte Aufnahme und ein klares Bild des heutigen Footprints — als Grundlage für die folgende Strategie-Phase.
Schriftliche Migrations-Strategie als Verhandlungs-Grundlage
Auf Basis der Bestandsaufnahme entsteht eine schriftliche Migrations-Strategie mit Phasen-Reihenfolge, identifizierten Risiken, Stufen-Plan und vorgeschlagenen Open-Source-Plattformen. Die Strategie ist Ihre Verhandlungs- und Planungsgrundlage gegenüber Geschäftsführung und Aufsichtsorgan — Sie entscheiden, ob und in welchem Umfang umgesetzt wird.
Pilot vereinbaren und starten
Sofern die Strategie freigegeben wird, startet ein Pilot in einer eingegrenzten Abteilung. Der Pilot validiert die Strategie, liefert Schulungs-Material und schafft die Grundlage für die anschließende Stufen-Migration. Das Pilot-Ergebnis wird gemeinsam ausgewertet und entscheidet über die Fortsetzung — ohne Vorab-Festlegung auf den Gesamtumfang der Stufen-Migration.