Python development company: 6 checks before the 31 October 2026 cutoff

Summary. Python 3.10 reaches end of life in October 2026, which is roughly 10 weeks away, and it is already in security-only status with no new binaries. The AWS Lambda python3.10 runtime carries a deprecation date of 31 October 2026, after which Lambda blocks new function creation from 1 February 2027 and blocks updates to existing functions from 3 March 2027. Amazon Linux 2, which both the python3.10 and python3.11 Lambda runtimes are built on, reached end of life on 30 June 2026. Django 6.0, released 3 December 2025, supports only Python 3.12, 3.13 and 3.14. Python 3.15.0 is scheduled for 1 October 2026 and its Lambda runtime is targeted for November 2026. Meanwhile free-threaded Python became officially supported in 3.14 under PEP 779, at a cost of roughly 10% single-threaded performance and 15-20% higher memory use. A Lambda function invoked a million times costs $0.20 in request charges, so none of this is about compute spend. It is about whether your code can still be deployed in March 2027.

Most guides to hiring a Python development company compare framework familiarity. That is table stakes. The six checks below are about migration competence, which is what actually determines whether your team spends the next two quarters shipping features or chasing runtime deadlines.

Check 1: do they know which Python versions are actually supported?

The Python Software Foundation publishes version status on the Python Developer's Guide, and the picture surprises most teams. Only two versions still receive binary bugfix releases.

The status column matters more than the end-of-life column. Under the phases defined in PEP 602, a version in security status accepts only security fixes, and, in the developer guide's own words, "no more binaries are released. New source-only versions can be released as needed." Python 3.12 has already crossed that line. If your team believes 3.12 is a safe long-term target because its end of life is 2028, they are planning around a version that no longer ships binaries.

A partner should be able to tell you, without looking it up, that 3.13 and 3.14 are the only versions in bugfix status today.

Check 2: have they mapped your cloud runtime deadlines?

Language end of life is the upstream event. The deadline that actually stops your deployment is your cloud provider's. AWS publishes both, and the Lambda runtimes table is unambiguous.

Three details in that table are easy to miss and expensive to discover late.

First, python3.10 and python3.11 both run on Amazon Linux 2, which AWS states was scheduled for end of life on 30 June 2026. AWS confirms those runtimes continue receiving patches for critical and selected important Amazon Linux 2 security issues until their listed deprecation dates, but the underlying OS is already out of support. AWS recommends upgrading to an Amazon Linux 2023-based runtime as soon as possible.

Second, deprecation does not stop your functions running. AWS is explicit that you can continue to invoke functions indefinitely, but security patches stop, technical support ends, and the runtime is provided as-is. The hard wall is 3 March 2027, when Lambda blocks updates to python3.10 function code and configuration. After that you can still upgrade to a supported runtime, but rolling back may be blocked.

Third, the gap between deprecation and blocking is unusually generous here. AWS's standard policy is 30 days to block creates and 60 days to block updates, but python3.10 gets 93 and 123 days respectively, which AWS attributes to customer feedback. Do not read that as slack. It is 2026 breathing room that disappears in 2027.

Python 3.15 is in public preview on Lambda now, and AWS states preview runtimes are not covered by the Lambda SLA or technical support and should not be used for production workloads. The general availability target is November 2026, a month after the 1 October 2026 language release, because Lambda only ships managed runtimes once a release reaches long-term support.

Check 3: can they explain what free-threaded Python costs you?

Free-threaded Python is the single largest change to the runtime in a decade, and it is now officially supported rather than experimental. PEP 779, authored by Thomas Wouters, Matt Page and Sam Gross, reached Final status with a Steering Council resolution on 16 June 2025 and moved the free-threaded build to Phase II in Python 3.14.

Officially supported is not the same as default. The PEP is direct about the trade-off, measured with the pyperformance benchmark suite:

Thomas Wouters, CPython release manager for Python 3.12 and 3.13 and a co-author of PEP 779, sets the expectation plainly: free-threaded Python is not a drop-in solution, and "some code will have to be redesigned to make the most of the new capability, as well as avoid performance pitfalls."

The commercial translation is straightforward. If your workload is a request-per-thread web service that already scales horizontally, adopting the free-threaded build today buys you a 10% single-threaded penalty and 15-20% more memory for no gain. If you run CPU-bound in-process parallelism that currently fights the GIL, it can be transformative. A partner who recommends free-threaded Python without asking which of those you are is guessing. We covered the upgrade mechanics in our note on the Python 3.15 upgrade, free-threaded ABI, lazy imports and JIT.

Check 4: does your framework floor match your runtime ceiling?

This is where migrations stall. Django 6.0 was released on 3 December 2025 and supports Python 3.12, 3.13 and 3.14. It does not support 3.10 or 3.11.

That produces a specific trap for teams on AWS. If you are running Django on python3.11, your Lambda runtime is supported until 30 June 2027, but your framework upgrade path is already blocked: you cannot move to Django 6.0 without first moving Python. Teams routinely plan the framework upgrade and the runtime upgrade as separate projects in separate quarters, then discover they are one project.

