QGIS 4.2 jetzt upgraden: Migrationswahl für Forschungsprojekte 2026

QGIS 4.2 wird auf der offiziellen Downloadseite als aktuelle reguläre Version geführt. QGIS 3.44 wird dort als aktuelle LTR-Version ausgewiesen. Die offizielle Roadmap plant, QGIS 4.2 im Oktober 2026 in den LTR-Kanal zu überführen. Dieser geplante Wechsel ist noch kein abgeschlossener Status und darf in einer Projektfreigabe nicht vorweggenommen werden. Die offizielle Release-Planung mit LTR-Hinweisen ist deshalb ein Termin für die nächste Prüfung, kein automatischer Upgrade-Befehl.

Für die Entscheidung zählt nicht, ob das Installationsprogramm startet. Entscheidend sind vier Fragen:

1. Gibt es vor dem nächsten Abgabetermin ausreichend Zeit für eine Rückfallprüfung?
2. Sind alle tatsächlich genutzten Plugins und Processing Provider kompatibel?
3. Erzeugt QGIS 4.2 dieselben fachlichen Resultate und Exportdateien?
4. Kann das Team bei einer Abweichung sofort mit QGIS 3.44 LTR weiterarbeiten?

Ein neues Projekt ohne alte Abhängigkeiten kann QGIS 4.2 in einer isolierten Umgebung verwenden. Ein laufendes Projekt mit finalen Karten, automatisierten Analysen oder eingereichten Ergebnissen bleibt zunächst auf QGIS 3.44 LTR. Für ein Labor mit neuen Funktionen, aber hohem Ausfallrisiko ist ein Parallelbetrieb die belastbarste Zwischenlösung.

Hinweis aus dem Betrieb: „Öffnet sich“ und „ist reproduzierbar“ sind zwei verschiedene Freigabekriterien. Ein Projekt kann ohne Fehlermeldung laden und trotzdem andere CRS-Transformationen, Feldwerte, Beschriftungen oder Layoutumbrüche erzeugen.

Der größte Migrationsaufwand liegt oft nicht im QGIS-Hauptprogramm. Er steckt in Drittanbieter-Plugins, Processing Providern, Python-Bibliotheken und selbst geschriebenen Skripten. QGIS 4 basiert auf einer Qt6-Umgebung. Deshalb kann ein bisher funktionierender Erweiterungspfad an einer API-, Abhängigkeits- oder Laufzeitänderung scheitern. Die offizielle Migrationsdokumentation für Plugins sollte für jedes eingesetzte Plugin einzeln geprüft werden.

Erstellen Sie zunächst ein Inventar. Ein Eintrag ist nur vollständig, wenn er folgende Informationen enthält:

• Name und genaue Version des Plugins.
• Zweck im Forschungsablauf.
• Verwendete Processing Provider.
• Python-Abhängigkeiten und externe Kommandozeilenprogramme.
• Eingabedaten, erwartete Ausgaben und verantwortliche Person.
• Link zur offiziellen Plugin-Seite und zum Code-Repository.
• Status der QGIS-4-Kompatibilität: bestätigt, ungeklärt oder nicht verfügbar.

PyQGIS benötigt eine eigene Prüfung. Die offizielle PyQGIS-Dokumentation für QGIS 4.2 beschreibt die Zielumgebung, ersetzt aber keinen Regressionstest Ihres Skripts. Testen Sie mindestens den Import, das Laden eines Projekts, die Auswahl von Layern, die Geometrieverarbeitung, Attributänderungen und den Export.

Stoppen Sie die Migration, wenn ein kritisches Plugin keine bestätigte Unterstützung besitzt, ein Skript nur mit manuellen Änderungen läuft oder ein Processing-Modell andere Ergebnisse erzeugt. Ein Ersatz-Plugin ist nur dann gleichwertig, wenn es dieselben Eingaben, Parameter, Geometrieoperationen und Exportformate liefert.

Für Modelle gehört auch der Modellaufbau in die Prüfung. Die Dokumentation zum QGIS-4.2-Modell-Designer hilft beim Abgleich der Modelllogik. Vergleichen Sie nicht nur den sichtbaren Modellgraphen. Sichern Sie die Parameterwerte und prüfen Sie die erzeugten Zwischenlayer.

