Python 3.11 end of life (October 2027): upgrade runbook for 3.13 and 3.14

Summary. Python 3.11 loses upstream security fixes in October 2027, its scheduled end of life on python.org and in the CPython developer guide, five years after 3.11.0 shipped on 24 October 2022. After 3.11.9 in April 2024 it moved to source-only security releases; the latest, 3.11.18, came out on 25 October 2026. Lambda moves first: its python3.11 runtime sits on Amazon Linux 2, so AWS deprecates it on 30 June 2027 and blocks function updates on 31 August 2027. Azure Functions supports 3.11 to October 2027, and Google Cloud deprecates python311 on 24 October 2027. Leaving 3.11 means absorbing the 3.12 and 3.13 removals (distutils, imp, 19 legacy modules, lib2to3) and rebuilding every native wheel. Our verdict: move to 3.14 where your dependencies allow, because upstream and Cloud Run support it a year longer than 3.13. On Lambda the two share a 30 June 2029 deprecation date and Azure lists 3.14 ending six months before 3.13, so there pick whichever your dependency tree passes first. Python 3.15 shipped on 9 October 2026 but was still in preview on all three platforms on 7 November 2026.

About this article. For engineering leads and platform teams running Python 3.11 on AWS Lambda, Azure Functions, Google Cloud Run or their own containers. On 7 November 2026 we checked every date against python.org's release status page, the developer guide, the release-schedule PEPs, the What's New pages and the AWS, Microsoft and Google runtime pages, and the compliance section against the DPDP Act 2023 as published on 11 August 2023 and notification G.S.R. 843(E) of 13 November 2025. Platform schedules change, so re-check them before you book a change window. This is not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

Many Python estates also run PostgreSQL 15, which reaches end of life on 11 November 2027. Our PostgreSQL 15 end of life guide covers that side.

What ends in October 2027, and what keeps running

End of life is a support event. A 3.11 interpreter will still run your code on 1 November 2027. What stops is the supply of upstream fixes, and package maintainers then drop the version, so the risk grows month by month.

Under PEP 602, a release gets bugfix releases with binaries for 18 months (two years from 3.13 onward), then source-only security fixes until five years after the x.0 release. PEP 664 records 3.11.9 on 2 April 2024 as the last release with binary installers, followed by nine source-only releases up to 3.11.18. The developer guide prints October 2027 in italics, meaning a scheduled date that can be adjusted; no exact final date has been named.

Dates are from python.org and the schedule PEPs. One detail surprises teams: 3.13 is already security-only, its last binary bugfix release being 3.13.16 on 1 October 2026. For regular python.org binaries the choice is 3.14 or 3.15. On distro packages, container images or managed runtimes this matters less, because the platform builds the interpreter.

Platform dates: Lambda, Azure Functions and Cloud Run

Most teams meet end of life through a platform. We checked all three runtime pages on 7 November 2026.

AWS Lambda: earlier than upstream

AWS's runtime table lists python3.11 on Amazon Linux 2 with deprecation on 30 June 2027, 116 days before 3.11's fifth anniversary and 235 days from 7 November 2026. The reason is the operating system: Amazon Linux 2 reached end of life on 30 June 2026, and AWS patches the Python 3.10 and 3.11 runtimes for critical and selected important Amazon Linux 2 issues, plus language fixes, only until their deprecation dates. Newer Python runtimes run on Amazon Linux 2023.

At deprecation AWS may stop patching, functions lose technical support, and the console stops creating or updating them, though the CLI, SAM and CloudFormation still work. From 29 July 2027 you cannot create python3.11 functions, and from 31 August 2027 you cannot update their code or configuration, but you can still switch them to a supported runtime and invocations continue. AWS emails at least 180 days before deprecation, so by 1 January 2027 for python3.11, but sends nothing for container-image functions: build on the 3.11 base image and nobody will email you.

python3.13 and python3.14 share one deprecation date, 30 June 2029, like other Amazon Linux 2023 runtimes such as java21 and provided.al2023, so on Lambda 3.14 buys no extra time today. python3.15 is in public preview without SLA or technical support, with November 2026 as its target launch month.

Azure Functions: watch the hosting plan

Microsoft's supported languages page, last updated 22 October 2026, lists Python 3.11 as GA until October 2027, 3.12 until October 2028, 3.13 until October 2029 and 3.14 until April 2029, with 3.15 in preview to April 2030. That 3.14 date is earlier than 3.13's; we report it as published and would confirm it with Microsoft before choosing 3.14 for Azure on lifetime grounds. Python apps run on Linux only.

