Eine Moodle-Migration ist mehr als ein Datenbankexport – und sie muss kein Risiko-Projekt sein. Wir haben Wechsel-Projekte mit fünfstelligen Nutzerzahlen über ein einziges Wochenende durchgezogen, ohne Datenverlust und ohne Downtime jenseits des geplanten Wartungsfensters. Das ist keine Glücksache, sondern Methode.
Von welchen Lernplattformen wir zu Moodle migrieren
Über die Jahre haben wir Migrationen aus praktisch allen relevanten Lernmanagementsystemen umgesetzt. Der Wechsel zu Moodle erfolgt typischerweise von folgenden Quellen:
- ILIAS → Moodle – Kurse, Tests, Lernmodule, Nutzer, Rollen, Gruppen
- Canvas → Moodle – inklusive Quizzes, Assignments, Diskussionen, Modul-Strukturen
- Blackboard / Anthology → Moodle – komplette Course-Cartridges nach IMS-Common-Cartridge-Standard
- OLAT / OpenOLAT → Moodle – wir kennen das Schweizer Hochschul-Ökosystem
- Itslearning → Moodle – häufig im Schul- und Hochschulkontext
- Sakai → Moodle – meist von US-Hochschulen, die nach Europa wechseln
- Stud.IP → Moodle – an deutschen Hochschulen, oft mit Sonderfällen
- Ältere Moodle-Versionen (1.9, 2.x, 3.x) → Moodle 4.x – inklusive aller notwendigen Zwischenschritte
- SCORM-, AICC- und xAPI-Inhalte aus beliebigen LMS-Systemen
Unser Migrationsprozess in sechs Phasen
Phase 1 – Audit der Quellplattform
Bevor wir migrieren, verstehen wir, was zu migrieren ist. Wir analysieren Kurse, Rollen, Aktivitäten, Datenmengen und Sonderfälle. Wir finden auch die versteckten Dinge – die nicht-dokumentierten Workflows, die “ein Kollege mal eingebaut hat”, die undokumentierten Plugins.
Phase 2 – Mapping in Moodle-Strukturen
Übersetzung der Quell-Konzepte in Moodle-Konzepte: Kategorien, Kohorten, Activities, Rollen, Capabilities. Jeder Mapping-Entscheidungspunkt wird schriftlich dokumentiert. Damit Sie nachvollziehen können, warum welche Daten wo gelandet sind.
Phase 3 – Testmigration in Staging
Wir migrieren in eine isolierte Staging-Umgebung. 1 zu 1 mit echten Daten. Damit erkennen wir Probleme, bevor sie produktiv werden.
Phase 4 – User Acceptance Testing
Sie und ausgewählte Anwender testen die Staging-Migration. Wir nehmen Findings auf, arbeiten sie ein, dokumentieren die Lösungen.
Phase 5 – Produktiv-Cutover
Mit definiertem Wartungsfenster, meist an einem Wochenende. Vorher: Final-Backup der alten Plattform. Nachher: Smoke-Test der neuen.
Phase 6 – Hypercare
4 bis 8 Wochen erhöhte Reaktionsbereitschaft. Tickets gehen direkt an das Migrationsteam, nicht in die normale Support-Warteschlange.
Was wir bei einer Moodle-Migration garantieren
- Null-Datenverlust-Garantie bei Standard-Migrationspfaden – Datenverluste sind in unseren Projekten dokumentationspflichtig und bisher Ausnahmefälle
- Reproduzierbare Migration – wir können den gesamten Vorgang jederzeit auf einer neuen Staging-Umgebung wiederholen
- Vollständige Dokumentation des Migrations-Skripts, der Mapping-Entscheidungen und der bekannten Einschränkungen
- Rollback-Plan – für den unwahrscheinlichen Fall, dass nach dem Cutover doch etwas nicht passt
Häufige Fragen zur Moodle-Migration
Wie lange dauert eine Migration zu Moodle?
Eine kleine ILIAS-zu-Moodle-Migration mit etwa 50 Kursen läuft typischerweise in 2 bis 4 Wochen. Eine Großmigration einer Hochschule mit mehreren tausend Kursen und Anbindung an Identity-Provider braucht 3 bis 6 Monate. Nach dem Audit nennen wir Ihnen einen verbindlichen Zeitplan – kein Schätzungs-Pingpong.
Müssen wir während der Migration offline gehen?
Nur während des finalen Cutovers, typischerweise ein Wartungsfenster am Wochenende. Davor und danach läuft Ihre alte Plattform weiter. Bei kritischen Plattformen planen wir den Cutover bewusst in Zeiten mit niedriger Nutzungsdichte.
Können wir stufenweise migrieren?
Ja. Wir entwerfen häufig Stufenmigrationen, bei denen aktive Kurse zuerst migrieren und Archivkurse später. Auch parallele Betriebsphasen sind möglich – allerdings mit dem Hinweis, dass diese die Komplexität erhöhen.
Was passiert mit User-Accounts und Passwörtern?
Nutzeraccounts werden migriert. Passwörter sind bei den meisten LMS-Systemen aus Sicherheitsgründen gehasht und nicht entschlüsselbar – Nutzer müssen daher beim ersten Login auf der neuen Moodle-Plattform ein neues Passwort setzen. Bei Single-Sign-On-Setups entfällt dieses Thema vollständig.
Werden auch SCORM-Pakete und externe Inhalte korrekt übernommen?
Ja. SCORM-1.2- und SCORM-2004-Pakete migrieren wir inklusive der Tracking-Daten Ihrer Lernenden. Bei xAPI- und AICC-Inhalten prüfen wir die Konformität im Vorfeld – manche Implementierungen weichen vom Standard ab.
Verwandte Leistungen
Nach einer Migration folgt der Betrieb – mit unserem technischen Moodle-Support nach SLA. Wenn Sie zusätzlich neue Funktionen brauchen, übernimmt das die individuelle Moodle-Entwicklung. Für die Schulung Ihrer Administratoren und Trainer empfehlen wir praxisnahe Moodle-Workshops. Den großen Überblick zu unserem Angebot finden Sie auf der Moodle Agentur Übersichtsseite. Falls Sie noch Grundlagen brauchen, lesen Sie Was ist Moodle? Der komplette Leitfaden.