Eine QGIS-Migration betrifft mehr als die Datei mit der Endung .qgz oder .qgs. Zum Projekt gehören häufig Stile, Formate, Modelle, benutzerdefinierte Ausdrücke, Datenbankverbindungen und lokale Einstellungen. Die offizielle Dokumentation zur QGIS-Konfiguration erklärt die Benutzerprofile und Konfigurationsbereiche, die bei einer getrennten Testumgebung berücksichtigt werden müssen.

Der sichere Aufbau sieht so aus:

1. Sichern Sie das Originalprojekt, die verwendeten Daten, Stile, Modelle und Skripte in einem versionierten Forschungsordner.
2. Dokumentieren Sie QGIS-Version, Betriebssystem, Plugin-Stände, Python-Abhängigkeiten und Datenbankzugänge.
3. Erstellen Sie eine Arbeitskopie des Projekts. Das Original bleibt unverändert.
4. Legen Sie ein separates QGIS-Benutzerprofil für QGIS 4.2 an.
5. Installieren Sie nur die Plugins, die das Testprojekt tatsächlich benötigt.
6. Öffnen Sie die Kopie und prüfen Sie Layerpfade, Netzwerkverbindungen, Stile, Beschriftungen und Layouts.
7. Öffnen Sie die Projektkopie wieder mit QGIS 3.44 LTR.
8. Vergleichen Sie, ob Datenquellen, Layouts und Modelle nach dem Rückwechsel unverändert verfügbar sind.

Verbindungsinformationen verdienen besondere Aufmerksamkeit. Ein Projekt kann zwar lokal öffnen, aber beim Zugriff auf einen Hochschulserver, eine Geodatenbank oder ein Netzlaufwerk scheitern. Für die Testphase sollten keine Zugangsdaten in eine unkontrollierte Projektkopie eingebettet werden. Nutzen Sie stattdessen einen dafür freigegebenen Testzugang und klären Sie die Datenschutzvorgaben Ihrer Hochschule.

Der Rückfallpfad ist erst bewiesen, wenn QGIS 3.44 LTR die Kopie wieder lädt, die Datenquellen erreichbar sind und mindestens ein Layout erneut exportiert werden kann. Ein Backup, das nie testweise zurückgespielt wurde, ist nur eine Annahme.

Für Forschungsarbeiten reicht ein visueller Vergleich der Benutzeroberfläche nicht. Wählen Sie ein repräsentatives Projekt, das die kritischen Verarbeitungsschritte enthält:

• eine reale Koordinatenreferenzsystem-Transformation,
• mindestens einen räumlichen Verarbeitungsschritt,
• einen Attribut- oder Join-Schritt,
• ein Kartenlayout mit Legende und Beschriftungen,
• den finalen Export in die im Projekt verwendeten Formate.

Führen Sie denselben Ablauf in QGIS 3.44 LTR und QGIS 4.2 durch. Speichern Sie nicht nur Screenshots. Vergleichen Sie die Anzahl der Ausgabeobjekte, CRS-Definitionen, Geometrietypen, Attributfelder, Nullwerte, Messwerte, Layoutbestandteile und Exportdateien.

Bei einer Abweichung prüfen Sie die Ursache in dieser Reihenfolge:

1. Wurde derselbe Datenstand verwendet?
2. Sind Eingabeparameter und Toleranzen identisch?
3. Wurde derselbe Processing Provider aufgerufen?
4. Haben sich CRS-, Geometrie- oder Datentypregeln verändert?
5. Hat ein Plugin oder PyQGIS-Skript einen anderen Pfad verwendet?
6. Ist nur die Darstellung anders oder auch der gespeicherte Inhalt?

Eine abweichende Kartenfarbe ist möglicherweise nur ein Stilproblem. Eine andere Objektanzahl oder ein anderes Koordinatensystem ist ein fachliches Freigabeproblem. Solange die Ursache nicht dokumentiert ist, darf das Ergebnis nicht für eine finale Publikation verwendet werden.

Für die Reproduzierbarkeit speichern Sie beide Testläufe mit Eingabedaten, Protokollen, Parametern und Exporten. Geben Sie jedem Lauf eine eindeutige Bezeichnung. In einem Hochschulteam sollte außerdem feststehen, wer die fachliche Abnahme übernimmt. Die technische Person kann einen erfolgreichen Lauf melden; die wissenschaftliche Verantwortung für die Ergebnisgleichheit bleibt davon getrennt.

