Migration von Microsoft 365 zu openDesk – Schritt-für-Schritt-Anleitung

0) Vorbemerkung: Was Sie wirklich migrieren

In M365 stecken häufig mehr als Dateien:

• Teams/Channels (Strukturen, Berechtigungen, Namenskonventionen)
• SharePoint-Sites (Dokumentenbibliotheken, Metadaten, Workflows)
• OneDrive (persönliche Ablagen, Schatten-IT)
• Exchange/Outlook (Kalender/Verteiler) je nach Scope

Definieren Sie: Was ist Zielsystem (openDesk-Bausteine), was bleibt, was wird ersetzt?

1) Bestandsaufnahme (die meisten überspringen das – und zahlen später)

Ziele der Analyse

• Datenvolumen und -typen (Dateien, Versionsstände, Sonderformate)
• Berechtigungen (Gruppen, externe Freigaben, Gastzugriff)
• Informationsarchitektur (Sites/Teams, Namensschema, Metadaten)
• Kritische Use Cases (Gremien, Projektarbeit, Aktennähe, vertrauliche Bereiche)

Ergebnisartefakte

• Migrationsinventar (was, wie viel, wie kritisch)
• Zielbild für Strukturen (Teams/Spaces/Ordner/Metadaten)
• Risiko- und Abhängigkeitenliste

2) Zielarchitektur und Governance festlegen

Ohne Regeln entsteht Chaos – nur im neuen System.

Minimum-Set an Standards

• Namenskonventionen für Teams/Arbeitsräume
• Rollenmodell (Owner, Editor, Leser, Extern)
• Freigaben/Links: wann erlaubt, wann verboten
• Metadaten/Tags für Auffindbarkeit
• Lebenszyklus: Aufbewahrung, Archiv, Löschung

3) Pilot (klein starten, aber richtig)

Wählen Sie 1-2 Bereiche, die repräsentativ sind:

• 1 Bereich mit vielen Dateien und berechtigungssensiblen Inhalten
• 1 Bereich mit hoher Kollaboration (Projektteam)

Pilotziele

• Migrationspfad technisch validieren
• Standards testen (finden Menschen Dinge wieder?)
• Schulungsbedarf und Supporttypologien erkennen

4) Migrationsstrategie: Wellen statt Big Bang

Bewährte Optionen

• Wave-Migration pro Abteilung/Standort
• Wave-Migration pro Use Case (z.B. zuerst Projektteams, dann Linienorganisation)
• Hybrid: erst "Read-only" Altbestand, dann Aktivmigration

Entscheidend ist die Kommunikationslogik: Wer arbeitet wann in welchem System?

5) Datenbereinigung vor der Migration

Bereinigen spart Kosten und senkt Risiko.

• Doppelte/obsolete Daten entfernen
• Berechtigungen entwirren (Gruppen konsolidieren)
• Metadaten vereinheitlichen
• Externe Freigaben dokumentieren und neu entscheiden

6) Schulung und Change (parallel zur Technik)

Ein Minimum, das funktioniert

• Kurzschulungen für alle (Grundfunktionen, Regeln)
• Rollenbasierte Trainings (Owner/Admin, Redakteure, Power User)
• Multiplikatoren + Sprechstunden in den ersten 2-4 Wochen

Kommunikation, die Adoption erzeugt

• 3 Kernbotschaften (Warum, Was ändert sich, Was bleibt)
• 1 Seite "So arbeiten wir künftig" (Regeln, Beispiele)
• Kurze How-to-Videos/Onepager

7) Cutover und Stabilisierung

Planen Sie die ersten Wochen als Produktivphase mit erhöhter Betreuung:

• Erweitertes Supportfenster
• Triage für Tickets (Bug vs. Regelverstoß vs. Schulungsbedarf)
• Adoption-KPIs: aktive Nutzer, Sucherfolg, Tickettypen, Freigabequoten

Risiken & Gegenmaßnahmen

• Risiko: "Wir migrieren alles" -> Gegenmaßnahme: Scope diszipliniert halten, Altbestand als Archiv.
• Risiko: Berechtigungen passen nicht -> Gegenmaßnahme: Rollenmodell + Stichproben-Audit.
• Risiko: Akzeptanz kippt -> Gegenmaßnahme: früher Pilot, Multiplikatoren, klare Regeln.
• Risiko: Betrieb nicht geklärt -> Gegenmaßnahme: Runbooks, Verantwortlichkeiten, Release-Prozess.

Beispiel-Zeitplan (grobe Orientierung)

• Woche 1-3: Bestandsaufnahme + Zielbild
• Woche 4-6: Pilot (inkl. Schulung)
• Woche 7-14: Migration in Wellen + Stabilisierung

Nächster Schritt

Wenn Sie Migration ohne Bauchgefühl planen wollen: Ein Assessment liefert Inventar, Zielbild, Risiken und einen realistischen Wellenplan.