BEKOM OPEN PROSaaS-Exit-StrategieStufen-Rollout, Datenportabilität
Exit-Strategien für proprietäre Anwendungs-Suiten: Stufen-Rollout, Datenportabilität und Betriebsprinzipien für strukturierte SaaS-Ablösung mit Open-Source-Alternativen.
Migration und Exit als strategische Aufgabe
Der Ausstieg aus proprietären SaaS-Suiten ist für viele Organisationen eine strategische Option geworden – ob Office-Suiten, E-Mail-Plattformen, Kollaborations-Umgebungen oder Fachanwendungen. Auslöser sind Kostenentwicklungen, Compliance-Anforderungen, Vendor-Lock-in-Sorgen oder die bewusste Entscheidung für digitale Souveränität. Gleichzeitig ist die Migration kein Triviales: Tausende Mitarbeitende, Millionen Datensätze, komplexe Berechtigungsstrukturen und eingebettete Workflows stehen auf dem Spiel. Für konkrete Produkt-Ablösungen verweist die Seite auf dedizierte Szenario-Seiten – z. B. den Microsoft 365 Exit mit DMA-Trigger, Stufenmigration und Open-Source-Alternativen.
Migration-Projekte sind geschäftskritisch, da sie alle zentralen Geschäftsprozesse von E-Mail-Kommunikation bis zur Dokumentenverwaltung betreffen. Der operative Betrieb darf während der Übergangsphase nicht unterbrochen werden, da Auftragsverarbeitung und standortübergreifende Kollaboration eine durchgängige Verfügbarkeit als Betriebsvoraussetzung erfordern. → BEKOM OPEN PRO Applications
Warum Migrations-Strategie strategisch ist
Die Art, wie eine Migration geplant und durchgeführt wird, prägt die Erfolgswahrscheinlichkeit, die Akzeptanz der neuen Plattform und die langfristige Handlungsfähigkeit der Organisation.
Strategische Dimensionen:
- Auslöser und Ziele: Was ist der eigentliche Grund für den Wechsel, und was soll konkret erreicht werden?
- Migrationstempo: Big Bang oder Stufen-Rollout, wie wird die Balance zwischen Risiko und Dauer gefunden?
- Datenportabilität: Welche Daten werden migriert, welche archiviert, welche bewusst nicht übernommen?
- Rollback-Fähigkeit: Wie lange bleibt ein Weg zurück möglich, und wann wird er endgültig verschlossen?
Für Geschäftsführung und IT-Leitung bedeutet das: Migration ist kein technisches Projekt, sondern ein organisatorisches Transformations-Vorhaben mit erheblicher Außenwirkung.
Was BEKOM OPEN PRO Migration umfasst
BEKOM OPEN PRO Applications betrachtet Migration als strukturiertes Transformations-Vorhaben. Die Kernaussage: Jede Migration ist individuell; die Ausgangslage, die Zielbilder und die internen Rahmenbedingungen entscheiden über die passende Strategie. Das methodische Gerüst gilt unabhängig vom konkreten Ausgangsprodukt.
Inhaltlicher Scope (SaaS-übergreifend):
- Migrationspfad-Typen: vollständige Ablösung, Teilmigration, Koexistenz
- Daten-Klassifizierung und Portabilitätsstrategien für verschiedene Datenarten
- Betriebsprinzipien für strukturierte Migrationsprojekte (Stufen, Parallelbetrieb, Rollback)
- Betriebsmodelle nach Abschluss der Migration: interner Betrieb, Managed Services oder Mischform
Für produktspezifische Migrationen existieren dedizierte Szenario-Seiten mit DMA-/Lizenz-Triggern, konkreten Werkzeug-Empfehlungen und branchenspezifischen Aspekten. Sie knüpfen inhaltlich an dieses Dach-Konzept an und vertiefen die Umsetzung für einen klar definierten Ausgangsstack.
BEKOM unterstützt Organisationen bei der strategischen Planung und operativen Umsetzung – von der initialen Evaluierung bis zur vollständigen Ablösung der Ursprungsplattform.
Migrationspfad-Typen im Überblick
Migrationspfade unterscheiden sich je nach Ursprungsplattform, Zielbild und Risikotoleranz. Unabhängig vom konkreten Produkt lassen sich drei methodische Pfad-Typen unterscheiden, die jeweils eigene Anforderungen an Planung und Werkzeuge stellen.
Vollständige Ablösung mit Stichtag
Bei der vollständigen Ablösung wird die Ursprungsplattform in einem klar definierten Zeitraum komplett durch die Zielumgebung ersetzt. Typisch bei Lizenz-Auslauf, regulatorischen Deadlines oder klaren Kostensignalen.
Charakteristika:
Klarer Cutover-Zeitpunkt für den produktiven Wechsel, vorbereitet durch Pilot- und Parallelbetrieb
Gesamte Datenlandschaft wird migriert – bewusste Entscheidungen über Archive und nicht übernommene Inhalte
Höhere Projektgeschwindigkeit, aber auch höheres Risiko bei Fehlern
Change-Kommunikation muss intensiv begleitet werden, da alle Nutzer gleichzeitig betroffen sind
Dieser Pfad passt, wenn der Lizenzkontrakt ohnehin endet oder das Unternehmen strategisch einen klaren Schnitt setzen will. Risiko und Aufwand sind hoch; der Gewinn ist eine saubere Zielumgebung ohne parallele Altlasten.
Stufenweise Ablösung mit Teilmigrationen
Die stufenweise Ablösung ist das methodisch häufigste Muster. Einzelne Teilbereiche (Datenkategorien, Abteilungen, Funktionsgruppen) werden nacheinander migriert, während die übrigen Bereiche zunächst in der Ursprungsplattform bleiben.
Typische Merkmale:
Datei-/Dokumentenmigration zuerst: die Zielplattform übernimmt Ablage und Kollaboration, Fachanwendungen folgen später
Identity-Migration als Fundament: zentrale Authentifizierung wird frühzeitig an die Zielplattform übergeben, auch verbleibende Alt-Komponenten melden sich darüber an
Projekt- oder Team-basierte Piloten: einzelne Gruppen wechseln früh, liefern Erfahrungswerte für den breiten Rollout
Rückweg bleibt pro Stufe erhalten: nach erfolgreichem Cutover einer Stufe kann die nächste beginnen, vorherige Stufen bleiben stabil
Dieser Pfad reduziert Risiko, verlängert die Projektlaufzeit aber deutlich. Er ist die Regel bei komplexen Umgebungen mit vielen Abhängigkeiten.
Dauerhafte Koexistenz mit selektiver Migration
Nicht jede Organisation muss oder will vollständig aussteigen. In vielen Fällen ist eine dauerhafte Koexistenz sinnvoll: bestimmte Bereiche werden auf die Open-Source-Zielplattform migriert, andere verbleiben bewusst in der Ursprungsplattform.
Typische Merkmale:
Sensible Daten und Compliance-kritische Workloads auf die Open-Source-Plattform, weniger sensible Daten bleiben beim Alt-Anbieter
Identity-Föderation: ein zentraler Identity-Provider bedient beide Plattformen mit gemeinsamen Rollen und Berechtigungen
Klare Leitlinien, welche Datenklassen und Prozesse wohin gehören – dokumentiert und in Governance verankert
Laufende Re-Evaluierung: Koexistenz ist kein Endzustand, sondern ein bewusst gewählter Zwischenschritt
Dieser Pfad passt für Organisationen mit differenzierten Anforderungen, etwa regulierte Branchen mit gemischter Datenlandschaft oder verteilte Konzerne mit unterschiedlichen Länderanforderungen.
Produktspezifische Szenarien
Für konkrete Ausgangsstacks – Microsoft 365, Google Workspace, Dropbox, Salesforce, Atlassian-Cloud und weitere – existieren dedizierte Szenario-Seiten mit produkt-spezifischen Werkzeugen, Trigger-Ereignissen und Migrationsschritten.
Die Pfad-Typen oben bilden das methodische Dach; die Szenario-Seiten vertiefen die Umsetzung je Ausgangsstack. Aktuell publiziert: Microsoft 365 Exit als strukturierter Pfad zu Open-Source-Alternativen mit DMA-Trigger und Stufenmigration.
Teilmigrationen reduzieren Risiko und erlauben Lerneffekte vor der Vollmigration. Sie sind oft der pragmatische Einstieg für größere Organisationen mit komplexen Strukturen und hoher Änderungsdichte.
Betriebsprinzipien für strukturierte Migrationen
Migrations-Projekte im produktiven Einsatz unterscheiden sich grundlegend von einfachen Software-Installationen. Drei Bereiche sind entscheidend: Planung und Stufen-Rollout, Parallelbetrieb und Daten-Synchronisation sowie Change-Kommunikation und Nutzer-Begleitung.
Planung und Stufen-Rollout
Eine strukturierte Migration folgt einem klaren Stufenplan. Willkürliche Reihenfolge führt zu Stress, ungeplanten Abhängigkeiten und frustrierten Nutzern.
Architektur-Prinzipien:
Inventarisierung vor Migration: alle Anwendungen, Daten, Integrationen und Nutzergruppen werden erfasst
Daten- und Berechtigungs-Klassifizierung: welche Inhalte sind kritisch, welche können zuletzt migriert werden
Stufenplan: Reihenfolge der Nutzergruppen und Teilmigrationen mit Meilensteinen und Kontroll-Checkpoints
Dokumentierte Rollback-Pfade pro Stufe: was passiert, wenn eine Migration unerwartete Probleme verursacht
Der Stufen-Rollout erlaubt die schrittweise Ablösung ohne Stichtagsrisiko. Kritische Gruppen werden erst migriert, wenn die Zielarchitektur in der Praxis stabil läuft.
Parallelbetrieb und Daten-Synchronisation
Während der Migration laufen alte und neue Plattform parallel. Die Synchronisation dazwischen ist ein eigenes Teilthema, das sorgfältig geplant wird.
Kernprinzipien:
Einheitliche Identität während der Parallelphase: ein Nutzer meldet sich mit gleichen Credentials auf beiden Seiten an
Bidirektionale Synchronisation kritischer Inhalte, wo möglich, oder klare Handover-Regeln pro Datensatz
Regelmäßige Konsistenz-Prüfungen: Delta-Reports zeigen, wo Inhalte auseinanderlaufen oder fehlerhaft repliziert wurden
Klarer Cutover-Zeitpunkt pro Stufe: der Moment, ab dem die alte Plattform nicht mehr Schreibzugriff für die migrierte Gruppe hat
Parallelbetrieb ist ressourcenintensiv – sowohl technisch als auch organisatorisch. Er wird so kurz wie möglich und so lang wie nötig geplant, abhängig von Risikotoleranz und Komplexität der Migration.
Change-Kommunikation und Nutzer-Begleitung
Die technische Migration ist nur die halbe Arbeit. Ohne strukturierte Kommunikation und Begleitung der Nutzer scheitert auch der technisch beste Migrationsplan.
Umsetzung:
Regelmäßige Information über Stand, nächste Schritte und konkrete Auswirkungen auf einzelne Nutzergruppen
Schulungen vor der Migration: Nutzer lernen die neue Plattform kennen, bevor sie sie produktiv nutzen
Ansprechpartner für Fragen und Probleme: dedizierte Migrations-Helpdesks mit klaren Eskalationswegen
Feedback-Schleifen: Nutzerrückmeldungen fließen in die Anpassung der Ziel-Plattform ein, besonders bei Bedienungsfragen
Die Change-Kommunikation startet Monate vor der eigentlichen Migration und begleitet sie weit über den Stichtag hinaus. Sie ist häufig der entscheidende Faktor für den Projekterfolg.
Betriebsmodelle nach der Migration
Nach Abschluss der Migration stellt sich die Frage, wie die Ziel-Plattform langfristig betrieben wird. Drei Modelle stehen zur Verfügung und lassen sich auch kombinieren.
Internes Team
Die eigene IT übernimmt Planung, Betrieb und Weiterentwicklung der Open-Source-Anwendungslandschaft. Voraussetzung ist ausreichende Kompetenz und Personal-Verfügbarkeit.
Vorteile:
Volle Kontrolle über Konfiguration, Änderungen und Update-Zyklen
Interne Kompetenz wächst mit der Plattform, keine Vendor-Abhängigkeit für Weiterentwicklung
Direkte Verbindung zwischen Fachbereich und Betrieb, schnelle Anpassungen möglich
Lokale Abstimmungswege für spezifische Anforderungen und neue Integrationen
Ideal für diese Szenarien:
- Organisationen mit vorhandener IT-Kompetenz in relevanten Technologien
- Ausreichendes Personal für Betrieb, Incident-Response, Updates und Weiterentwicklung
- Strategische Ausrichtung auf interne IT-Souveränität
Managed Service durch BEKOM
BEKOM übernimmt den operativen Betrieb der migrierten Plattform als Managed Service – mit Monitoring, Updates, Incident-Response und Nutzer-Support. Die strategische Kontrolle bleibt bei der Organisation.
Vorteile:
Professioneller Betrieb mit definiertem SLA-Rahmen von Beginn an
Keine Aufbauzeit für interne Kompetenz, direkter Zugriff auf erfahrene Spezialisten
Entlastung der internen Teams von Routineaufgaben und 24/7-Bereitschaft
Klare Verantwortungsabgrenzung für Audit und Compliance
Ideal für diese Szenarien:
- Kleine oder mittelgroße IT-Teams ohne Kapazität für eigenen Anwendungsbetrieb
- Geschäftskritische Anwendungen mit hohen Verfügbarkeitsanforderungen
- Regulierte Branchen mit strengen Anforderungen an dokumentierte Betriebsprozesse
Hybrides Betriebsmodell
Mischung aus internem und externem Betrieb. Das eigene Team übernimmt strategische Themen und Fachbereichs-Kommunikation, BEKOM übernimmt operative Routine oder spezifische Bereiche.
Vorteile:
Interne Kompetenz wächst gezielt, ohne das Team zu überlasten
Externe Unterstützung für 24/7-Bereitschaft, Kapazitätsspitzen oder Spezialthemen
Flexible Aufteilung, die über die Zeit anpassbar ist
Wissenssicherung durch strukturierte Zusammenarbeit
Ideal für diese Szenarien:
- Organisationen im Übergang: nach der Migration Aufbau interner Kompetenz mit externer Begleitung
- Klare Kompetenzschwerpunkte im internen Team mit Lücken in angrenzenden Bereichen
- Langfristige Partnerschaft mit definierter Verantwortungsaufteilung
TCO-Optimierung bei Migration und Exit-Strategien
Die Gesamtkostenbilanz einer SaaS-Migration wird oft unterschätzt.
Zentrale Kostentreiber im Eigenbetrieb sind die Parallelführung von Alt- und Neu-Systemen während der Übergangsphase, Datenkonvertierungsaufwände zwischen proprietären und Open-Source-Formaten sowie ungeplante Nacharbeiten bei unvollständigen Migrationen. Variable Aufwände entstehen durch Change-Management, Schulungen und Support-Peaks während der Rollout-Phasen. BEKOM strukturiert diese Komplexität durch ein systematisches Assessment der bestehenden SaaS-Landschaft und definiert eine Kostenstruktur mit planbaren Betriebskosten. Die Monatspauschale deckt dabei sowohl die technische Migration-Orchestrierung als auch den laufenden Betrieb der neuen Open-Source-Alternativen ab – ohne überraschende Lizenzsprünge oder Vendor-abhängige Kostensteigerungen.
Verwandte Themen: Migrations-Strategien verzahnen sich mit Identity & Access für SSO-Übernahme und Office-Suites für Dokumenten-Migration; die korrespondierende Microsoft-Managed-Schicht: Managed Microsoft; für strukturierte M365-Ablösungen siehe das Szenario Microsoft-365-Exit. Für Lead-Gen-Themen mit Telefonie-Bezug siehe Cloud-Telefonie.
Häufige Fragen zur Application-Migration
Wie lange dauert eine vollständige SaaS-Ablösung typischerweise?
Die Dauer hängt stark von Umfang und Komplexität ab. Kleine Organisationen mit wenigen hundert Nutzern können in wenigen Monaten migrieren; große Organisationen mit komplexen Strukturen und vielen Integrationen brauchen ein bis zwei Jahre für die vollständige Ablösung. Entscheidend ist die stufenweise Planung: jede Stufe reduziert Risiko, verlängert aber den Gesamtprozess. Die Dauer wird im Assessment gemeinsam geschätzt und im Roadmap-Dokument festgehalten, mit klaren Meilensteinen pro Stufe und strukturierter Risikobewertung.
Welche Daten müssen überhaupt migriert werden?
Nicht alle Daten müssen migriert werden – oft ist die bewusste Nicht-Migration die bessere Entscheidung. Aktuelle produktive Daten werden migriert; historische Archive können in Archivsysteme ausgelagert werden; veraltete Inhalte werden nach Aufbewahrungsfristen gelöscht. Die Datenklassifizierung erfolgt vor der Migration und reduziert Aufwand und Kosten erheblich. Eine Migration, die alle Daten der letzten zwanzig Jahre mitnimmt, ist meist teurer und unübersichtlicher als eine bewusst fokussierte Migration auf produktiv genutzte Inhalte.
Wie gehe ich mit Nutzer-Widerstand um?
Widerstand ist bei Anwendungs-Migrationen normal. Er entsteht nicht aus technischer Ablehnung, sondern aus Gewohnheit, Sorge um Kompetenzverlust und Unsicherheit über neue Workflows. Der Umgang: frühzeitige Information, Einbeziehung von Schlüsselpersonen, Schulungen vor der Migration, klare Kommunikation der Gründe. Change-Management ist kein Zusatz, sondern integraler Bestandteil des Projekts. Ohne strukturierte Nutzer-Begleitung scheitern auch technisch einwandfreie Migrationen an organisatorischen Realitäten.
Wie stelle ich Datenportabilität dauerhaft sicher?
Datenportabilität ist kein einmaliges Ereignis, sondern laufende Aufgabe. Kern-Prinzipien: Speicherung in offenen Formaten ohne proprietäre Wrapper, regelmäßige Exports zur Validierung der Portabilität, dokumentierte Export-Prozesse pro Anwendung, vertragliche Zusagen des Anbieters bei Cloud-Angeboten. Nach der Migration wird die Portabilität in regelmäßigen Abständen geprüft: Kann ich die Daten heute noch exportieren, wenn ich wollte? Diese Prüfung ist Teil der Architektur-Governance und wird in den Betriebshandbüchern dokumentiert.
Was passiert mit bestehenden Integrationen und Workflows?
Integrationen und Workflows sind oft der aufwändigste Teil der Migration. Sie werden systematisch erfasst: welche Systeme sind an die Ursprungsplattform angebunden, welche Workflows laufen darüber, welche Abhängigkeiten bestehen. Für die neue Plattform werden entsprechende Integrationen aufgebaut, oft mit modernisierter Architektur. Einige Workflows werden in der Migration vereinfacht, andere bleiben unverändert, wieder andere werden bewusst neu gestaltet. Die Integrations-Migration erfordert häufig dedizierte Teilprojekte.
Wie gehe ich mit spezialisierten Artefakten (Makros, Automatisierungen) um?
Spezialisierte Artefakte der Ursprungsplattform – Office-Makros, Workflow-Automatisierungen, plattformspezifische Scripte – stellen besondere Herausforderungen. Die Strategien sind immer ähnlich: Ersatz durch produktunabhängige Werkzeuge (Python-Skripte, dedizierte Workflow-Plattformen), Neuimplementierung auf der Zielplattform, oder paralleler Betrieb einer Alt-System-Insel für besonders komplexe Spezialfälle. Die Analyse dieser Artefakte erfolgt früh im Projekt, damit Lösungen rechtzeitig bereitstehen und nicht erst am Stichtag Überraschungen entstehen. Produkt-spezifische Details (z. B. VBA-Makros in Microsoft Office oder Apps Script in Google Workspace) werden in den jeweiligen Szenario-Seiten vertieft.
Bleibt nach der Migration ein Rückweg offen?
Ja, bei bewusster Planung bleibt ein Rückweg über mindestens eine definierte Zeit. Voraussetzungen: Ursprungsplattform wird nicht sofort nach der Migration gekündigt, alle Daten liegen in offenen Formaten vor, dokumentierte Rück-Migrationspfade sind vorbereitet. Nach einer stabilen Betriebsphase (typischerweise mehrere Monate) wird entschieden, ob der Rückweg endgültig geschlossen wird – durch Kündigung der Ursprungslizenzen und Abbau der Parallelstrukturen. Der Zeitpunkt wird bewusst gewählt, nicht aus Kostendruck überstürzt.
Wie unterscheidet sich BEKOM OPEN PRO Migration von BEKOM MANAGED?
BEKOM OPEN PRO Migration adressiert die strategische und operative Migrationsplanung: Welches Zielbild, welcher Migrationspfad, welche Reihenfolge? BEKOM MANAGED Applications (Silo 11) übernimmt den laufenden Betrieb der migrierten Plattform – mit Monitoring, Updates, Incident-Response und Nutzer-Support. Die Angebote ergänzen sich: Viele Kunden nutzen OPEN PRO für die Migrationsphase und übergeben den anschließenden Betrieb an MANAGED, mit klarem SLA-Rahmen. Der Übergang zwischen Projekt und Betrieb wird strukturiert dokumentiert und erfolgt mit definierter Abnahme.
Nächster Schritt: Migrations-Evaluierung
Der Einstieg beginnt mit einem strukturierten Strategiegespräch: Bestandsaufnahme der aktuellen Anwendungslandschaft, Bewertung der Migrationsoptionen und Erstellung einer belastbaren Migrations-Roadmap.
Strategiegespräch anfragen
Kontaktieren Sie BEKOM für ein unverbindliches Application-Strategiegespräch mit Migrations-Fokus. Gemeinsam mit Ihrem Team bewertet BEKOM die aktuelle Anwendungslandschaft und identifiziert realistische Migrationspfade – technologie-neutral und abgestimmt auf Organisationsgröße, Branche und interne Kompetenzen.
Assessment und Zielbild durchführen
Auf Basis des Strategiegesprächs erstellt BEKOM ein strukturiertes Assessment: Inventarisierung, Datenklassifizierung, Integrations-Abbild und Zielbild. Das Ergebnis ist eine dokumentierte Migrations-Roadmap mit Stufenplanung und klaren Meilensteinen, die als Grundlage für die spätere Umsetzungsplanung dient.
Pilotphase und Migration begleiten
Vor der breiten Migration starten Pilotphasen mit ausgewählten Teams und Daten-Sets. Die Pilotphase validiert die geplante Architektur unter realen Bedingungen und liefert die Erfahrungsbasis für den späteren Roll-out – mit strukturiertem Parallelbetrieb, klaren Cutover-Punkten und begleitender Nutzer-Schulung.