Wer von Moodle4.5 auf Moodle5.1.3 wechseln will, steht nicht vor einem normalen Patchday. Die Migration ist technisch zwar offiziell unterstützt, sie greift aber an mehreren Stellen tief in den Betrieb ein: neue Anforderungen an PHP und Datenbank, eine geänderte Webserver-Struktur mit /public sowie mögliche Nacharbeiten bei Plugins, Themes und Integrationen. Genau deshalb behandeln wir den Wechsel nicht als Schnellschuss, sondern als planbares Migrationsprojekt.

Bei ADMIN INTELLIGENCE sehen wir solche Vorhaben vor allem in On-Premise- und Inhouse-Umgebungen, in denen Moodle nicht nur „läuft“, sondern an Authentifizierung, Videotools, Zusatzplugins, Mail und Betriebsprozesse angebunden ist. In diesem Beitrag zeigen wir, wie wir eine Moodle4.5-zu-Moodle5.1.3–Migration strukturiert vorbereiten und welche Punkte vor dem Livegang zwingend geprüft werden sollten.

Warum der Wechsel auf Moodle5.1.3 mehr als ein Update ist

Der direkte Upgrade-Pfad ist offiziell freigegeben: Moodle 5.1 lässt sich von Moodle 4.2.3 oder neuer aktualisieren. Damit ist der Weg von Moodle4.5 auf Moodle5.1.3 grundsätzlich unterstützt. Ein Pflicht-Zwischenschritt über 4.6 oder 5.0 ergibt sich aus der offiziellen Upgrade-Dokumentation nicht.

Trotzdem ist der Schritt kein Routine-Update. Der wichtigste Grund ist die neue Verzeichnisstruktur ab Moodle 5.1. Webzugängliche Dateien liegen nun unter /public. Der Webserver muss also so konfiguriert werden, dass der DocumentRoot auf dieses Verzeichnis zeigt. Wenn diese Umstellung fehlt oder falsch gesetzt ist, drohen nach dem Upgrade Fehlermeldungen oder sogar Directory Listings.

Dazu kommt eine strategische Einordnung, die oft übersehen wird: Moodle 4.5 ist eine LTS-Version, Moodle 5.1 dagegen nicht. Wer auf Moodle5.1.3 geht, entscheidet sich also nicht einfach für „die neueste stabile Langzeitversion“, sondern für einen aktuellen Release-Stand mit anderem Lebenszyklus. Das kann sinnvoll sein, etwa wenn technische Abhängigkeiten, Anforderungen aus Projekten oder Theme-Korrekturen für 5.1.3 eine Rolle spielen. Es sollte nur bewusst entschieden werden.

Welche Rahmenbedingungen vor der Moodle Migration geprüft werden müssen

Bevor wir ein Testsystem aufbauen oder den Livegang planen, prüfen wir den technischen Unterbau. Gerade bei älteren Installationen liegt das Risiko oft nicht im Moodle-Core, sondern in der Umgebung.

PHP, Architektur und Pflichtmodule

Für Moodle 5.1 gelten laut offizieller Dokumentation diese Mindestanforderungen:

• PHP 8.2.0 oder höher
• Unterstützung für PHP 8.3.x und 8.4.x
• ausschließlich 64-Bit-PHP
• die PHP-Erweiterung sodium muss vorhanden sein
• max_input_vars >= 5000

In der Praxis heißt das: Wer noch mit einer älteren PHP-Version arbeitet, kann die Migration nicht isoliert betrachten. Dann gehört die Laufzeitumgebung in dasselbe Projekt. Vor allem bei On-Premise-Systemen sehen wir oft Konfigurationen, die historisch gewachsen sind. Moodle selbst läuft vielleicht noch, aber einzelne Parameter passen nicht mehr zur Zielversion.

Ein kurzer Check auf der Shell spart hier viel Zeit. Typische Prüfungen sehen etwa so aus:

php -v
php -m | grep sodium
php -i | grep max_input_vars

Wenn schon an dieser Stelle Lücken sichtbar werden, ist das kein Stoppschild. Es zeigt nur, dass die Moodle Migration sauber vorbereitet werden muss.

Datenbank-Versionen

Auch die Datenbankseite muss zur Zielversion passen. Für Moodle 5.1 gelten mindestens:

• PostgreSQL 15
• MySQL 8.4
• MariaDB 10.11.0
• Microsoft SQL Server 2017
• Aurora MySQL 8.0