Die QGIS-Installationsinformationen berücksichtigen macOS und die unterstützten Installationswege. Die offizielle QGIS-Installationsanleitung ist die Grundlage für den Installationscheck. Für einen Apple-Silicon-Mac genügt es jedoch nicht, dass QGIS startet. Prüfen Sie auch die Architektur der Datenbanktreiber, Python-Pakete, GDAL-nahen Werkzeuge und externen Befehle, die Ihr Projekt aufruft.

Wenn im Labor ausschließlich Windows- oder Linux-Rechner vorhanden sind, kann ein eigenständiger Remote-Mac die bestehende Arbeitsumgebung ergänzen. Das ist vor allem dann sinnvoll, wenn der Test zeitlich begrenzt ist und kein Gerät dauerhaft angeschafft werden soll. MESHLAUNCH stellt dafür den Zugriff auf einen echten verwalteten Mac per VNC, SSH oder Webkonsole bereit. Vor dem Einsatz sollten Sie mit der Hochschule klären, welche Forschungsdaten auf einen externen Rechner übertragen werden dürfen und welche DSGVO-Anforderungen gelten.

Wenn Sie die Hardwareoption für eine längerfristige Nutzung prüfen, können Sie außerdem die Übersicht zum Mac Mini für Forschungs- und Entwicklungsaufgaben heranziehen. Maßgeblich bleiben dabei die tatsächliche Auslastung, die Wartungsverantwortung und die Datenschutzfreigabe Ihres Instituts.

Prüfen Sie die Remote-Umgebung nicht nur mit einem Starttest:

• Öffnet das Projekt ohne unerwartete Pfadänderungen?
• Lassen sich große Layer ausreichend bedienen?
• Funktionieren Layout-Editor, Beschriftung und Kartennavigation?
• Können Daten kontrolliert übertragen und wieder abgeholt werden?
• Läuft ein längerer Processing-Auftrag ohne Sitzungsabbruch?
• Sind SSH, VNC und Webkonsole mit der Sicherheitsrichtlinie des Instituts vereinbar?
• Ist der Zugriff auf Forschungsdaten protokolliert und auf berechtigte Personen begrenzt?

Aussagen zu Bearbeitungsdauer, Interaktionsgeschwindigkeit oder Exportzeit sollten nur aus einem dokumentierten Test stammen. Ohne einen passenden Datensatz und eine konkrete MESHLAUNCH-Konfiguration veröffentlichen wir dafür keine Zahlen. Die Remote-Methode ist ein Prüfpfad, kein allgemeiner Leistungsnachweis.

Wenn Sie vorab die Alternative eines eigenen Geräts bewerten, hilft der interne Überblick zur Mac-Miete für Forschungs- und Entwicklungsumgebungen. Ersetzen sollte das keine Datenschutzprüfung: Sensible Rohdaten gehören nur in eine Umgebung, die durch Ihre Institutsrichtlinien und eine passende Vereinbarung abgedeckt ist.

Die folgende Matrix trennt die drei realistischen Betriebsmodelle. Sie ist keine Bewertung nach gefühlter Geschwindigkeit, sondern nach Abgaberisiko und Nachweisbarkeit.

Für die Teamfreigabe sollten Sie die technischen Nachweise in einer zweiten Tabelle erfassen:

Auch die Kostenentscheidung sollte nicht auf dem Kaufpreis eines Geräts allein beruhen. Berücksichtigen Sie Arbeitszeit für Migration, mögliche Verzögerungen, Ersatzlösungen für Plugins und die Pflege zweier Umgebungen. Für einen kurzen Validierungszeitraum kann eine gemietete Umgebung wirtschaftlich sein; bei dauerhaft hoher Auslastung und vorhandener Infrastruktur kann ein eigener Laborrechner sinnvoller sein.

Checkliste für die Freigabe