Django 6.0 also brings changes worth scoping properly rather than absorbing accidentally, including template partials for named template fragments, a built-in background tasks framework for work outside the request-response cycle, Content Security Policy configuration, and a modernised email API built on Python's EmailMessage.

Ask a prospective partner to draw your dependency floor: the highest Python version your libraries permit, and the lowest your framework requires. If those two numbers do not overlap, that gap is the project.

Check 5: how do they handle the migration itself?

A credible Python migration is not a version bump in a Dockerfile. The sequence we use is:

1. Inventory. Every service, Lambda function, container base image, CI runner and scheduled job, with its current Python version and runtime identifier. AWS's Trusted Advisor deprecated-runtimes check and the Health Dashboard list affected functions, and AWS sends email notifications at least 180 days before a runtime is deprecated to the account's primary contact.

1. Dependency audit. Which pinned libraries have wheels for the target version, and which are unmaintained. This is where the calendar is really set.

1. Staged upgrade. Move to the highest version your dependencies allow, run the test suite under the new interpreter, then move the runtime.

1. Runtime cutover. Use Lambda function versions and aliases so you can deploy safely with rollback, which AWS recommends explicitly because reverting after updates are blocked is not possible.

1. Verification. Load-test the changed paths rather than assuming parity.

The step teams skip is the second one, and it is the only one that reliably surfaces the six-month problems.

Check 6: security posture and compliance

Python 3.9 stopped receiving security fixes on 31 October 2025. Anything still running it has been unpatched for nine months. The Lambda python3.9 runtime was deprecated on 15 December 2025, and although AWS will not block updates to those functions until 3 March 2027, they receive no security patches in the interim.

The Python Software Foundation runs a Python Security Response Team and publishes a software bill of materials for CPython releases, which is the artefact your compliance team will ask for. A partner should be producing an equivalent SBOM for your application dependencies, not just the interpreter.

India-specific considerations

For Indian businesses, the Digital Personal Data Protection Act 2023 applies to the personal data your Python services process, and the practical questions are where data is stored, how consent is recorded and how deletion requests propagate through queues, caches and analytics pipelines. Django's background tasks framework, new in 6.0, makes it easier to move that work off the request path, but it also creates another place where personal data comes to rest. Map it at design time. eCorpIT designs applications aligned with DPDP requirements and holds ISO 27001:2022 certification for its own information security management.

Cost discipline matters differently in rupee-denominated budgets. AWS Lambda charges $0.20 per 1 million requests in US East (Ohio) as published on the AWS Lambda pricing page, with a monthly free tier of 1 million requests and 400,000 GB-seconds. At that unit price the migration decision is never about invocation cost. It is about the engineering time that a blocked deployment in March 2027 would consume.

What we build, and how

eCorpIT builds and maintains Python systems for teams that treat the interpreter version as production infrastructure. The work covers Django and FastAPI web services, data and ETL pipelines, AWS Lambda and container workloads, and the migrations that keep them deployable.

Our delivery sequence is the five steps in Check 5, run as a fixed-scope audit and migration plan first, then either a fixed-scope migration or a retained senior engineering team for continuous work. We quote the migration after the dependency audit, not before, because the pinned-library inventory is what determines the effort and it cannot be estimated from outside.

eCorpIT is a Gurugram-based technology company founded in 2021, assessed at CMMI Level 5, MSME certified and ISO 27001:2022 certified, working with AWS, Microsoft and Google as technology partners. Teams are senior-led and multi-disciplinary. Related work is described on our pages for custom software development, SaaS development and software development in India.

FAQ

How eCorpIT can help

We inventory every Python service, Lambda function and container image you run, produce a dependency audit that shows which pinned libraries block your target version, and give you a costed migration plan with dates mapped against the AWS deprecation calendar. For teams already committed, we run the migration itself, including framework upgrades and the load testing that confirms parity. eCorpIT is CMMI Level 5 assessed and ISO 27001:2022 certified, and designs applications aligned with DPDP requirements. Tell us what you are running at /contact-us/ and we will start with the inventory.

References

1. Status of Python versions — Python Developer's Guide, last updated 27 May 2026.

1. PEP 790: Python 3.15 release schedule — Hugo van Kemenade, last modified 5 August 2026.

1. PEP 779: Criteria for supported status for free-threaded Python — Thomas Wouters, Matt Page and Sam Gross, resolution 16 June 2025.

1. PEP 703: Making the Global Interpreter Lock optional in CPython — Python Enhancement Proposals.

1. PEP 602: Annual release cycle for Python — Python Enhancement Proposals.

1. Lambda runtimes — AWS Lambda Developer Guide, August 2026.

1. Retrieve data about Lambda functions that use a deprecated runtime — AWS Lambda Developer Guide.

1. Understanding how Lambda manages runtime version updates — AWS Lambda Developer Guide.

1. AWS Lambda pricing — Amazon Web Services, August 2026.

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

1. Django 6.0 released — Django Weblog, 3 December 2025.

1. PEP 619: Python 3.10 release schedule — Python Enhancement Proposals.

1. Software bill-of-materials — Python Developer's Guide.

1. Python Security Response Team — Python Developer's Guide.

Last updated: 16 August 2026.