Python 3.10 Hit End of Life in October. Are Your Data Jobs Still on It?

Python 3.10 is past its last release

Python 3.10 came out in October 2021. For a couple of years it was the safe default, so a lot of small data jobs were built on it. Think of the nightly script that pulls orders out of the ERP and loads them into SQL Server. Or the cloud function that picks up a vendor CSV every morning. Or the notebook somebody scheduled and then forgot about.

The Python developer guide lists the end of life for 3.10 as October 1, 2026. At that point the guide says the release cycle is frozen and no further changes are allowed. In plain terms, no more security fixes from the people who make Python. The code keeps running exactly as before. That is why it is easy to miss.

The cloud platforms have their own dates

AWS lists python3.10 on its Lambda runtimes page with a deprecation date of October 31, 2026. Creating new functions on it gets blocked on July 29, 2027. Updating existing functions gets blocked on August 31, 2027. AWS says that after a runtime is deprecated it may no longer apply security patches or updates, and functions using it are no longer eligible for technical support.

Google lists python310 for Cloud Run functions with a deprecation date of October 4, 2026 and a decommission date of April 4, 2027. After decommission, Google says you can no longer create new workloads or update existing ones on that runtime, and workloads that keep using it may be disabled. Google sends notices 90 days before deprecation, which means those emails may already have gone to an inbox nobody reads.

The data libraries already moved on

Most data scripts lean on numpy, pandas or scipy. Those projects stopped supporting 3.10 a while ago. PyPI shows numpy 2.3.0, released in June 2025, requires Python 3.11 or newer. Scipy 1.16.0 from the same month has the same floor. Pandas 3.0.0, released in January 2026, requires 3.11 as well. The newest numpy and scipy releases now require 3.12.

When you run pip on Python 3.10, it quietly installs the last version that still supports 3.10. Nothing errors out. You just end up frozen on older library versions that are not getting fixes either. Over time that gap grows, and the upgrade gets bigger the longer you wait.

Where Python 3.10 hides in an Oklahoma company

It is rarely one big system. It is a dozen small jobs that belong to different people. These are the places to look.

1. 1AWS Lambda functions and Google Cloud Run functions set to the 3.10 runtime.
2. 2Docker images built on the official Python 3.10 image.
3. 3Scheduled tasks on a Windows server with a 3.10 install from a few years ago.
4. 4Cron jobs and Airflow tasks on Linux servers.
5. 5Build pipelines in GitHub or Azure DevOps that pin 3.10.
6. 6Notebooks and scripts on one analyst's laptop that feed a monthly report.

One case is different. Ubuntu 22.04 ships Python 3.10 as its system Python, and Canonical keeps patching its own packages under standard security maintenance until May 2027. That covers the Python that came with the server. It does not cover libraries you installed with pip, and it does not help a container or a cloud function.

Why this one slips through

Nobody gets an error message. The job that loads payroll data still finishes at 2 in the morning. The person who wrote it may have left the company. The cloud account email may go to a shared inbox. So the first sign of trouble is often a failed deploy on the day you need a quick fix, or a security review that flags an unsupported runtime.

Quick ways to find it

Start in the cloud consoles. The function list in AWS Lambda and in Google Cloud shows the runtime for each function, so you can sort by it and see the 3.10 ones in a few minutes. Check every region and every project, because old test accounts tend to hold the forgotten ones.

On servers, ask whoever runs them to check the Python version on each machine and list the scheduled tasks that call it. In code, search your repositories for 3.10 in Dockerfiles, build files and requirement files. Then talk to the analysts. The scripts on their laptops often feed reports that leadership reads every week, and nobody in IT knows they exist.

Keep the list simple. A shared spreadsheet with the job name, owner, where it runs, Python version, libraries and the date it last ran is enough. That list becomes the plan, and it also tells you which jobs nobody uses anymore. Those can be turned off instead of upgraded.

Which version to move to

Python 3.11 reaches end of life in October 2027, and AWS deprecates the python3.11 Lambda runtime on June 30, 2027. Moving there buys months, not years. Python 3.12 is supported until October 2028 and 3.13 until October 2029. On Lambda, python3.12 runs on Amazon Linux 2023 instead of Amazon Linux 2, so any packages with compiled code need to be rebuilt. For most data jobs we would pick 3.12 or 3.13 and do the work once. Most simple scripts move with few changes. The time goes into testing and into the one or two jobs that pinned an old library years ago.

A plan for the next 90 days

1. 1Make a list of every Python job, function and container. Note the owner, where it runs and the Python version.
2. 2Start with cloud functions, since Google stops updates in April 2027 and AWS in August 2027.
3. 3Write down the libraries each job uses and the versions it has pinned.
4. 4Build a copy of each job on Python 3.12 or 3.13 and run it against a day of real input in a test area.
5. 5Compare the output row by row with the old job before you switch.
6. 6Rebuild any package with compiled code for the new runtime.
7. 7Switch one job at a time and keep the old one ready to roll back for a week.
8. 8Put the next end of life date for each job on a shared calendar so this does not surprise you again.

What this means if you run a company in Oklahoma

Plenty of Oklahoma businesses run on small Python jobs that nobody thinks about until they break. A manufacturer in Tulsa, an energy firm in Oklahoma City or a clinic group in Norman can each have a handful of these jobs keeping reports and loads alive. Python 3.10 reaching end of life is a good reason to find them all, give each one an owner and move them before the cloud dates arrive.

At Oklahoma Data Partners, we work only with data and only in Oklahoma. We help companies list their data jobs, move them to a supported Python version and test the results before anything goes live. If you want help finding what still runs on 3.10, book a consultation.