Python 3.11 End of Life: Dates and How to Upgrade

Python 3.11 reaches end of life in October 2027 and gets security fixes only. What that means, when to move, and what breaks going to 3.12 or later.

Python 3.11 reaches end of life in October 2027. Until then it receives security fixes only, and after that the core team stops releasing fixes of any kind. The sensible time to plan the move is now, while you can choose the date.

For every version’s dates, see the Python end-of-life dates page. The neighbouring versions are covered in Python 3.10 end of life and Python 3.12 end of life.

Python 3.11 dates

The dates come from PEP 664 and the Python Developer’s Guide. Python 3.11 received bugfix releases for about 18 months. Since then it has received source-only security releases, provided irregularly as needed, until about five years after the first release.

What end of life means in practice

Nothing stops on the day. Your code, environments and containers keep running. What changes:

• No interpreter fixes. A vulnerability found in 3.11 is fixed in newer versions only.
• Libraries move on. The latest NumPy (2.5.4), SciPy (1.18.1) and Django (6.1.3) require Python 3.12 or later, according to PyPI on 4 November 2026. pandas, Pillow, Matplotlib and scikit-learn still support 3.11, for now.
• Platforms follow. Check which versions your hosting runtime, CI images and base images still offer.

Which version to move to

Moving to 3.12 is the smallest jump, but it is already in its security-only phase, so you would be upgrading again within a year of 3.11. For the differences between the two newest versions, see Python 3.14 vs 3.15 and what is new in Python 3.15.

What breaks going from 3.11 to 3.12

• Removed modules: distutils, imp, asyncore, asynchat and smtpd.
• Removed aliases: the unittest names failUnless, failIf, assertEquals, assertNotEquals, assertRegexpMatches, assertRaisesRegexp and the other aliases listed in the 3.12 What’s New. Rename to assertTrue, assertFalse, assertEqual, assertNotEqual, assertRegex and assertRaisesRegex.
• No setuptools in new virtual environments. If your code imports setuptools or pkg_resources, declare it as a dependency. You can see the difference by creating one environment on each version:

$ python3.11 -m venv venv311 && venv311/bin/python -m pip list --format=freeze
pip==26.2.2
setuptools==79.0.1

$ python3.12 -m venv venv312 && venv312/bin/python -m pip list --format=freeze
pip==26.2.2

Version numbers will differ on your machine; the point is that setuptools is absent on 3.12.

What breaks going on to 3.13 and 3.14

If you jump past 3.12 you meet these as well, listed by the version that made the change:

More detail on each is in Python 3.13 end of life and what is new in Python 3.14.

An upgrade checklist

1. Find where you run 3.11: python --version in each environment, requires-python in pyproject.toml, FROM python:3.11 in Dockerfiles, and the version settings in CI.
2. Run your tests on the target version first, with warnings turned into errors: python -W error -m pytest. A deprecation warning in your own code then fails a test instead of scrolling past.
3. Check each dependency supports the target. Installing into a fresh virtual environment shows resolver conflicts quickly.
4. Run Ruff with the UP rules to modernise syntax: ruff check --select UP --target-version py313 .
5. Update CI, Docker and deployment settings together, then roll out.

If you need several versions side by side while you migrate, see pyenv vs uv.