• [ ] QGIS 3.44 LTR und QGIS 4.2 sind mit Installationsdatum dokumentiert.
• [ ] Das Originalprojekt wurde nicht als Testobjekt verwendet.
• [ ] Benutzerprofile und Konfigurationsverzeichnisse sind getrennt.
• [ ] Alle Plugins, Processing Provider und Python-Abhängigkeiten sind inventarisiert.
• [ ] Ein repräsentativer PyQGIS- und Processing-Lauf wurde doppelt ausgeführt.
• [ ] Ausgabeobjekte, CRS, Attribute, Layouts und Exporte wurden verglichen.
• [ ] Die Projektkopie wurde mit QGIS 3.44 LTR erneut geöffnet.
• [ ] Apple-Silicon- und externe Tool-Abhängigkeiten sind bestätigt.
• [ ] Datenübertragung, Remote-Sitzung und Zugriffsrechte wurden geprüft.
• [ ] Eine fachlich verantwortliche Person hat die Freigabe dokumentiert.

Kann QGIS 4.2 ein Projekt aus QGIS 3.44 LTR ohne weitere Prüfung übernehmen?

Das Öffnen einer Projektdatei ist nur der erste technische Test. Datenquellen, Stile, Modelle, Plugins, Layouts und Verbindungen können trotzdem abweichen. Verwenden Sie eine Kopie mit eigenem Benutzerprofil. Prüfen Sie danach einen vollständigen Analyse- und Exportlauf und öffnen Sie das Ergebnis erneut mit QGIS 3.44 LTR.

Was geschieht mit alten Plugins und selbst geschriebenen PyQGIS-Skripten?

Die Unterstützung muss für jede Erweiterung einzeln belegt werden. Prüfen Sie Plugin-Verzeichnis, Versionshinweise und Code-Repository. Bei PyQGIS testen Sie nicht nur den Programmstart, sondern auch Imports, Layerzugriff, Geometrieoperationen, Modelle und Exporte. Fehlt ein Nachweis für eine kritische Komponente, bleibt die alte Umgebung produktiv.

Ist QGIS 4.2 auf Apple Silicon grundsätzlich einsatzbereit?

Die offizielle macOS-Unterstützung beantwortet nicht jede Abhängigkeit Ihres Forschungsprojekts. Prüfen Sie Python-Pakete, Datenbanktreiber, externe Programme und eigene Skripte auf passende Architektur. Ein getrennter Apple-Silicon-Test mit einem repräsentativen Projekt zeigt, ob der konkrete Workflow funktioniert. Allgemeine Kompatibilität darf nicht mit Ergebnisgleichheit verwechselt werden.

Ist ein Versionswechsel während einer laufenden Arbeit vertretbar?

Bei einer laufenden Dissertation oder einer nahen Abgabe sollte QGIS 3.44 LTR aktiv bleiben. Ein Wechsel ist erst vertretbar, wenn ein paralleler Test dieselben fachlichen Ergebnisse und Exporte liefert und der Rückweg nachweislich funktioniert. Bei ungeklärten Abweichungen verschieben Sie die Migration, statt die Produktionsumgebung zu gefährden.

Wann ist ein paralleler Betrieb besser als ein sofortiges Upgrade?

Parallelbetrieb ist sinnvoll, wenn neue Funktionen gebraucht werden, aber Plugins, Skripte oder Abgabetermine ein Produktionsrisiko darstellen. Halten Sie Installationen, Benutzerprofile und Datenkopien getrennt. Nach dem geplanten LTR-Wechsel im Oktober 2026 sollte die Matrix erneut geprüft werden; bis dahin bleibt QGIS 4.2 eine reguläre Version und nicht die aktuelle LTR-Basis.

Für viele Forschungsteams ist die bisherige Lösung – ausschließlich Windows- oder Linux-Arbeitsplätze im Labor – bei dieser Migration unpraktisch: Es fehlt die macOS-Zielumgebung, Apple-Silicon-Abhängigkeiten lassen sich nicht real prüfen, und ein einzelner gemeinsamer Rechner blockiert oft die Validierung. Ein sofortiger Hardwarekauf bindet dagegen Budget und Wartungsaufwand, obwohl der Test möglicherweise nur für eine begrenzte Migrationsphase benötigt wird. Wenn die vorhandene Publikationsumgebung nicht unterbrochen werden darf, kann eine getrennte MESHLAUNCH-Mac-Umgebung für die QGIS-4.2-Prüfung die bessere praktische Lösung sein: Projektkopie übertragen, Plugins und PyQGIS testen, Exporte vergleichen und erst danach über die dauerhafte Migration entscheiden.