Migrationsleitfaden – Umstieg auf openDesk Edu | Docs

Einleitung

Die IT-Landschaft deutscher Hochschulen ist über Jahrzehnte gewachsen. Auf dem Weg von zentralen Rechenzentren hin zu dezentralen Diensten haben sich heterogene Infrastrukturen etabliert: proprietäre Groupware-Lösungen neben Open-Source-Plattformen, verschiedene Lernmanagementsysteme, unterschiedliche Authentifizierungsquellen und eine Vielzahl an Speicherbackends. Der Betriebsaufwand für diese Heterogenität steigt kontinuierlich, während der Druck wächst, digitale Souveränität zu gewährleisten, Vendor-Lock-in zu vermeiden und den Nutzenden eine moderne, integrierte Arbeitsumgebung zu bieten.

openDesk Edu adressiert diese Herausforderungen als vollständig integrierte, Kubernetes-basierte Kollaborationsplattform, die speziell für den Hochschulkontext entwickelt wurde. Sie vereint E-Mail und Kalender (Grommunio, OX App Suite, SOGo), Datei-Sync-und-Share (Nextcloud, OpenCloud), Lernmanagement (ILIAS, Moodle), Videokonferenzen (BigBlueButton, Jitsi), kollaboratives Bearbeiten (Collabora, Etherpad, CryptPad, Excalidraw), Projektmanagement (OpenProject, Planka), Ticketsystem (Zammad), Wiki und Wissensdatenbank (XWiki, BookStack) und viele weitere Dienste – alles hinter einer einheitlichen Identity- und Access-Management-Ebene auf Basis von Keycloak mit SAML-Föderation zu DFN-AAI und eduGAIN.

Dieser Leitfaden beschreibt vier typische Migrationsszenarien:

Szenario	Beschreibung
Neueinführung (Greenfield)	Keine Vorgängersysteme; openDesk Edu wird erstmalig eingeführt
Komplettumstieg (Rip-and-Replace)	Abschalten der Altsysteme und Datenmigration in einem geplanten Umstellungsfenster
Schrittweise Migration	Dienstweiser Umstieg mit parallelem Betrieb von Alt- und Neusystem
Hybride Föderation	Beibehaltung des bestehenden IdP; openDesk Edu wird per SAML dahintergeschaltet

Der Leitfaden richtet sich an IT-Administratorinnen und System Engineers an Hochschulen. Grundkenntnisse in DNS, LDAP, IMAP, SAML und grundlegende Kubernetes-Erfahrung werden vorausgesetzt.

Bestandsaufnahme vor der Migration

Eine gründliche Bestandsaufnahme der aktuellen Infrastruktur ist der wichtigste Erfolgsfaktor für eine Migration. Fehler in dieser Phase führen zu Folgeproblemen, die exponentiell aufwändiger zu beheben sind.

Diensteverzeichnis

Erfassen Sie jeden Dienst, der aktuell im Einsatz ist. Für jeden Dienst dokumentieren Sie:

Hersteller und Version – bestimmt die Kompatibilität von Migrationswerkzeugen
Nutzerbasis – Anzahl aktiver Nutzende, Gruppen, Verteilerlisten
Datenvolumen – Postfachgrößen, Dateispeicherbelegung, LMS-Kursdaten
Authentifizierungsmethode – LDAP-Bind, SAML-SP, OIDC, lokale Accounts
Integrationspunkte – APIs, Webhooks, LTI-Links, SSO-Sitzungen
Ablösungsstatus – Wird die Version vom Hersteller noch unterstützt?

Erstellen Sie eine Tabelle ähnlich der folgenden:

Dienst	Nutzende	Datenvolumen	Authentifizierung	Integration	Migrierbar?
Microsoft Exchange	15.000	4,2 TB	AD/LDAP	EWS, ActiveSync	Ja (IMAP/EWS)
ILIAS 7	12.000	850 GB	Shibboleth SP	LTI 1.3	Ja (SCORM/Backup)
ownCloud 10	8.000	6,1 TB	LDAP	WebDAV	Ja
Jitsi (eigener Server)	5.000	—	keine (offen)	—	Nur Konfiguration

Nutzerzahlen und Datenvolumen schätzen

Ermitteln Sie exakte Zahlen statt Schätzungen, soweit möglich. Führen Sie SQL-Abfragen gegen das IdP-Verzeichnis, die Mailserver-Datenbanken und die Speicher-Backends durch. Bei E-Mail sollten Sie sowohl die Anzahl der Postfächer als auch das Gesamtvolumen erfassen – eine Hochschule mit 20.000 Postfächern à 200 MB hat andere Anforderungen als eine mit 5.000 Postfächern à 4 GB.

Nutzen Sie diese Zahlen zur Dimensionierung des openDesk Edu Kubernetes-Clusters. Als Faustregel gilt:

Control-Plane-Knoten: 3 (für Hochverfügbarkeit)
Worker-Knoten: Start mit 5–7, je nach Last skalieren
Speicher: Das 1,5-Fache des aktuellen Datenvolumens einplanen (Wachstum und Migrationspuffer)
Arbeitsspeicher: Mindestens 8–16 GB pro Worker-Knoten für die Kollaborationsdienste

