Execute the Python 3.9 retirement playbook

Guide structure and deliverables

• Inventory scoping. Establish authoritative runtime inventories, dependency maps, and ownership models to quantify Python 3.9 risk exposure.
• Dependency remediation. Prioritise upgrades across frameworks, data science stacks, and build tooling that have already dropped Python 3.9 testing.
• CI validation. Harden automation so every modernization change captures reproducible evidence aligned with SSDF and Zeph Tech controls.
• Runtime certification. Document vendor support, managed service availability, and internal approval gates for the target Python versions.
• Observability benchmarks. Baseline performance, memory, and telemetry coverage to measure modernization benefits and detect regressions.

Inventory scoping and governance

Create a single modernization backlog before touching code. Combine CMDB data, container registries, serverless manifests, and dependency files (requirements.txt, poetry.lock, Pipfile.lock) to enumerate Python versions in use. Tag each workload with owner, deployment target, and compliance boundary so remediation can be sequenced by risk.

Use the externally-managed environment guidance in PEP 668 to separate system Python packages from application environments, preventing in-place upgrades that conflict with distribution package managers.^PEP 668 Mandate the use of venv or virtualenv for application stacks and capture environment metadata in source control, referencing the Python standard library guidance on virtual environments.^{venv documentation}

Surface modernization status through a tiered dashboard: Tier 0 business-critical services, Tier 1 shared platforms, and Tier 2 internal tooling. Flag blockers such as unsupported operating systems, embedded Python runtimes, or vendor software that bundles 3.9. Incorporate Zeph Tech’s nightly briefings to update the backlog when new frameworks or managed services publish deprecation notices.

Deliverable: modernization register detailing assets, runtime versions, owners, criticality, and target upgrade releases with expected completion windows.

Dependency remediation program

Prioritise dependencies that have already raised their minimum supported Python version. Django 4.2 is the last LTS release with Python 3.9 support; future security fixes require Python 3.10+, so web applications must uplift both the framework and the interpreter simultaneously.^{Django Python support} Apply the same scrutiny to pandas, NumPy, FastAPI, and other critical libraries by tracking their release notes and wheel metadata.

Break remediation into waves: platform libraries (frameworks, ORMs), data & analytics packages, build-time dependencies (setuptools, wheel), and operational tooling (Linters, monitoring SDKs). For each wave, publish compatibility matrices showing the tested Python versions, required dependency pins, and test suite status. Retire Python 3.9-specific workarounds (e.g., importlib metadata shims) to reduce maintenance drag.

Verify binary availability for your target environments—AMD64, ARM64, GPU-enabled containers—especially for data science workloads that rely on compiled extensions. Align package builds with the Debian and Ubuntu archives supplying Python 3.11/3.12 base images to avoid mixing glibc versions or unsupported manylinux tags.^{Debian bookworm python3 package}

Deliverable: dependency remediation plan listing every modernization wave, required library upgrades, owner, and scheduled completion date, accompanied by automated dependency update pull requests.

CI validation and automation

Expand continuous integration pipelines to test against both the new target Python versions and legacy 3.9 branches until cutover is complete. Introduce matrix builds that exercise unit, integration, and contract tests on Python 3.11 and 3.12, logging parity metrics and failure deltas. Embed rollout criteria—code coverage thresholds, performance guardrails, and dependency audit reports—into pipeline gates.

Integrate runtime detection scripts that fail builds when python --version outputs 3.9.x or when Dockerfiles reference deprecated base images. Capture evidence bundles (test logs, SBOMs, provenance attestations) for every modernization branch so compliance teams can attest to SSDF practices without re-running pipelines.^PEP 596

Stage canary deployments using feature flags or blue/green routing to validate application behaviour on the new interpreter before full promotion. Document rollback conditions, regression monitoring, and approval checkpoints in change management systems so audit sampling shows controlled cutovers.

Deliverable: updated CI/CD workflows enforcing interpreter version checks, producing modernization evidence bundles, and tracking canary promotion results.

Runtime certification and vendor alignment

Compile vendor attestations that confirm Python 3.11/3.12 availability across infrastructure: container base images, managed Kubernetes runtimes, AWS Lambda, Azure Functions, and Google Cloud Run. Use AWS Lambda’s runtime deprecation schedule to document when Python 3.9 functions must be rebuilt and redeployed, and record the testing evidence required by each cloud provider.^{AWS Lambda runtimes}

For on-premises or self-managed environments, certify operating system support by referencing distribution package repositories. Debian bookworm’s default python3 package demonstrates that long-term support distributions are already delivering Python 3.11 binaries, enabling direct adoption without third-party PPAs.^{Debian bookworm python3 package} Capture installer versions, checksum details, and validation steps within a certification dossier.

Coordinate with governance teams to update technology standards, secure coding policies, and vendor questionnaires to state that Python 3.9 is unsupported after October 2025. Provide customer-facing communications that reference upstream policy to pre-empt security reviews and procurement escalations.^{Python release status}

Deliverable: runtime certification package covering cloud runtimes, operating systems, installer artifacts, policy updates, and customer communications.

Observability benchmarks and performance baselining

Quantify modernization wins by benchmarking CPU, memory, startup time, and request latency on both Python 3.9 and the target release. Use the official pyperformance suite to run standardized micro-benchmarks and document percentage improvements or regressions for leadership and customer communications.^{pyperformance}

Instrument applications with Python’s built-in tracemalloc and logging frameworks to monitor memory allocation differences, GC pressure, and logging format changes introduced by the new interpreter.^{tracemalloc documentation} Feed metrics into your APM platform and compare against pre-upgrade baselines to confirm there are no regressions in throughput or error rates.

Update runbooks to include modernization observability checks: verifying OpenTelemetry exporters, ensuring metrics labels remain stable, and flagging long-running workers that still report Python 3.9. Automate dashboards and alerts so runtime drift triggers immediate remediation tickets.

Deliverable: observability benchmark report summarizing pre- and post-upgrade performance, telemetry deltas, and ongoing monitoring rules.

Roadmap and sustaining cadence

Set a modernization cadence that mirrors Python’s annual feature releases. Adopt a policy that freezes interpreter upgrades no later than six months after general availability so teams avoid multi-version leaps. Tie cadence reviews to Zeph Tech’s developer briefings and Python release schedules so the modernization register stays current.

Close the program with a retrospective documenting metrics (percentage of services upgraded, vulnerabilities mitigated, performance gains) and residual exceptions. Require executive approval for any workloads requesting extended use of Python 3.9 and set review checkpoints aligned with AWS Lambda’s deprecation enforcement and third-party support contracts.