Python 3.10 End of Life im Oktober 2026 und was Unternehmen jetzt tun sollten

Am 1. Oktober 2026 ist Python 3.10.22 erschienen. Es war das letzte Sicherheitsupdate dieser Version, denn mit dem Python 3.10 End of Life ist die Codebasis eingefroren. Für Python 3.10 gibt es keine weiteren offiziellen Updates; neu gemeldete Fehler und Sicherheitslücken bleiben dort offen. Für viele Unternehmen klingt das nach einem Thema, das die Entwicklung schon irgendwie regeln wird. In der Praxis betrifft es aber Server, Datenpipelines, interne Tools und Kundenportale, die seit Jahren zuverlässig laufen und gerade deshalb von niemandem mehr angefasst werden.

Wir zeigen Ihnen, was das Ende der Unterstützung konkret bedeutet, wo Python 3.10 oft unbemerkt weiterläuft, auf welche Version Sie wechseln sollten und wie eine Migration abläuft, ohne dass der laufende Betrieb darunter leidet.

Was das Python 3.10 End of Life konkret bedeutet

Python folgt einem festen Rhythmus. Jede Version bekommt zuerst Fehlerkorrekturen, bei älteren Versionen 18 Monate lang, seit Python 3.13 zwei Jahre. Danach gibt es bis zum fünften Jahr nur noch Sicherheitsupdates. Python 3.10 kam im Oktober 2021 heraus, die fünf Jahre sind also vorbei.

Ihre Anwendung hört deswegen nicht plötzlich auf zu funktionieren. Der Interpreter läuft weiter wie bisher. Das Problem entsteht schleichend. Wird morgen eine Lücke im SSL Modul, im HTTP Client oder in einem XML Parser der Standardbibliothek entdeckt, bleibt sie in 3.10 offen. Das Kernteam von Python wird sie dort nicht mehr schließen.

Dazu kommt ein zweiter Effekt, den viele unterschätzen. Die großen Bibliotheken ziehen mit, aber nicht überall gleichzeitig. Aktuelle Versionen von NumPy, SciPy und pandas 3.0 setzen Python 3.11 oder neuer voraus. Django 5.2 LTS unterstützt Python 3.10 noch, Django 6.0 setzt mindestens Python 3.12 voraus. Wer bei 3.10 bleibt, kann bei einzelnen Paketen an älteren Versionen festhängen und sollte die Unterstützung aller eingesetzten Abhängigkeiten prüfen.

Spätestens im nächsten Audit kann das unangenehm werden. Für von der NIS2-Richtlinie erfasste Einrichtungen gehören risikobasierte Maßnahmen einschließlich der Behandlung von Schwachstellen zum Sicherheitsmanagement. Beim Cyber Resilience Act gelten seit dem 11. September 2026 Meldepflichten; die Hauptpflichten folgen ab dem 11. Dezember 2027. Unabhängig davon sollte das Risiko nicht unterstützter Software nachvollziehbar bewertet und dokumentiert werden.

Wo Python 3.10 noch läuft, oft ohne dass es jemand merkt

Die meisten Teams wissen ungefähr, welche Version ihre Hauptanwendung nutzt. Heikler sind die Ecken, an die niemand denkt. Diese Stellen sehen wir besonders häufig.

• Ubuntu 22.04 bringt Python 3.10 als Systemversion mit. Canonical versorgt diese Pakete zwar weiter mit Sicherheitsupdates, mit Ubuntu Pro sogar noch einige Jahre länger. Ihre per pip installierten Abhängigkeiten deckt das aber nicht ab.
• Container Images, die vor zwei oder drei Jahren auf Basis von Python 3.10 gebaut und seitdem nur neu gestartet, aber nie neu gebaut wurden.
• Funktionen in AWS Lambda mit der Laufzeit Python 3.10. Nach dem aktuellen AWS Laufzeitplan kann AWS dafür ab dem 31. Oktober 2026 keine Sicherheitsupdates oder sonstigen Updates mehr einspielen. Die anschließend geplanten Termine, ab dem 1. Februar 2027 keine neuen Funktionen mehr anzulegen und ab dem 3. März 2027 bestehende nicht mehr zu aktualisieren, können sich noch ändern.
• Cronjobs auf alten virtuellen Maschinen, die nachts Daten zwischen Systemen hin und her schieben.
• Notebooks und Skripte aus der Datenanalyse, die jemand gebaut hat, der längst nicht mehr im Haus ist, und die heute im Monatsreporting stecken.
• CI Pipelines, in denen die Version fest eingetragen ist und bei jedem Build brav weiterverwendet wird.