Identity-Provider-Prüfung

Identifizieren Sie jede Quelle von Nutzeridentitäten:

Active Directory / LDAP – am häufigsten, oft die autoritative Quelle
SAML-Föderation – DFN-AAI, eduGAIN oder nationale Forschungsnetze
OIDC-Provider – Azure AD, Google Workspace oder Eigenentwicklungen
Lokale Datenbanken – Legacy-Anwendungen mit eigenen Nutzertabellen

Bestimmen Sie, welches System die autoritative Quelle ist. Die IdP-Migrationsstrategie (Option A oder B im nächsten Abschnitt) hängt davon ab, ob Sie den vorhandenen Provider ersetzen oder lediglich anbinden können.

DSGVO-Aspekte bei der Bestandsaufnahme

Bereits in der Planungsphase müssen die Anforderungen der Datenschutz-Grundverordnung (DSGVO) berücksichtigt werden:

Datenminimierung: Welche Daten müssen tatsächlich migriert werden? Alte, nicht mehr benötigte Datensätze sollten vor der Migration bereinigt werden.
Löschkonzepte: Stellen Sie sicher, dass der neue Dienst die gleichen oder bessere Löschfristen unterstützt.
Auftragsverarbeitung: openDesk Edu kann on-premise betrieben werden – klären Sie, ob ein Auftragsverarbeitungsvertrag (AVV) mit dem Betreiber erforderlich ist.
Verzeichnisdienste: Personenbezogene Daten in LDAP-Verzeichnissen unterliegen der DSGVO – dokumentieren Sie die Datenfelder und ihre Löschfristen.

DNS- und TLS-Bestandsaufnahme

Führen Sie ein vollständiges DNS-Audit durch:

Listen Sie jede DNS-Zone und jeden Subdomain auf, der mit Hochschuldiensten verbunden ist
Dokumentieren Sie aktuelle TTL-Werte (müssen vor der Umstellung abgesenkt werden)
Identifizieren Sie alle TLS-Zertifikate, ihre Aussteller und Verfallsdaten
Notieren Sie DNSSEC-Konfigurationen, die die Umstellungszeit beeinflussen könnten

Typische Dienste mit eigenen DNS-Einträgen sind: mail, webmail, cloud, lms, meet, wiki, pad, project, ticket, auth, sso, api, autoconfig, mta-sts, _dmarc, _smtp._tls, _imap._tls.

Netzwerkanforderungen

Während der Migration laufen Alt- und Neuinfrastruktur parallel. Stellen Sie sicher, dass folgende Netzwerkpfade vorhanden sind:

IMAP/EWS-Synchronisation: openDesk Edu Worker → alter Mailserver (Ports 143, 993, 443)
LDAP-Synchronisation: Keycloak → altes LDAP/AD (Port 389, 636)
Datenbankreplikation: falls eine Read-Replica zur Verifizierung vorgehalten wird
Reverse Proxy: Externer Traffic muss während der schrittweisen Umstellung sowohl auf alte als auch auf neue Ingress-Controller routbar sein
DNS-Management: API-Zugriff auf den DNS-Provider für automatisierte Record-Updates

Identity-Provider-Migration

Keycloak ist die zentrale Identity- und Access-Management-Komponente von openDesk Edu. Es übernimmt Authentifizierung, Autorisierung, User Federation und die SAML/OIDC-Anbindung an übergeordnete Identitätsföderationen.

Es gibt zwei primäre Migrationsansätze:

Option A: Vorhandenen IdP durch Keycloak ersetzen

Bei diesem Ansatz wird Keycloak zum autoritativen Identity Provider. Benutzerkonten werden in Keycloak migriert und Keycloak übernimmt die SAML-Föderation zu DFN-AAI/eduGAIN.

Benutzer und Gruppen aus AD/LDAP exportieren

Wenn das vorhandene Verzeichnis Active Directory oder OpenLDAP ist, haben Sie zwei Optionen:

LDAP-Föderation (empfohlen): Konfigurieren Sie Keycloak so, dass es eine Verbindung zum vorhandenen LDAP-Verzeichnis als User-Federation-Provider herstellt. Dies vermeidet Bulk-Export/Import und behält das Verzeichnis als Benutzerquelle bei. Gruppenmitgliedschaften und Rollenzuweisungen werden live synchronisiert.
Bulk-Import: Exportieren Sie Benutzer und Gruppen mittels ldapsearch ins LDIF-Format und importieren Sie diese in den integrierten Keycloak-Benutzerspeicher. Dies ist sinnvoll, wenn das Altsystem vollständig abgelöst werden soll.

Beispielkonfiguration für die LDAP-Föderation in Keycloak:

# Keycloak LDAP-Föderation
provider: ldap
consoleDisplayConnectionUrl: ldaps://ldap.uni-example.de:636
usersDn: ou=people,dc=uni-example,dc=de
bindDn: cn=keycloak,ou=service,dc=uni-example,dc=de
bindCredential: <geheim>
customUserSearchFilter: (objectClass=inetOrgPerson)
searchScope: one
priority: 0
editMode: READ_ONLY
syncRegistrations: false
vendor: active_directory
useKerberosForPasswordAuthentication: false

In Keycloak importieren

Wenn Sie sich für den Bulk-Import entscheiden, ist der allgemeine Ablauf:

Export der Benutzer aus dem Altsystem als LDIF
Import über die Keycloak-Admin-Konsole oder das kcadm.sh-Script
Temporäre Passwörter setzen oder Passwortänderung beim ersten Login erzwingen
Gruppenmitgliedschaften und Rollenzuweisungen migrieren

# Beispiel: Bulk-Import mit kcadm.sh
kcadm.sh create users -r hochschule \
  -s username=musterfrau \
  -s email=musterfrau@uni-example.de \
  -s firstName=Erika \
  -s lastName=Musterfrau \
  -s enabled=true \
  -s attributes='{"eduPersonPrincipalName":["musterfrau@uni-example.de"]}'

SAML-Föderation mit DFN-AAI/eduGAIN konfigurieren

Keycloak fungiert als SAML-Identity-Provider für interne Dienste und gleichzeitig als SAML-Service-Provider gegenüber den übergeordneten Föderationen.

<!-- Keycloak SAML-SP-Metadaten für DFN-AAI -->
<md:EntityDescriptor entityID="https://auth.uni-example.de/auth/realms/hochschule/broker/dfn-aai/endpoint">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:AssertionConsumerService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://auth.uni-example.de/auth/realms/hochschule/broker/dfn-aai/endpoint"
      index="1"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Registrieren Sie diese Metadaten beim DFN-AAI-Operatoren (DFN). Nach Genehmigung können sich Angehörige anderer föderierter Einrichtungen mit ihren Heimatorganisations-Zugangsdaten an openDesk Edu anmelden.

Passwortrichtlinien und MFA

Konfigurieren Sie Passwortrichtlinien in Keycloak, die den bestehenden Anforderungen mindestens entsprechen:

Mindestlänge, Komplexität, Historie
Passwortablauf (erwägen Sie semesterbasierte Zyklen statt starre 90-Tage-Fristen)
Multi-Faktor-Authentifizierung: WebAuthn (FIDO2), TOTP, SMS oder Backup-Codes

Aktivieren Sie bedingte MFA – zum Beispiel MFA-Pflicht für Administrationsdienste, aber nicht für den grundlegenden Dateizugriff.

Option B: Keycloak hinter vorhandenem IdP föderieren

Wenn eine Ablösung des Hochschul-IdP nicht möglich ist (politische oder betriebliche Gründe), setzen Sie Keycloak als SAML-Service-Provider hinter dem vorhandenen IdP ein. In dieser Konfiguration:

Die Nutzenden authentifizieren sich gegen den vorhandenen Hochschul-IdP
Der IdP sendet eine SAML-Assertion an Keycloak
Keycloak mappt die Assertions-Attribute auf sein internes Benutzermodell
Keycloak stellt eigene Tokens für die openDesk-Edu-Dienste aus

Dieser Ansatz ist typisch für Hochschulen, die am DFN-AAI teilnehmen und ihre bestehende SAML-Infrastruktur beibehalten müssen.

Attribut-Mapping

Konfigurieren Sie das Attribut-Mapping zwischen den SAML-Assertions Ihres IdP und dem Keycloak-Benutzermodell:

SAML-Assertions-Attribut	Keycloak-Benutzerattribut
`urn:oid:0.9.2342.19200300.100.1.3` (mail)	`email`
`urn:oid:2.5.4.42` (givenName)	`firstName`
`urn:oid:2.5.4.4` (sn)	`lastName`
`urn:oid:1.3.6.1.4.1.5923.1.1.1.6` (eduPersonPrincipalName)	`username`, `epPN`
`urn:oid:1.3.6.1.4.1.5923.1.1.1.1` (eduPersonAffiliation)	`groups`

Testen der Authentifizierung vor der Umstellung

Testen Sie die Authentifizierung vor der Umstellung isoliert:

Stellen Sie eine Keycloak-Instanz bereit (oder nutzen Sie die in openDesk Edu enthaltene)
Konfigurieren Sie die Föderation zu Ihrem Test-IdP oder LDAP-Verzeichnis
Erstellen Sie einen Testdienst (z. B. eine Test-Nextcloud-Instanz), der Keycloak OIDC nutzt
Lassen Sie eine kleine Gruppe von IT-Mitarbeitenden Login, Logout, Session-Refresh und MFA testen
Überwachen Sie die Keycloak-Logs auf Assertions-Fehler, Attribut-Konflikte oder Timeouts

# Authentifizierung durch direkten Token-Request testen
curl -s -X POST https://auth.uni-example.de/auth/realms/hochschule/protocol/openid-connect/token \
  -d "client_id=test-client" \
  -d "username=musterfrau" \
  -d "password=test-passwort" \
  -d "grant_type=password" | jq .