Zusätzlich ist relevant: Oracle Database wird seit Moodle 5.0 nicht mehr unterstützt. Wer eine ältere Umgebung mit Oracle-Historie betreibt, muss diesen Punkt frühzeitig klären.

In vielen Projekten lohnt sich vorab ein Blick auf die Datenbankgröße, die Laufzeiten von Sicherungen und die Reaktionszeit bei Restore-Tests. Eine Live-Migration ohne validierte Rücksicherung ist bei produktiven Lernplattformen unnötig riskant.

Plugins, Themes und Integrationen sind der eigentliche Prüfstein

Der Core-Wechsel von Moodle4.5 auf Moodle5.1.3 ist nur ein Teil der Arbeit. In realen Umgebungen entscheiden meist installierte Erweiterungen darüber, ob ein Projekt sauber durchläuft oder kurz vor dem Wartungsfenster ins Stocken gerät.

Plugins müssen für den Ziel-Build passen

Moodle weist ausdrücklich darauf hin, dass Plugins nur für den exakten Ziel-Build verlässlich funktionieren. Daraus folgt für die Praxis: Vor dem Upgrade prüfen wir nicht nur, ob ein Plugin grundsätzlich für 5.1 existiert, sondern auch, ob eine passende Version für den konkreten Zielstand vorliegt.

Besonders kritisch sind dabei:

• Drittanbieter-Plugins
• Eigenentwicklungen
• Authentifizierungs- und SSO-Erweiterungen
• Aktivitäts- und Fragetyp-Plugins
• H5P-Erweiterungen
• Videokonferenz-Plugins

Wenn Sie solche Erweiterungen im Einsatz haben, lohnt auch ein Blick auf unseren Beitrag zu H5P in Moodle, weil genau diese Art von Zusatzfunktion bei einer Migration häufig nachgetestet werden muss.

Die neue /public-Struktur betrifft auch Plugins

Ein Punkt, den man nicht übergehen sollte: Bereits installierte Plugins können nach dem Upgrade noch an alten Stellen liegen und müssen unter Umständen manuell in die passende Struktur innerhalb von /public verschoben werden. Das ist kein Randthema, sondern eine konkrete technische Änderung in Moodle 5.1.

Gerade bei Installationen mit vielen Erweiterungen oder Eigenanpassungen prüfen wir deshalb nicht nur Versionsnummern, sondern auch Pfade, Deployments und eventuell angepasste Webserver-Regeln. Ein System kann formal aktualisiert sein und trotzdem an falsch eingebundenen Komponenten scheitern.

Themes und Renderer gezielt testen

Im Rohmaterial war von „Template anpassen“ die Rede. Fachlich sauberer ist: Theme- und Renderer-Kompatibilität prüfen und anpassen. Das trifft den Kern deutlich besser.

Für Moodle5.1.3 ist das besonders relevant, weil die offizielle Release Note einen Fix für ein Problem aus 5.1.2 nennt, das Drittanbieter-Themes betrifft, die den core admin renderer anpassen, etwa Moove. Wer mit individuellen Themes arbeitet, sollte daher nicht bei „5.1.x“ stehenbleiben, sondern den konkreten Patch-Stand betrachten.

Das heißt nicht automatisch, dass jedes Fremdtheme unter 5.1.3 problemlos läuft. Es heißt nur: Ein aktueller Patch-Stand ist in diesem Bereich fachlich begründet und kein Detail am Rand.

Unser Vorgehen bei einer Moodle4.5 zu Moodle5.1.3 Migration

Bei ADMIN INTELLIGENCE teilen wir das Projekt in klar nachvollziehbare Schritte. So lassen sich technische Risiken früh erkennen, statt sie erst im Wartungsfenster zu entdecken.

Moodle Check-up und Bestandsaufnahme

Am Anfang steht kein Upgrade-Klick, sondern eine belastbare Inventur. Wir erfassen:

• genaue Moodle-Version und Build-Stand
• PHP-Version und aktive Erweiterungen
• Datenbanktyp und Datenbankversion
• Webserver-Setup und aktueller DocumentRoot
• verwendete Plugins, Themes und Eigenentwicklungen
• Authentifizierung, SSO, Mail, Videotools und weitere Schnittstellen
• Backup- und Restore-Stand
• Cronjobs und Nacharbeiten im Betrieb