Ein guter erster Schritt nach dem Supportende ist deshalb eine einfache Inventur. Welche Server, Container und Funktionen gibt es, und welche Python Version steckt jeweils darin? Mit Zugriff auf Repositories und Infrastruktur lässt sich diese Inventur strukturiert vorbereiten.

Auf welche Version sollten Sie wechseln?

Nach dem Python 3.10 End of Life wirkt ein kleiner Schritt auf Python 3.11 naheliegend. Davon raten wir ab. Python 3.11 erreicht sein Supportende bereits im Oktober 2027, Sie stünden also in einem Jahr wieder vor derselben Aufgabe.

Sinnvoller sind diese Ziele.

• Python 3.12 ist die konservative Wahl. Prüfen Sie vor dem Wechsel die Unterstützung aller eingesetzten Abhängigkeiten; Sicherheitsupdates gibt es bis Oktober 2028.
• Python 3.13 bekommt bis Oktober 2029 Updates und ist für die meisten Anwendungen ein guter Kompromiss aus Reife und Supportdauer.
• Python 3.14 ist seit Oktober 2025 stabil und wird bis Oktober 2030 gepflegt. Hier ist auch die Variante ohne Global Interpreter Lock offiziell unterstützt, was für rechenintensive Dienste interessant werden kann.
• Python 3.15 ist nach dem aktuellen Zeitplan für Oktober 2026 vorgesehen. Geplant sind unter anderem Lazy Imports und UTF-8 als Standardkodierung. Für produktive Systeme sollten Sie zunächst prüfen, ob alle wichtigen Pakete fertige Wheels liefern.

Für die meisten Teams empfehlen wir Python 3.13 oder 3.14. Wer stark auf wissenschaftliche Pakete oder Bibliotheken mit kompiliertem Code setzt, prüft vorher kurz, ob es für alle Abhängigkeiten passende Wheels gibt.

Was Sie durch das Update gewinnen

Ein Update ist mehr als eine lästige Pflicht. Schon Python 3.11 war laut offizieller Dokumentation im Schnitt rund 25 Prozent schneller als 3.10, je nach Anwendung auch deutlich mehr. Die Versionen danach haben die Fehlermeldungen spürbar verbessert, was im Alltag viel Zeit beim Debugging spart. Moderne Typisierung, bessere Werkzeuge und aktuelle Bibliotheken machen den Code wartbarer. Und Sie können wieder die neuesten Versionen von Django, NumPy oder pandas einsetzen, statt sich mit alten Ständen zu arrangieren.

So läuft eine Migration weg von Python 3.10 ab

Eine Migration ist selten spektakulär. Sie ist vor allem sauberes Handwerk. In unseren Projekten hat sich dieser Ablauf bewährt.

1. Bestandsaufnahme

Wir erfassen alle Stellen, an denen Python 3.10 läuft, und alle direkten und indirekten Abhängigkeiten. Lockfiles, requirements.txt und Dockerfiles sind dabei die wichtigsten Quellen.

2. Abhängigkeiten prüfen

Für jedes Paket klären wir, ab welcher Version es die Zielversion unterstützt und ob auf dem Weg dorthin Änderungen liegen, die Ihren Code betreffen. Verwaiste Pakete ohne Release seit Jahren fallen hier auf und brauchen Ersatz.

3. Tests absichern

Ohne Tests ist jede Migration ein Blindflug. Wo die Abdeckung dünn ist, schreiben wir zuerst einfache Tests für die kritischen Abläufe, etwa Bestellungen, Rechnungen oder Importe. Diese Tests halten fest, wie sich das System heute verhält.

4. Code anpassen

Werkzeuge wie pyupgrade und Ruff erledigen einen großen Teil der mechanischen Arbeit. Den Rest machen erfahrene Entwickler von Hand, vor allem dort, wo entfernte Module oder geänderte Schnittstellen im Spiel sind.

5. Parallel testen und ausrollen

In der CI läuft die Testsuite eine Zeit lang gegen beide Versionen. Danach folgt der Rollout schrittweise, mit Monitoring und einem klaren Weg zurück, falls doch etwas hakt.

6. Updates zur Routine machen

Am Ende steht ein Prozess, der künftige Updates einfacher macht. Renovate oder Dependabot schlagen neue Versionen automatisch vor, und die nächste Umstellung landet rechtzeitig im Kalender statt im Krisenmodus.

