Wer wissen will, was ein Shop-Update an der Datenbank verändert, sucht die Migrationen. Beim naheliegenden Ort wird man fündig — mit einem leeren Verzeichnis. Der Schluss daraus wäre falsch und teuer.
Ein Update-Verzeichnis mit einem Unterordner namens migrations ist eine nachvollziehbare Vermutung. Bei JTL-Shop 5 führt sie in die Irre: Seit Version 5.4 liegt dort nichts mehr. Wer nur dorthin sieht, kommt zu dem Schluss, das Update fasse die Datenbank gar nicht an.
Dieser Schluss ist falsch — und er ist gefährlich, weil er die Planung für den Rückweg verdirbt. Wer glaubt, es gehe nur um Dateien, sichert nur Dateien.
Die ausgeführten Migrationen liegen im Quellbaum der Anwendung, unter includes/src/Migrations/. Dort steht jede Änderung als eigene Klasse, benannt nach ihrem Zeitstempel — und dort steht auch, was sie anfasst.
Weil man damit vorher beantworten kann, was ein Versionssprung überhaupt berührt. Für den Sprung von 5.5.4 auf 5.6.2 ergab die Auswertung: zwölf betroffene Tabellen von 544.
Diese Zahl verändert alles. Ohne sie bleibt im Schadensfall nur, den kompletten Datenbestand zurückzuspielen — samt aller Bestellungen, die seit der Sicherung eingegangen sind. Mit ihr wird ein zielgenauer Rückweg möglich: nur die betroffenen Tabellen, alles andere bleibt, wie es ist.
Genau deshalb lohnt sich die Auswertung, bevor man ein Update fährt — nicht danach.
Der Fall ist ein gutes Beispiel für ein wiederkehrendes Muster: Die naheliegende Annahme über ein fremdes System ist oft nachvollziehbar, plausibel — und falsch. Der Unterschied zwischen „vermutlich“ und „gemessen“ kostet zehn Minuten und entscheidet manchmal über einen Arbeitstag.
Passend dazu: Was ein reines Datenbank-Backup nicht rettet.
Individuelle Software und Werkzeuge für Betriebe, die mit Standardlösungen an Grenzen stoßen.