Für diesen Einstieg ist ein strukturierter Moodle Check-up oft der schnellste Weg, weil er technische und organisatorische Punkte zusammenführt. Ergänzend passt auch unser Artikel zum Moodle Check-Up, wenn Sie vorab sehen möchten, welche Prüffelder wir im Betrieb regelmäßig bewerten.

Falls unklar ist, auf welchem Stand die Plattform gerade wirklich läuft, hilft auch ein kurzer Blick in unseren Quick Tipp zur Moodle-Version.

Testsystem aufsetzen

Nach der Bestandsaufnahme bauen wir ein Testsystem, das der produktiven Umgebung so nahe wie möglich kommt. Genau hier trennt sich eine brauchbare Vorbereitung von einer bloßen Annahme.

Ein Testsystem sollte mindestens diese Punkte abbilden:

• gleiche oder vergleichbare PHP-Version
• passende Datenbankversion
• identische Plugin-Liste
• identisches Theme
• Kopie von Datenbank und moodledata
• Webserver-Konfiguration mit DocumentRoot auf /public

Wenn die Umgebung virtualisiert ist, lässt sich ein solches Staging sauber auf einer Plattform wie Proxmox aufbauen. Für die Migration ist das praktisch, weil Snapshots, Klone und klar getrennte Testläufe den Ablauf planbarer machen.

Testmigration durchführen

Erst im Testsystem zeigt sich, ob die Theorie trägt. Wir spielen dort den kompletten Upgrade-Weg von Moodle4.5 auf Moodle5.1.3 durch und dokumentieren jeden Eingriff.

Dabei achten wir besonders auf:

• Upgrade-Verhalten des Moodle-Core
• Fehler oder Warnungen im Plugin-Check
• Theme-Darstellung im Frontend und Backend
• Login-Verfahren und Rollen
• Kursaufrufe, Aufgaben, Tests und Bewertungen
• Dateizugriffe und moodledata
• Cronjobs nach dem Upgrade

Wenn BigBlueButton im Einsatz ist, gehört auch diese Funktion in die Testmatrix. Dazu passt unser Artikel zur BigBlueButton-Integration in Moodle, weil Videokonferenz-Plugins in der Praxis oft mehr Nacharbeit brauchen als erwartet.

Anpassungen umsetzen

Nach dem Testlauf arbeiten wir die Befunde ab. Typische Maßnahmen sind:

• inkompatible Plugins aktualisieren oder ersetzen
• Eigenentwicklungen anpassen
• Theme- und Renderer-Anpassungen nachziehen
• Webserver auf die neue /public-Struktur abstimmen
• Auth- und SSO-Konfiguration nachtesten
• Cronjobs und Automationen anpassen

Wenn Moodle an einen Identity Provider angebunden ist, prüfen wir die Authentifizierung gesondert. Bei Nextcloud- oder OAuth2-Szenarien ist unser Beitrag zu Moodle SSO mit OAuth2 und Nextcloud ein passender technischer Bezug.

Backup-, Restore- und Rollback-Konzept festlegen

Vor der Live-Migration definieren wir nicht nur ein Backup, sondern einen Rückweg. Dazu gehören mindestens:

• vollständiges Backup der Datenbank
• Sicherung des Moodle-Codes
• Sicherung von moodledata
• dokumentierter Restore-Ablauf
• klares Wartungsfenster
• Entscheidungskriterien für Abbruch oder Freigabe

Viele Ausfälle nach Upgrades entstehen nicht durch den eigentlichen Versionswechsel, sondern durch einen fehlenden oder nie getesteten Rollback-Plan. Wer bei einem produktiven LMS mit realen Kursen, Prüfungen oder Schulungsterminen arbeitet, sollte diesen Punkt nicht an den Rand schieben.

Livemigration im Wartungsfenster

Erst wenn Testmigration, Nacharbeiten und Rückfallplan stehen, gehen wir an das Produktivsystem. Für die Live-Migration setzen wir ein definiertes Wartungsfenster und arbeiten eine feste Reihenfolge ab:

1. Wartungsmodus aktivieren
2. aktuelle Sicherungen erstellen und prüfen
3. Code- und Konfigurationsstand dokumentieren
4. Upgrade auf Moodle5.1.3 durchführen
5. Webserver- und /public-Pfad kontrollieren
6. Plugins, Themes und Integrationen prüfen
7. Cronjobs testen
8. Freigabe nach Funktionskontrolle

