Was Vendor Lock-in wirklich kostet
Vendor Lock-in bezeichnet den Zustand, in dem der Wechsel eines Anbieters technisch, vertraglich oder wirtschaftlich so aufwendig wird, dass er faktisch nicht mehr stattfindet. Die Kosten entstehen selten sofort – sie zeigen sich bei Preiserhöhungen, Lizenzänderungen, neuen Compliance-Anforderungen oder wenn ein Dienst abgekündigt wird.
Bei Microsoft 365 entsteht Bindung typischerweise über mehrere Ebenen gleichzeitig: proprietäre Postfach- und Dateiformate, tief integrierte Identitätsdienste, Automatisierungen in Power Platform sowie Lizenzbündel, deren Bestandteile einzeln kaum ersetzbar erscheinen. Je länger diese Ebenen wachsen, desto höher werden die Wechselkosten.
Sechs Ebenen der Abhängigkeit
Datenformate
Proprietäre oder nur teilweise dokumentierte Formate erschweren einen vollständigen, verlustfreien Export von Postfächern, Notizen und Dokumenten.
Schnittstellen
Fehlen offene Standards wie IMAP, CalDAV oder WebDAV, lassen sich Drittsysteme und Clients nicht ohne Anpassung weiterverwenden.
Identitäten
Verzeichnisdienste, Single Sign-on und Gerätemanagement werden zum Anker: Sie binden nicht nur Nutzerkonten, sondern auch angeschlossene Fachanwendungen.
Prozesse und Automatisierung
Workflows, Makros und Low-Code-Anwendungen sind an eine Plattform gebunden und müssen bei einem Wechsel neu gedacht werden.
Vertrag und Recht
Laufzeiten, Bundle-Rabatte und ein Rechtsträger außerhalb der EU erhöhen die Wechselhürde und den Aufwand für DSGVO-Nachweise.
Wirtschaftlicher Effekt
Fehlende Alternativen schwächen die Verhandlungsposition. Preisanpassungen lassen sich dann kaum noch abfedern.
Merksatz: Lock-in ist kein Zustand, sondern ein Prozess. Wer Exportfähigkeit, offene Standards und klare Ausstiegspfade von Anfang an einfordert, hält die Wechselkosten dauerhaft niedrig.
Ausgangslage analysieren
Vor jeder Migration steht eine belastbare Bestandsaufnahme. Sie beantwortet drei Fragen: Welche Daten existieren, welche Dienste werden tatsächlich genutzt und welche Prozesse hängen daran?
Ergebnis der Phase: eine priorisierte Liste aller Datenquellen mit Volumen, Verantwortlichen, Abhängigkeiten und einer Einschätzung, was migriert, archiviert oder bewusst nicht übernommen wird.
Migrationsstrategien im Vergleich
Es gibt keine universell richtige Strategie. Die Wahl hängt von Organisationsgröße, Ausfalltoleranz, Datenvolumen und der Zahl angebundener Fachverfahren ab.
| Strategie | Vorgehen | Geeignet für | Zu beachten |
|---|---|---|---|
| Big Bang | Umstellung aller Nutzer zu einem festen Stichtag, meist an einem Wochenende. | Kleine bis mittlere Organisationen mit überschaubarem Datenvolumen. | Hoher Vorbereitungsaufwand, wenig Spielraum für Korrekturen, intensive Hotline-Phase. |
| Wellenmigration | Umstellung in Gruppen nach Abteilung, Standort oder Nutzerprofil. | Mittlere und große Organisationen mit heterogenen Anforderungen. | Erfordert Koexistenz von Adressbuch und Kalenderfreigaben über den Migrationszeitraum. |
| Koexistenz | Beide Systeme laufen parallel; Dienste werden nacheinander abgelöst. | Komplexe Umgebungen mit vielen Fachverfahren und langen Vertragslaufzeiten. | Längste Laufzeit, doppelte Lizenzkosten in der Übergangsphase, klare Zuständigkeiten nötig. |
| Dienstweise Ablösung | Zuerst E-Mail und Kalender, danach Dateien, Dokumente und Kommunikation. | Organisationen, die Risiko und Aufwand über Quartale verteilen wollen. | Nutzer arbeiten zeitweise in zwei Oberflächen – Kommunikation und Schulung sind entscheidend. |
Praxisempfehlung: In den meisten Projekten hat sich die Wellenmigration bewährt. Eine Pilotgruppe aus 10 bis 20 technikaffinen Personen deckt Sonderfälle auf, bevor die Breite umgestellt wird.
Der Migrationsfahrplan in acht Schritten
Ein bewährtes Vorgehen von der Analyse bis zur Abschaltung der Altumgebung.
Ziele und Rahmen festlegen
Souveränitäts-, Kosten- und Compliance-Ziele definieren, Projektorganisation aufsetzen, Budget und Zeitfenster abstimmen.
Bestandsaufnahme durchführen
Daten, Dienste, Identitäten und Integrationen erfassen und bewerten.
Zielarchitektur entwerfen
Mandanten- und Domänenstruktur, Postfachtypen, Ablagestruktur, Rollen- und Rechtekonzept sowie Schnittstellen festlegen.
Pilotmigration
Kleine, repräsentative Nutzergruppe migrieren, Laufzeiten messen, Sonderfälle dokumentieren und das Vorgehen nachschärfen.
Kommunikation und Schulung
Frühzeitig informieren, Kurzanleitungen bereitstellen, Ansprechpartner benennen und den Umstellungstermin mehrfach ankündigen.
Datenmigration in Wellen
Vorabsynchronisation großer Bestände, Delta-Abgleich kurz vor Umstellung, DNS- und MX-Umstellung mit reduzierter TTL.
Nachlauf und Qualitätssicherung
Vollständigkeit stichprobenartig prüfen, Signaturen, Weiterleitungen, Freigaben und Kalenderserien kontrollieren, Support verstärken.
Altumgebung abschalten
Archiv- und Aufbewahrungspflichten klären, Restdaten exportieren, Lizenzen kündigen und den Rückbau dokumentieren.
Daten und Dienste im Detail
Jede Datenart bringt eigene Fallstricke mit. Die folgende Übersicht fasst zusammen, worauf bei den wichtigsten Beständen zu achten ist.
Risiken vermeiden
Die meisten Migrationsprobleme sind nicht technischer, sondern planerischer Natur. Diese sechs Fehler treten am häufigsten auf.
Zu spät kommuniziert
Nutzer erfahren erst kurz vor dem Stichtag von der Umstellung. Folge: Widerstand und vermeidbare Supportlast. Mindestens vier Wochen Vorlauf einplanen.
Alles migrieren wollen
Jahrzehntealte Ablagen unbesehen zu übernehmen verlängert das Projekt. Besser: bereinigen, archivieren und nur Relevantes übertragen.
Sonderfälle übersehen
Funktionspostfächer, Scanner, Ticketsysteme und Serienbriefe greifen oft unbemerkt auf E-Mail zu und fallen sonst am Stichtag aus.
DNS ohne Vorbereitung
Zu hohe TTL-Werte verzögern die MX-Umstellung. TTL rechtzeitig senken und SPF, DKIM sowie DMARC vorab korrekt setzen.
Kein Rollback-Plan
Für jede Welle sollte definiert sein, wie im Fehlerfall zurückgeschaltet wird und wer diese Entscheidung trifft.
Support unterschätzt
In den ersten Tagen nach der Umstellung entstehen die meisten Rückfragen. Erhöhte Support-Kapazität und Kurzanleitungen bereithalten.
Qualitätskriterium: Eine Migration gilt erst dann als erfolgreich, wenn Stichproben aus jeder Nutzergruppe Vollständigkeit von Postfach, Kalender und Ablage bestätigen – nicht schon, wenn der Transfer technisch durchgelaufen ist.
Migration zu xworks.365
xworks.365 ist eine vollständig integrierte Collaboration-Plattform der mediaBEAM GmbH: E-Mail, Kalender und Aufgaben, Cloud-Speicher und Dokumentenmanagement, Office-Bearbeitung im Browser, Chat und Videokonferenzen – betrieben in einem eigenen, ISO/IEC 27001-zertifizierten Rechenzentrum in Deutschland.
Offene Standards von Anfang an
IMAP, SMTP, CalDAV, CardDAV, WebDAV und dokumentierte APIs. Bestehende Clients und Drittsysteme lassen sich weiterverwenden.
Migration über Standardprotokolle
Postfächer, Kalender und Kontakte werden über offene Protokolle übernommen – ohne proprietäre Zwischenformate.
Jederzeit exportierbar
Daten und Dokumente lassen sich vollständig in offenen Formaten exportieren. Der Ausstieg bleibt dauerhaft möglich.
Ein Anbieter, ein Rechtsrahmen
Vertragspartner ist ein deutsches Unternehmen ohne US-Muttergesellschaft – kein Transfer-Impact-Assessment, keine Standardvertragsklauseln.
Begleitung im Projekt
Bestandsaufnahme, Zielarchitektur, Pilot und Wellenplanung werden gemeinsam mit dem Fachteam der mediaBEAM GmbH abgestimmt.
Bewährt im Großbetrieb
Mandantenfähig und White-Label-fähig, im Einsatz bei Kommunen, Schulträgern, Systemhäusern und Telkos mit Millionen Nutzerkonten.
Leitfaden als PDF
Alle Kapitel dieses Leitfadens – inklusive Checkliste – als kompaktes Whitepaper zum Herunterladen.