The hosting plan is the bigger constraint. Linux Consumption gets no Python version newer than 3.12, and Microsoft's update guide says a Consumption plan app cannot change its Python version at all. The plan retires on 30 September 2028, and Microsoft's migration path creates a new Flex Consumption app beside the old one, so treat a 3.11 Linux Consumption upgrade as a new Flex Consumption app. Existing 3.11 apps on Elastic Premium or Dedicated plans may still use a Debian Bullseye image (Python|3.11|2.0); Microsoft documents Python|3.11|3.0 on Debian Bookworm as the interim step.

Cloud Run functions and Cloud Run services

Google's schedule, last updated 2 November 2026, is the most generous: python311 deprecates on 24 October 2027 and decommissions on 24 April 2028, a 183-day window in which you can still create and redeploy. After decommission you cannot, and existing functions may be disabled. Notifications start 90 days before deprecation, in late July 2027. python313 runs on the google-22 stack and python314 on google-24, so 3.14 also changes the base operating system: rebuild native dependencies.

The same dates apply to Cloud Run services built from source on Google-managed base images. Container images you build and deploy yourself are outside that policy, so the schedule is yours to enforce.

Picking the target: 3.13, 3.14 or 3.15

Python 3.12 is a holding move, not a target: it ends in October 2028 and is already security-only.

The framework floor matters too. Django 6.0's release notes say the 5.2 series is the last to support Python 3.10 and 3.11, so a 3.11 estate cannot take Django 6.x without the interpreter upgrade. Django 5.2 supports Python 3.14 from 5.2.8, so the interpreter can move first. Our Django 6.2 LTS upgrade guide covers the framework side.

The Scientific Python SPEC 0 policy, endorsed by NumPy, SciPy, matplotlib, scikit-image, networkx, xarray, IPython and zarr, recommends dropping a Python version three years after release: 3.11's window closed in October 2025, 3.12 is due to go in the fourth quarter of 2026 and 3.13 a year later. Those libraries can stop shipping 3.11 wheels long before CPython ends support, which is why data pipelines usually feel this deadline first.

What breaks between 3.11 and 3.13

Going from 3.11 to 3.13 crosses two releases of removals. The 3.12 and 3.13 What's New pages list them; these are the ones that break real services.

Removed in 3.12:

• distutils (PEP 632). Setuptools still provides it if installed, but old setup.py scripts and build helpers that import it from the standard library fail.

• asynchat, asyncore and imp, plus old unittest.TestCase aliases such as assertEquals.

• venv no longer pre-installs setuptools, so pkg_resources and easy_install vanish from fresh virtual environments.

• In the C API, PEP 623 removed wstr from Unicode objects, and the legacy Py_UNICODE APIs went too, breaking old extensions.

Removed in 3.13:

• The 19 PEP 594 modules: aifc, audioop, cgi, cgitb, chunk, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu and xdrlib. The usual surprises are cgi (form parsing in old WSGI code), crypt (password checks against shadow-style hashes), imghdr (upload validation) and telnetlib (network automation). Some have PyPI replacements, such as audioop-lts and standard-chunk.

• The 2to3 tool and lib2to3 module, tkinter.tix, locale.resetlocale(), and the typing.io and typing.re namespaces.

Behaviour changes in 3.13 worth testing:

• ssl.create_default_context() now sets VERIFY_X509_PARTIAL_CHAIN and VERIFY_X509_STRICT by default. Strict mode rejects certificates that break X.509 rules, most likely from old internal CAs and appliances.

• dbm.sqlite3 becomes the default dbm backend, which matters if anything reads shelve files written by an older interpreter.

• locals() has defined semantics when you mutate the returned mapping (PEP 667), which affects debuggers, profilers and code that writes to it.

Every 3.13 module removal above was deprecated in 3.11, so running your tests on 3.11 with deprecation warnings visible shows much of the list early.

What 3.14 adds on top

Going straight to 3.14 adds more.

• Deferred evaluation of annotations (PEP 649 and PEP 749). Annotations are no longer evaluated eagerly. Most code keeps working, but libraries that read __annotations__ at import time (older serialisers, dependency-injection frameworks, some ORMs) need annotationlib or a 3.14-ready release.

• A new process start default. On Unix platforms other than macOS, forkserver replaces fork as the default start method for ProcessPoolExecutor. Code that relies on children inheriting module-level state through fork must pass an explicit mp_context.

• Stricter asyncio. asyncio.get_event_loop() now raises RuntimeError when there is no current event loop instead of creating one; move such code to asyncio.run().