Das Ziel ist nicht „möglichst schnell“, sondern nachvollziehbar und beherrschbar.

Nachkontrolle nach dem Go-live

Nach dem Livegang endet das Projekt nicht. Wir prüfen die wichtigsten Kursszenarien im laufenden System:

• Administrator-Login
• Trainer- und Teilnehmer-Login
• Kurszugriff
• Datei-Upload und Dateiabruf
• Aufgaben und Tests
• Mailversand
• Cronjob-Ausführung
• externe Integrationen

Gerade in den ersten Stunden nach der Migration lohnt ein Blick in Logs und Monitoring. Kleine Abweichungen fallen dort oft früher auf als über Supporttickets.

Was sich bei Moodle5.1.3 technisch besonders beachten lässt

Einige Punkte sind bei dieser Zielversion besonders praxisrelevant.

Die /public-Umstellung muss aktiv geplant werden

Der Wechsel auf /public ist keine Formalität. Wenn Apache oder Nginx noch auf das bisherige Webroot zeigen, passt die Struktur nicht mehr zur Zielversion. Das Problem zeigt sich dann nicht erst tief im Betrieb, sondern oft sofort über Fehlermeldungen oder falsches Verhalten an der Oberfläche.

Deshalb prüfen wir in der Testmigration immer auch die Webserver-Konfiguration. Wer mehrere vHosts, Reverse Proxys oder spezielle Rewrite-Regeln nutzt, sollte diese Konstellation exakt nachbilden.

Der Patch-Stand 5.1.3 ist bei Themes relevant

Der Fix für Drittanbieter-Themes, die den core admin renderer anpassen, macht Moodle5.1.3 für Umgebungen mit individuellem Frontend oder Admin-Theme besonders interessant. Das ersetzt keinen Test, reduziert aber ein konkretes Risiko, das in 5.1.2 dokumentiert wurde.

Die Version ist aktuell, aber keine LTS

Für die Entscheidungsfindung gehört dieser Punkt offen auf den Tisch: Moodle 5.1 ist keine LTS-Version. Wer heute von Moodle4.5 wechselt, sollte also auch die weitere Release-Planung im Blick behalten. Es geht nicht darum, 5.1.3 schlechtzureden. Es geht darum, den Schritt fachlich richtig einzuordnen.

Für welche Umgebungen sich die Migration besonders lohnt

Der Wechsel von Moodle4.5 auf Moodle5.1.3 ist vor allem dort ein Thema, wo Moodle als zentraler Baustein im Betrieb verankert ist:

• On-Premise-Installationen mit eigener Infrastruktur
• Inhouse-Systeme mit Datenschutz- und Integrationsvorgaben
• Plattformen mit vielen Plugins oder Eigenentwicklungen
• Moodle-Umgebungen mit SSO, Nextcloud oder Videokonferenz-Anbindung
• Organisationen, die Änderungen erst im Testsystem validieren müssen

Genau dort hilft ein strukturiertes Vorgehen. Der Aufwand entsteht nicht, weil Moodle grundsätzlich schwer zu aktualisieren wäre, sondern weil echte Produktionsumgebungen selten aus einem unveränderten Standardpaket bestehen.

Wie ADMIN INTELLIGENCE die Moodle Migration begleitet

Wir unterstützen entlang des kompletten Ablaufs: von der Bestandsaufnahme über das Testsystem bis zur Live-Migration. Je nach Bedarf übernehmen wir die technische Prüfung, die Nacharbeit an Plugins und Themes oder die operative Begleitung im Wartungsfenster.

Wenn ein Projekt bereits feststeckt oder ein Upgrade schiefgelaufen ist, gibt es mit dem Moodle Notfall von ADMIN INTELLIGENCE auch einen direkten Einstieg für akute Fälle. Für den regulären Projektstart ist unsere Moodle-Leistungsseite der passende Ausgangspunkt.

Wer seine Administrationszugänge im Zuge der Migration absichern möchte, findet außerdem in unserem Beitrag zur Moodle-2FA für Administratoren einen praxisnahen Anschluss an das Thema Betriebssicherheit. Weitere technische Beiträge rund um Moodle und andere Betriebsplattformen finden Sie laufend im Blog von ADMIN INTELLIGENCE. Wenn Sie eine Moodle4.5-zu-Moodle5.1.3–Migration für Ihre Umgebung sauber planen möchten, sprechen Sie uns gern direkt über unsere Kontaktpage an.