Typische Stolpersteine bei der Umstellung

Die meisten Probleme nach dem Python 3.10 End of Life sind bekannt und gut lösbar, wenn man sie früh sieht.

• distutils ist seit Python 3.12 nicht mehr Teil der Standardbibliothek. Alte Buildskripte und manche betagte Pakete brechen deshalb.
• Mit Python 3.13 wurden eine Reihe alter Module entfernt, darunter cgi, telnetlib, crypt und imghdr. Wer sie nutzt, braucht Ersatz.
• Alte, fest gepinnte Versionen von NumPy oder anderen Paketen mit kompiliertem Code lassen sich unter Python 3.13 oder 3.14 oft gar nicht installieren. Dann zieht ein Update das nächste nach sich.
• Wer das Python des Betriebssystems verwendet, ist an dessen Zeitplan gebunden. Für Anwendungen ist ein eigener Interpreter im Container oder über uv meist die bessere Lösung.

Der Aufwand hängt vor allem von Testabdeckung, Abhängigkeiten und Infrastruktur ab. Aufwendig wird es besonders dann, wenn Tests fehlen oder viele Abhängigkeiten gleichzeitig große Versionssprünge machen.

Was es kostet, nichts zu tun

Natürlich können Sie das Python 3.10 End of Life auch einfach aussitzen. Viele werden genau das tun. Rechnen Sie dann aber mit den Folgen.

Ungepatchte Lücken summieren sich mit jedem Monat. Kunden, Versicherer und Auditoren können in Fragebögen nach Software ohne Herstellersupport fragen. Und wenn der Umstieg dann doch unter Zeitdruck passiert, weil ein Kunde ihn verlangt oder ein Sicherheitsvorfall eintritt, wird er deutlich teurer als ein geplantes Projekt.

Es gibt noch einen weicheren Faktor. Gute Entwicklerinnen und Entwickler arbeiten ungern auf veralteten Plattformen. Ein aktueller Stack hilft also auch dabei, Leute zu finden und zu halten.

Was Sie noch diese Woche erledigen können

Sie müssen nicht auf ein großes Projekt warten, um das Risiko zu senken. Ein paar Schritte gehen sofort.

• Prüfen Sie, welche öffentlich erreichbaren Dienste noch auf Python 3.10 laufen. Diese haben Vorrang.
• Werfen Sie einen Blick in die Konsole von AWS oder einem anderen Cloudanbieter und suchen Sie nach Funktionen mit alter Laufzeit.
• Lassen Sie Ihre Testsuite probeweise gegen Python 3.13 laufen. Die Fehlerliste zeigt schnell, wo es klemmt.
• Legen Sie eine verantwortliche Person und ein Zieldatum fest. Ohne beides bleibt das Thema erfahrungsgemäß liegen.

Häufige Fragen zum Supportende von Python 3.10

Läuft meine Anwendung nach dem Supportende weiter?

Ja. Auch nach dem Python 3.10 End of Life funktioniert der Interpreter technisch weiter, und Pakete lassen sich weiterhin installieren. Neue Sicherheitslücken werden aber nicht mehr geschlossen, und neue Versionen vieler Bibliotheken laufen nicht mehr darauf.

Reicht ein Wechsel auf Python 3.11?

Für ein Jahr. Python 3.11 erreicht sein Supportende im Oktober 2027. Wer jetzt ohnehin migriert, geht besser direkt auf 3.13 oder 3.14.

Wie lange dauert eine Migration?

Das hängt von Größe, Testabdeckung und Abhängigkeiten ab. Eine kurze Analyse der kritischen Abläufe, Pakete und Infrastruktur schafft eine belastbare Grundlage für die Planung.

Gibt es verlängerten Support für Python 3.10?

Linux Distributionen wie Ubuntu pflegen ihre eigene Python Version weiter. Das kann eine Brücke sein. Das Problem veralteter Abhängigkeiten löst es aber nicht.

Die Migration mit erfahrener Unterstützung planen

Sie möchten wissen, wie groß der Aufwand bei Ihnen wirklich ist? Unser Python Team prüft Ihre Anwendungen, erstellt eine vollständige Liste der Abhängigkeiten und sagt Ihnen, welche Zielversion passt und womit Sie rechnen müssen. Auf Wunsch übernehmen wir die komplette Umstellung oder unterstützen Ihr eigenes Team dabei.

Schreiben Sie uns für ein unverbindliches Erstgespräch. Je früher Sie nach dem Python 3.10 End of Life starten, desto entspannter wird das Projekt.