• Removals in argparse, ast (the old ast.Num, ast.Str and related classes), asyncio (the child watcher classes), email, importlib.abc, itertools (copy and pickle support), pathlib, pkgutil (find_loader and get_loader), pty, sqlite3 (version and version_info) and urllib (URLopener and FancyURLopener).

• No more PGP signatures. Under PEP 761, 3.14 and later releases carry no PGP signatures. Build pipelines that verify CPython source tarballs with GPG need to switch to Sigstore verification.

C API changes, wheels and native extensions

For most teams the hardest part of a Python upgrade is not their own code but every compiled dependency. CPython's ABI is stable only within a minor release, so each of cryptography, psycopg, numpy, lxml, grpcio and your own C or Rust extensions needs a cp313 or cp314 wheel, or a build toolchain in your image. Packages built for the Stable ABI (abi3) are the exception.

The C API kept moving too: 3.12 removed the legacy Py_UNICODE APIs, 3.13 added the Py_mod_gil slot for free-threading, and 3.14 finished the PEP 703 work, C API included. Pin build backends (setuptools, scikit-build-core, maturin, Cython) to versions that support your target, and run pip with --only-binary=:all: in CI to catch any package that would quietly fall back to a source build.

Free-threading and the JIT: what to do with them in 2027

Neither feature needs to be part of a 3.11 migration.

Free-threaded CPython. In 3.13 it was experimental: a separate python3.13t executable with a substantial single-threaded slowdown. In 3.14, PEP 779 made it officially supported, with a single-threaded penalty of roughly 5 to 10 percent, but it is still optional and not the default build. A C extension not marked as free-threading safe can switch the GIL back on when imported. A request-per-process web service gains little; CPU-bound threads in one process (batch transforms, inference pre-processing) are worth testing later, as a separate project.

The JIT. PEP 744 added an experimental JIT in 3.13, only in builds made with --enable-experimental-jit, and the release notes called the gains modest. In 3.14 the official Windows and macOS binaries include it, off unless you set PYTHON_JIT=1, with an effect the notes put between 10 percent slower and 20 percent faster. Linux servers and managed runtimes use their distributor's build, so benchmark the JIT later; it is not a reason to pick a version now.

Worked example: what each path buys

Take a team that finishes migrating on 1 May 2027, five months before 3.11's end of life. The end-of-support date for each path, by platform:

Dates are from python.org and the three runtime pages. On Lambda, 3.13 and 3.14 both give about 26 months from 1 May 2027 (to 30 June 2029). On Cloud Run, 3.13 gives about 29 months (to 10 October 2029) and 3.14 about 41 (to 10 October 2030). On Azure, as listed today, 3.13 outlasts 3.14 by six months. If you need one version everywhere, 3.14 is still the better default: its upstream and Cloud Run dates are a year later, and the Lambda and Azure dates are platform schedules that can be revised.

The grace periods are short: 62 days on Lambda between deprecation on 30 June 2027 and the update block on 31 August 2027, and 183 days on Cloud Run between deprecation and decommission. Neither window brings upstream security fixes after October 2027.

CI matrix and tooling

Run the targets alongside 3.11 before you switch production, then remove 3.11 when the last service moves. A minimal GitHub Actions matrix, using v7 of the official checkout and setup-python actions, current on 7 November 2026:

            # .github/workflows/test.yml (excerpt)
strategy:
  fail-fast: false
  matrix:
    python-version: ["3.11", "3.13", "3.14"]
steps:
  - uses: actions/checkout@v7
  - uses: actions/setup-python@v7
    with:
      python-version: ${{ matrix.python-version }}
  - run: python -m pip install --only-binary=:all: -r requirements-test.txt
  - run: python -m pip install --no-deps -e .
  - run: python -X dev -m pytest
          

Four habits make the matrix useful:

1. Pin runner images. Floating labels such as ubuntu-latest move to newer Ubuntu releases with a newer system Python. Pin the runner and install the interpreter explicitly.

1. Make your own deprecations fatal, not everyone's. Add an error::DeprecationWarning entry to pytest's filterwarnings setting with your package as the module, so third-party warnings do not block the build.

1. Add a free-threaded job only if you ship C extensions. It tells you whether your extension declares free-threading support.