Fahren Sie mit der vollständigen Umstellung erst fort, wenn die Test-Authentifizierung für alle Nutzertypen (Mitarbeitende, Lehrende, Studierende, externe Angehörige) erfolgreich war.

E-Mail-Migration

Die E-Mail-Migration ist in der Regel der kritischste und risikoreichste Teil des Umstiegs. Hochschulen betreiben ihre E-Mail-Infrastruktur über Jahrzehnte, und Postfächer enthalten historische Daten, komplexe Ordnerstrukturen, Delegationsregeln und gemeinsame Postfächer.

IMAP-Sync-Strategie mit imapsync

imapsync ist der De-facto-Standard für die Migration von Postfächern zwischen IMAP-Servern. Es erhält Ordnerstrukturen, Flags und Daten bei der Übertragung.

Vorbereitung

Installieren Sie imapsync auf einer Maschine mit ausreichender Bandbreite zu Quell- und Zielserver:

apt install imapsync
# oder aus dem Quellcode
git clone https://github.com/imapsync/imapsync.git

Gestaffelte Migration

Teilen Sie die Postfächer in Batches ein, um die Last zu steuern und Probleme frühzeitig zu erkennen:

Batch	Nutzende	Postfächer	Gesamtgröße	Geschätzte Zeit
1	IT-Mitarbeitende, Pilotgruppe	50	25 GB	2 Stunden
2	Lehrende (Early Adopters)	500	600 GB	24 Stunden
3	Verwaltungspersonal	3.000	2,1 TB	3–4 Tage
4	Studierende	12.000	1,5 TB	5–7 Tage
5	Alumni, gemeinsame Postfächer	2.000	800 GB	2–3 Tage

imapsync ausführen

imapsync \
  --host1 imap.alt.uni-example.de --user1 musterfrau --password1 geheim \
  --host2 imap.openedesk.uni-example.de --user2 musterfrau --password2 geheim \
  --ssl1 --ssl2 \
  --exclude "Trash|Junk|Spam|Gelöscht" \
  --maxsize 52428800 \
  --addheader \
  --logfile imapsync-musterfrau.log

Wichtige Flags:

--exclude: Papierkorb und Spam-Ordner überspringen, um Zeit zu sparen
--maxsize: Nachrichten über einer Größenbeschränkung (50 MB) überspringen
--addheader: Fügt migrierten Nachrichten einen Header für die Nachverfolgung hinzu
--logfile: Unverzichtbar für die Fehlersuche bei fehlgeschlagenen Übertragungen

Ratenbegrenzung

Setzen Sie --maxconnections, um den Quellserver nicht zu überlasten. Starten Sie mit 1 Verbindung pro Postfach und 2 gleichzeitigen Postfächern. Überwachen Sie CPU und Festplatten-I/O des Quellservers:

# Auf 5 parallele Übertragungen begrenzen
ls mailboxes.txt | xargs -P5 -I{} imapsync --host1 ... --host2 ... {}

Große Postfächer (>10 GB) handhaben

Postfächer über 10 GB profitieren von einer speziellen Behandlung:

Vorsynchronisation älterer Daten, dann eine inkrementelle Synchronisation für aktuelle Änderungen
--split1 verwenden, um große Ordner in Bereiche von Nachrichten aufzuteilen
Timeout-Werte erhöhen mit --timeout1 und --timeout2
Anhänge über 25 MB auslagern und außerhalb der Bandbreite übertragen

# Zweistufige Synchronisation für große Postfächer
# Stufe 1: Alles älter als 30 Tage synchronisieren
imapsync ... --maxage 30
# Stufe 2: Aktuelle Nachrichten synchronisieren (schnellerer Inkrementaldurchlauf)
imapsync ... --minage 1

Kalender- und Kontaktmigration

Quelle	Ziel	Protokoll/Werkzeug	Hinweise
Exchange	Grommunio/OX	EWS → ActiveSync	Microsoft stellt Exchange-Migration-Tools bereit
SOGo	SOGo (neu)	CalDAV/CardDAV	Direkte CalDAV-Synchronisation
Google Workspace	Grommunio/OX	Google Takeout → Import	Manuell pro Nutzer oder automatisiert per API
iCal/CSV	Nextcloud/OX	CalDAV	Bulk-Import per Script

Für CalDAV-Migration verwenden Sie Werkzeuge wie caldavsync oder vdirsyncer:

# Ein einzelnes Kalender-Sync
vdirsyncer sync calendar-musterfrau

# Batch-Sync für alle Nutzenden
for user in $(cat users.txt); do
  vdirsyncer sync calendar-$user
done

Mailfluss-Umstellung

Die MX-Record-Änderung ist der Point of no Return für die E-Mail-Migration. Führen Sie sie sorgfältig durch.

TTL vor der Umstellung absenken

48 Stunden vor der geplanten Umstellung senken Sie die TTL Ihrer MX- und zugehörigen DNS-Records vom Standardwert (oft 86400 Sekunden / 24 Stunden) auf 300 Sekunden (5 Minuten) ab:

; Ursprünglich
uni-example.de.   86400  IN  MX  10 mail.alt.uni-example.de.

; Reduzierte TTL (48h vor Umstellung)
uni-example.de.   300    IN  MX  10 mail.alt.uni-example.de.

Paralleler Mailfluss

Konfigurieren Sie den alten Mailserver so, dass er E-Mails für migrierte Nutzende an den neuen openDesk-Edu-Mailserver weiterleitet. Dies ermöglicht eine inkrementelle Migration ohne Aufteilung der Domain:

# Auf dem Altserver: Transport-Map für migrierte Nutzende
user@uni-example.de smtp:[mail.openedesk.uni-example.de]:25

MX-Umstellung

Wenn alle Postfächer synchronisiert und verifiziert sind:

; Umstellung
uni-example.de.   300    IN  MX  10 mail.openedesk.uni-example.de.
uni-example.de.   300    IN  MX  20 mail.alt.uni-example.de.  ; Backup

Behalten Sie den alten Mailserver als sekundären MX (höhere Prioritätszahl = niedrigere Priorität), damit er E-Mails annimmt, falls der neue Server nicht erreichbar ist. Wichtig: Der alte MX-Server sollte mindestens zwei Wochen lang weiterhin E-Mails annehmen können – auch wenn keine Authentifizierung mehr stattfindet.

Postfachverifizierung nach der Migration

Für jedes migrierte Postfach prüfen:

Login-Test: Kann sich der Benutzer per IMAP und Webmail anmelden?
Ordneranzahl: Stimmt die Ordnerhierarchie mit der Quelle überein?
Nachrichtenanzahl: Gesamtnachrichtenzahl vergleichen (mit SELECT INBOX IMAP-Befehl)
Senden/Empfangen: Kann der Benutzer neue Nachrichten senden und empfangen?
Kalender: Sind zukünftige Termine vorhanden?
Kontakte: Sind alle Adressbucheinträge intakt?

# Postfachgrößen per IMAP vergleichen
# Quelle
curl-imap ... imap.alt.uni-example.de
# Ziel
curl-imap ... imap.openedesk.uni-example.de

Dateispeicher-Migration

Der Dateispeicher in openDesk Edu wird von Nextcloud und/oder OpenCloud bereitgestellt. Beide unterstützen WebDAV als primäres Migrationsinterface.

WebDAV-Sync-Werkzeuge

Für mittlere Migrationen (bis 10 TB) sind WebDAV-basierte Werkzeuge ausreichend:

# Mit davfs2 beide Systeme mounten
mount -t davfs https://cloud.alt.uni-example.de/remote.php/dav/files/musterfrau /mnt/quelle
mount -t davfs https://cloud.openedesk.uni-example.de/remote.php/dav/files/musterfrau /mnt/ziel
rsync -av --progress /mnt/quelle/ /mnt/ziel/

Für große Migrationen verwenden Sie rclone, das mehrere Backends unterstützt und Wiederholungslogik bietet:

# rclone-Konfiguration für Nextcloud/WebDAV
rclone config
# Alle Dateien eines Benutzers synchronisieren
rclone sync nextcloud_alt:musterfrau nextcloud_openedesk:musterfrau \
  --progress \
  --transfers 4 \
  --checkers 8 \
  --retries 3

Große Datenmengen migrieren (>10 TB)

Bei Datensätzen über 10 TB umgehen Sie WebDAV und synchronisieren direkt mit dem Speicher-Backend:

Altspeicher mounten (NFS, SMB oder lokale Festplatte)
Daten in das openDesk-Edu-Speicher-Backend kopieren (z. B. Longhorn-Volume, NFS-Export oder S3-Bucket)
Dateisystem von der Anwendungsebene neu einlesen:

# Nextcloud-Dateiscan nach Backend-Kopie
sudo -u www-data php occ files:scan --all

Gemeinsame Ordner und Berechtigungen abbilden

Gemeinsame Ordner sind der komplexeste Teil der Dateispeicher-Migration. Dokumentieren Sie jede Freigabe vor der Migration:

# Alle Freigaben aus Nextcloud listen
sudo -u www-data php occ sharing:list \
  --output json > legacy_freigaben.json

Nach der Migration erstellen Sie die Freigaben über die openDesk-Edu-API oder occ-Befehle neu:

# Freigabe neu erstellen
sudo -u www-data php occ sharing:create \
  --share-type group \
  --share-with it-abteilung \
  --path "shared/it-dokumente" \
  --permissions read

Dateiversionen und Papierkorb behandeln

Standardmäßig werden Dateiversionen und Papierkorb-Inhalte bei der WebDAV-Kopie mitübertragen. Dies kann das Transfervolumen jedoch verdoppeln oder verdreifachen. Entscheiden Sie sich für eine der folgenden Optionen:

Alles migrieren (empfohlen): Inklusive Versionshistorie und gelöschter Dateien. Verwenden Sie rclone mit --include "*/versions/*" und --include "*/trash/*".
Neu beginnen: Nur aktuelle Dateien migrieren. Nutzende verlieren die Versionshistorie, die Migration ist aber schneller.
Hybrid: Aktuelle Dateien und Versionen der letzten 30 Tage migrieren.

Verifizierung

Überprüfen Sie nach der Migration die Integrität des Dateispeichers:

Prüfung	Methode
Dateianzahl	`find /storage -type f
Gesamtgröße	`du -sh /storage`
Berechtigungen (Stichprobe)	50 zufällige Ordner auswählen, Freigabeeinstellungen vergleichen
Dateiinhalt (Stichprobe)	`md5sum` von 100 zufälligen Dateien, mit Quelle vergleichen
Benutzer-Login-Test	Als 10 zufällige Benutzer einloggen, Dateiliste bestätigen

LMS-Migration (ILIAS, Moodle)

Lernmanagementsysteme enthalten Jahre von Kursinhalten, studentischen Abgaben, Notenbüchern und Aktivitätsdaten. Die Migration muss um den akademischen Kalender herum geplant werden.

Kursinhalte exportieren/importieren

ILIAS

# Einzelnen Kurs exportieren
# Über ILIAS-GUI: Administration > Export > SCORM
# Oder per CLI:
php setup/ilias.php export \
  --type course \
  --ref_id 12345 \
  --target /tmp/export

# In openDesk-Edu-ILIAS importieren
# Über GUI: Administration > Import

ILIAS unterstützt SCORM 1.2 und 2004 Export. Nicht alle ILIAS-Plugins exportieren sauber – testen Sie zuerst mit einem repräsentativen Kurs.

Moodle

# Moodle-Kurs-Backup per CLI
sudo -u www-data php admin/cli/backup.php \
  --courseid=123 \
  --destination=/tmp/moodle-backup \
  --pref-role --pref-user --pref-activity

# Wiederherstellen
sudo -u www-data php admin/cli/restore.php \
  --backupfile=/tmp/moodle-backup/backup-moodle2-course-123.mbz \
  --courseid=0 \
  --categoryid=1

Notenbücher erhalten

Notenbücher müssen getrennt vom Kursinhalt exportiert werden:

# ILIAS: Notenexport als CSV über GUI oder SOAP-API
# Moodle: Notenexport per CLI
sudo -u www-data php grade/export/grade_export.php \
  --course=123 \
  --format=csv \
  --output=/tmp/noten-kurs-123.csv

Importieren Sie die Notenbücher nach der Kursmigration über die Importfunktion der Plattform. Beachten Sie, dass sich Aufgaben- und Quiz-IDs ändern können, was die Verknüpfung von Noten zu Aktivitäten beeinträchtigen kann. Eine manuelle Zuordnung ist oft erforderlich.

LTI-Integration neu konfigurieren

Wenn Ihre Hochschule LTI 1.3 zur Verbindung von LMS-Plattformen mit externen Tools verwendet, muss jede Tool-Verknüpfung nach der Migration neu konfiguriert werden:

Dokumentieren Sie alle vorhandenen LTI-1.3-Plattform-Deployments und Tool-Registrierungen
Generieren Sie neue Plattformschlüssel in der neuen ILIAS-/Moodle-Instanz
Registrieren Sie die Tool-Deployments mit den neuen Plattform-IDs und öffentlichen Schlüsselsätzen neu
Testen Sie eine Stichprobe von LTI-Launches vor der vollständigen Umstellung

Plugin-Kompatibilitätsprüfung

Plugin	ILIAS	Moodle	Hinweise
H5P	Integriert	Integriert	Daten migrierbar
BigBlueButton	Plugin	Plugin	Endpunkt neu konfigurieren
Turnitin	—	Plugin	Mit neuer Instanz-URL reaktivieren
MathJax	Plugin	Integriert	Nur Konfiguration
Eigenes Auth-Plugin	Plugin	Plugin	Durch Keycloak OIDC ersetzen

Zeitfenster für die Migration planen

Wichtig: Planen Sie die LMS-Migration in der vorlesungsfreien Zeit (Semesterferien). Kalkulieren Sie mindestens zwei Wochen für die Migration und eine weitere Woche für die Verifizierung vor dem nächsten Semester.

Semester	Empfohlenes Fenster	Dauer
Sommerpause (Juli–September)	Mitte August	3 Wochen
Winterpause (Dezember–Februar)	Anfang Januar	2 Wochen
Frühjahrspause (März–April)	Ende März	1 Woche (eng)

Videokonferenz-Migration

BigBlueButton

Bei BigBlueButton müssen Aufzeichnungen (auf der Festplatte) und API-Benutzerdaten migriert werden:

# Aufzeichnungen kopieren
rsync -av /var/bigbluebutton/published/ \
  neuer-server:/var/bigbluebutton/published/
rsync -av /var/bigbluebutton/unpublished/ \
  neuer-server:/var/bigbluebutton/unpublished/
rsync -av /var/bigbluebutton/recording/raw/ \
  neuer-server:/var/bigbluebutton/recording/raw/

# Metadaten auf dem neuen Server neu aufbauen
bbb-record --rebuildall

API-Benutzerdaten (Berechtigungen zur Meeting-Erstellung, Hooks) werden in der Datenbank gespeichert. Exportieren Sie die Tabellen meeting und users aus PostgreSQL und importieren Sie sie in die neue Instanz.

Jitsi

Jitsi-Raumzustände sind flüchtig (werden im Prosody/XMPP-Speicher gehalten). Es gibt keine zu migrierenden Raumdaten – Räume werden bei Bedarf erstellt. Es muss nur die Konfiguration übertragen werden:

config.js: Branding, Authentifizierungseinstellungen
prosody.cfg.lua: Domain und Authentifizierung
Benutzerdefinierte Meeting-URL-Muster

Meeting-URL-Weiterleitung während der Übergangsphase

Richten Sie während der Übergangsphase URL-Weiterleitungen von der alten Videokonferenz-Domain auf die neue ein:

# Nginx-Weiterleitung für alte Meeting-URLs
server {
  server_name meet.alt.uni-example.de;
  return 301 https://meet.openedesk.uni-example.de$request_uri;
}

DNS- und Domain-Umstellung

Die DNS-Umstellung bestimmt, ab wann Nutzende auf die neue Infrastruktur zugreifen. Führen Sie sie methodisch durch.

Schritt-für-Schritt-DNS-Plan

T-48h: TTL aller betroffenen Records auf 300 Sekunden senken
T-24h: Umstellungsfenster allen Nutzenden ankündigen
T-0h (Auth-Umstellung): Auth-/CNAME-Records auf openDesk-Edu-Keycloak umbiegen
T+1h (E-Mail-Umstellung): MX-Records ändern
T+2h (Datei-Umstellung): Cloud-CNAME ändern
T+3h (LMS-Umstellung): LMS-CNAME ändern
T+4h (Konferenz-Umstellung): Meet-CNAME ändern
T+48h: TTL wieder auf Normalwerte erhöhen

TTL-Absenkung vorbereiten

# Vor der Umstellung (T-48h)
nsupdate << EOF
server ns1.uni-example.de
zone uni-example.de
update delete uni-example.de. MX
update add uni-example.de. 300 MX 10 mail.alt.uni-example.de.
send
EOF

Umstellungsreihenfolge

Stellen Sie zuerst die Authentifizierung um, dann die Dienste in Abhängigkeitsreihenfolge. Die E-Mail-Umstellung sollte so früh wie möglich erfolgen, da die MX-Propagation auch bei niedriger TTL Zeit benötigt.

DNS-Propagation überwachen

Verwenden Sie dig, um die Propagation global zu überwachen:

# Von mehreren Resolvern aus überwachen
for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do
  dig @$ns MX uni-example.de +short
  sleep 1
done

# Bestimmten Record-Typ prüfen
dig +short MX uni-example.de
dig +short A auth.uni-example.de

TLS-Zertifikate neu ausstellen

Nach der DNS-Umstellung müssen TLS-Zertifikate für die neue Infrastruktur ausgestellt werden. openDesk Edu unterstützt zwei Ansätze:

openDesk Certificates (Bundesdruckerei): Für Hochschulen, die qualifizierte Zertifikate benötigen
Let's Encrypt: Automatisierte Ausstellung per cert-manager in Kubernetes

# cert-manager ClusterIssuer für Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: it-admin@uni-example.de
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

Rollback-Plan

Trotz bester Vorbereitung kann eine Migration fehlschlagen. Bereiten Sie den Rückbau vor der Umstellung vor, nicht erst danach.

Alte Infrastruktur im Read-Only-Modus belassen

Halten Sie die alte Infrastruktur für mindestens 30 Tage nach der Umstellung im Read-Only-Modus. Dies bedeutet:

Mailserver: E-Mails annehmen, aber SMTP-Authentifizierung ablehnen; an neuen Server weiterleiten
Dateispeicher: WebDAV im Read-Only-Modus
LMS: Keine neuen Inhalte zulassen, aber historische Daten einsehbar halten
IdP: Weiterlaufen lassen, aber als Backup markieren

Datensynchronisation für den Rollback

Falls ein Rollback erforderlich wird:

E-Mail: imapsync in umgekehrter Richtung ausführen (neu → alt). Nur geänderte Nachrichten müssen synchronisiert werden.
Dateien: rclone in umgekehrter Richtung ausführen. Auf dem neuen System erstellte Versionen gehen verloren.
LMS: Datenbank-Backup aus der Zeit vor der Migration einspielen. Kurse, die auf dem neuen System bearbeitet wurden, müssen vorher re-exportiert werden.
Identity: Keycloak-Datenbank-Backup einspielen, alten IdP reaktivieren.

Das Rollback-Zeitfenster schrumpft mit jedem Tag. Nach 7 Tagen wird ein Rollback aufgrund von Datenabweichungen zunehmend schwierig. Nach 30 Tagen ist ein vollständiger Rückbau nicht mehr praktikabel – ab diesem Punkt sollte die Umstellung als abgeschlossen betrachtet werden.

Kommunikationsplan für Nutzende

Zeitpunkt	Nachricht	Kanal
2 Wochen vorher	„Migration angekündigt" – Termine, Auswirkungen, Anleitungen	E-Mail, Intranet
48h vorher	„Letzte Erinnerung" – Was zu erwarten ist, Ausfallfenster	E-Mail
Während der Umstellung	„Dienststatus" – Echtzeit-Updates zum Fortschritt	Statusseite
Nach der Umstellung	„Neue Dienste verfügbar" – Login-Anleitung, Hilfeseiten	E-Mail, On-Screen-Banner
Wöchentlich (erster Monat)	„Wie läuft es?" – Feedback einholen	Umfrage

Nachbereitung und Verifizierung

Dienstbezogene Checkliste

Dienst	Verifiziert durch	Status
Keycloak-Authentifizierung	Login-Test von 5 Nutzenden aus verschiedenen Gruppen	✅ / ❌
E-Mail (IMAP/SMTP)	Sende-/Empfangstest, Webmail-Login
E-Mail (Kalender)	Termin erstellen/ändern/löschen
Dateispeicher (WebDAV)	Datei hochladen/herunterladen/löschen
Dateispeicher (Freigaben)	3 gemeinsame Ordner prüfen
LMS (Kursansicht)	5 Kurse mit verschiedenen Rollen aufrufen
LMS (Notenbuch)	Notenexport von alt und neu vergleichen
BigBlueButton	Raum erstellen, Bildschirm teilen, Aufzeichnung ansehen
Jitsi	Raum erstellen, Audio/Video testen
Collabora/Office	Dokument öffnen, bearbeiten, speichern
Etherpad/CryptPad	Pad erstellen, teilen, gemeinsam bearbeiten

Abnahmetests durch Nutzende (User Acceptance Testing)

Stellen Sie eine Gruppe von 20–50 Nutzenden zusammen, die verschiedene Rollen repräsentieren (Studierende, Lehrende, Verwaltung, Forschende). Geben Sie ihnen ein Testskript mit den häufigsten Arbeitsabläufen:

Einloggen (Single Sign-On)
E-Mail mit Anhang versenden
Meeting mit Kalendereinladung planen
Datei hochladen und teilen
LMS-Kurs aufrufen und Aufgabe abgeben
Videokonferenz mit Bildschirmfreigabe beitreten
Gemeinsames Dokument bearbeiten

Sammeln Sie Feedback mittels einer strukturierten Umfrage. Die Migration ist erst abgeschlossen, wenn die Abnahmegruppe grünes Licht gibt.

Leistungsvergleich

Messen und vergleichen Sie die wichtigsten Leistungskennzahlen vor und nach der Migration:

Metrik	Altes System	Neues System	Akzeptabel
E-Mail-Zustellzeit (intern)	< 5 Sek.	< 3 Sek.	✅
E-Mail-Zustellzeit (extern)	< 30 Sek.	< 15 Sek.	✅
Dateiupload (10 MB)	2,1 Sek.	0,8 Sek.	✅
LMS-Seitenaufbau	1,4 Sek.	0,9 Sek.	✅
Videokonferenz-Beitritt	8 Sek.	4 Sek.	✅
Authentifizierungsantwort	1,2 Sek.	0,6 Sek.	✅

Stilllegung der alten Infrastruktur

Phase	Aktion	Zeitplan
1	Nicht kritische Altdienste abschalten	1 Woche nach Umstellung
2	DNS-Records auf alte Infrastruktur entfernen	2 Wochen nach Umstellung
3	Alten Dateispeicher abschalten (Read-Only → Offline)	2 Wochen nach Umstellung
4	Alten IdP außer Betrieb nehmen	4 Wochen nach Umstellung
5	Alten Mailserver abschalten	4 Wochen nach Umstellung
6	Letztes Backup und Abschaltung der alten Infrastruktur	6 Wochen nach Umstellung
7	Hardware freigeben/anderweitig verwenden	8 Wochen nach Umstellung

Anhang: Kurzreferenz

Wichtige Werkzeuge

Werkzeug	Zweck	Installation
imapsync	Postfachmigration	`apt install imapsync`
rclone	Dateispeichermigration	`apt install rclone`
vdirsyncer	CalDAV/CardDAV-Synchronisation	`pip install vdirsyncer`
kcadm.sh	Keycloak-Admin-CLI	In Keycloak enthalten
occ	Nextcloud-Kommandozeile	In Nextcloud enthalten
dig	DNS-Propagation prüfen	`apt install bind9-dnsutils`

Wichtige Kontakte

openDesk Edu Support: support@openedesk-edu.org
DFN-AAI Föderationssupport: aai@dfn.de
Community-Forum: community.openedesk-edu.org

Letzte Aktualisierung: 2026-06-13. Dieser Leitfaden gilt für openDesk Edu Version 2.x und höher.