1. Move the floor when you cut over. Set requires-python to >=3.13 (or >=3.14) in pyproject.toml, update trove classifiers, and point linters at the new target (for example Ruff's target-version).

Compliance, India and data protection

Section 8(5) of India's Digital Personal Data Protection Act 2023 requires a Data Fiduciary to protect the personal data it holds, including data a processor handles for it, through reasonable security safeguards to prevent breaches; failing to do so can cost up to ₹250 crore. Section 8 comes into force on or about 13 May 2027, eighteen months after the 13 November 2025 notification and five months before 3.11's end of life. In our view, running an interpreter that no longer gets security fixes, when a supported version with the fix exists, is hard to defend under that standard. Our DPDP Rules checklist covers the wider controls, and our Node.js 22 end of life guide applies the same reasoning to the JavaScript side.

The upgrade runbook

1. Inventory every interpreter. Lambda functions in every region, Azure function apps, Cloud Run functions and services, container and CI images, Airflow or Dagster workers, notebooks and laptops. Record each version and its platform end date.

1. Pick a target per platform from the tables above, with its end date.

1. Audit dependencies first. Check wheels for every native package and framework support (Django, FastAPI, Celery, Airflow). This sets the calendar.

1. Fix removals on 3.11. Replace distutils, imp, cgi, crypt, imghdr, telnetlib and the rest, guided by deprecation warnings.

1. Run the suite on the target in CI, with TLS tests against real internal endpoints to catch strict X.509 checks.

1. Rebuild images on the target base image, including Lambda container images, which get no deprecation emails.

1. Roll out by blast radius, using Lambda versions and aliases or Cloud Run traffic splitting for rollback.

1. Remove 3.11 from CI and base images once the last service moves.

The platform commands are short. Run them per function after tests pass:

            # AWS Lambda: list python3.11 functions in the current region, then move one
aws lambda list-functions --query "Functions[?Runtime=='python3.11'].FunctionName" --output text
aws lambda update-function-configuration --function-name my-fn --runtime python3.13

# Azure Functions on a Linux Elastic Premium or Dedicated plan
# (confirm the value with: az functionapp list-runtimes --os linux)
az functionapp config set --name my-app --resource-group my-rg --linux-fx-version "Python|3.13"

# Cloud Run functions (keep your existing trigger and region flags)
gcloud functions deploy my-fn --runtime python313 --source .

# Confirm the interpreter, and the GIL state on a free-threaded build
python -VV
python -c "import sys; print(sys._is_gil_enabled())"
          

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our application modernisation and framework upgrade service plans and runs Python runtime upgrades across Lambda, Azure Functions, Cloud Run and container estates, from interpreter inventory and wheel audits to staged rollout. Talk to us at /contact-us/.

Last updated: 7 November 2026.

References

1. Status of Python versions — Python Developer's Guide

1. Download Python: active Python releases — Python Software Foundation

1. PEP 664: Python 3.11 release schedule — Python Software Foundation

1. Lambda Event Function runtimes — Amazon Web Services

1. Supported languages in Azure Functions, last updated 22 October 2026 — Microsoft Learn

1. Runtime support, Cloud Run functions, last updated 2 November 2026 — Google Cloud

1. What's New in Python 3.12 — Python Software Foundation

1. What's New in Python 3.13 — Python Software Foundation

1. Versioning policy — PostgreSQL Global Development Group

1. PEP 602: Annual release cycle for Python — Python Software Foundation

1. PEP 619: Python 3.10 release schedule — Python Software Foundation

1. PEP 693: Python 3.12 release schedule — Python Software Foundation

1. PEP 719: Python 3.13 release schedule — Python Software Foundation

1. PEP 745: Python 3.14 release schedule — Python Software Foundation

1. PEP 790: Python 3.15 release schedule — Python Software Foundation

1. Update language versions in Azure Functions — Microsoft Learn

1. Azure Functions Consumption plan hosting (legacy) — Microsoft Learn

1. Migrate Consumption plan apps to Flex Consumption in Azure Functions — Microsoft Learn

1. Python developer reference for Azure Functions — Microsoft Learn

1. Cloud Run runtime lifecycle, last updated 2 November 2026 — Google Cloud

1. Django 6.0 release notes, 3 December 2025 — Django Software Foundation

1. FAQ: Installation, What Python version can I use with Django — Django Software Foundation

1. SPEC 0: Minimum supported dependencies — Scientific Python

1. What's new in Python 3.14 — Python Software Foundation

1. C API and ABI stability — Python Software Foundation

1. Python support for free threading — Python Software Foundation

1. Releases of actions/checkout — GitHub

1. Releases of actions/setup-python — GitHub

1. The Digital Personal Data Protection Act, 2023 (No. 22 of 2023), Gazette of India, 11 August 2023 — Ministry of Electronics and Information Technology

1. Notification G.S.R. 843(E), commencement of the DPDP Act, 13 November 2025 — Ministry of Electronics and Information Technology