Teams on an end-of-life Python
Applications still running on a Python version that no longer receives fixes.
Python Consulting
Python consulting for upgrades and architecture
Python codebases age quietly: an end-of-life interpreter, a requirements file nobody trusts, no type checks and a worker setup tuned years ago. Agnotic Technologies upgrades Python applications to supported versions, modernizes packaging and typing, and fixes concurrency and service structure, with tests guarding each step.
Off end-of-life versionspyproject.toml and lock filesGradual typingConcurrency that fits the workload
Trusted by global innovators
Python consulting
What does Python consulting cover?
Python consulting is senior engineering help for teams whose Python applications have become slow, fragile or hard to upgrade. Agnotic Technologies reviews the codebase, moves it off end-of-life Python versions, sets up pyproject.toml packaging with lock files, adds type checking gradually and chooses the right concurrency model for each workload.
Our engineers do the work with your team instead of only writing a report. Hiring individual Python developers is a separate service on our Python developers page.
Building and training machine learning models sits with our ML development services. Here we look after the application code around them: APIs, workers, pipelines and packaging.
Python standards
Which Python standards does a modern codebase follow?
The Python Enhancement Proposals we apply most on upgrade work, and what each changes in your repository.
| Code | Name | Typical use |
|---|---|---|
| PEP 621 | Project metadata in pyproject.toml | One [project] table replaces setup.py metadata, so every build tool reads the same name, version and dependencies |
| PEP 751 | Standard lock file (pylock.toml) | Records the exact dependency versions to install, so CI and production build the same environment |
| PEP 484 | Type hints | Annotations that mypy or pyright check in CI, added first to the modules that change most |
| PEP 703 | Making the GIL optional in CPython | A free-threaded build in which threads can run Python code in parallel on several cores |
| PEP 779 | Supported status for free-threaded Python | Made the free-threaded build officially supported but optional, from Python 3.14 |
| PEP 8 | Style guide for Python code | Formatting and naming enforced by a formatter and linter, so reviews focus on behavior |
Decision table
Which concurrency approach fits each Python workload?
Our starting point for each workload type. Profiling decides the final answer.
| Workload type | Approach we usually choose | What to measure first |
|---|---|---|
| I/O-bound API with many requests waiting on databases or other services | asyncio with an async framework such as FastAPI, or threads in a synchronous framework | Time spent waiting on I/O per request, connection pool use |
| CPU-bound batch job, such as report generation or file processing | Several processes, or the free-threaded build once your libraries support it | CPU per core, time per item, memory per worker |
| Data pipeline over large files or tables | Vectorized libraries and chunked processing, with processes for parallel stages | Rows per second per stage, memory peak, time in Python versus native code |
| ML inference service | A process per model worker, with request batching where latency allows | Latency percentiles, model load time, memory per worker |
| Background jobs and queues | A task queue with worker processes sized to the job mix | Queue depth, job duration, retry counts |
Measure before changing the model. A profile often shows the time goes to a slow query or a serial loop, not to Python's concurrency limits.
Who it is for
Which teams ask for Python consulting?
Teams with Python in production and a problem they cannot schedule around.
Data teams with slow pipelines
Batch and ETL code that takes longer every month as data grows.
API teams with latency problems
Django or FastAPI services that slow down under load or block on I/O.
Companies inheriting a Python codebase
Teams taking over code from a vendor or an acquired company.
ML teams with lagging serving code
Models that moved on while the serving, packaging and deployment code stayed behind.
Upgrade path
How do we upgrade an application off an end-of-life Python version?
Five steps that keep the application releasable the whole way through.
Audit versions and dependencies
We list the interpreter, every direct and indirect dependency and the newest version of each that supports your target Python.
Add tests where they are thin
Characterization tests capture current behavior on the paths the upgrade touches, before anything changes.
Move packaging and lock dependencies
Metadata moves to pyproject.toml and dependencies are locked, so the upgrade changes one thing at a time.
Upgrade in steps
We step through Python versions and major dependency versions, fixing deprecations at each step with the test suite green.
Run both, then switch
CI builds on the old and new versions until the new one has run in production without regressions.
Failure points
What usually breaks during a Python upgrade?
Problems we plan for on every upgrade, and how we handle them.
Challenge
A pinned dependency has no release for the new Python version.
Agnotic approach
We find a maintained replacement or fork, or isolate the dependency behind an interface so it can be swapped later.
Challenge
Deprecation warnings were ignored for years and are now errors.
Agnotic approach
Warnings become test failures one module at a time, so they are fixed in a planned order.
Challenge
Builds differ between laptops, CI and production.
Agnotic approach
One lock file drives every environment, and the container image is built from it.
Challenge
Type checking the whole codebase at once produces thousands of errors.
Agnotic approach
Strict checking starts on new and changed modules and widens release by release.
Challenge
An async rewrite made the service slower.
Agnotic approach
One blocking call in an async path stalls every request; we find these by profiling and move them to threads or processes.
Tools and frameworks
Which Python tools and frameworks do we work with?
The tools we use most on Python upgrade and architecture work.
CPythonmypy and pyrightpytestDjangoFastAPICelery
Facts and sources
What do the Python release and PEP documents say?
Version status and standards behind this page, each linked to its primary source.
Python 3.10 reached end of life on 1 October 2026, and Python 3.11 now accepts security fixes only until its scheduled end of life in October 2027.
Source: Python Developer's Guide: status of Python versionsPEP 621 specifies how a project's core metadata is written in pyproject.toml, so packaging tools and build back ends read it in one tool-agnostic way.
Source: PEP 621 (peps.python.org)PEP 751 defines a standard lock file format, pylock.toml, that records the direct and indirect dependencies to install, so installers can reproduce an environment without resolving dependencies at install time.
Source: PEP 751 (peps.python.org)PEP 484 introduced the standard vocabulary for type hints and states that Python will remain a dynamically typed language, with no wish to make type hints mandatory, even by convention.
Source: PEP 484 (peps.python.org)PEP 779, accepted in June 2025 for Python 3.14, sets the criteria for phase II of free-threaded Python, in which the build without the global interpreter lock is officially supported but still optional.
Source: PEP 779 (peps.python.org)
Scope and cost
What drives the cost of Python consulting?
We price Python work after looking at the code. These factors move the estimate most.
Codebase size and age
How much code there is and how far the current Python version is from a supported one.
Test coverage
Whether tests already guard the paths an upgrade touches, or need writing first.
Dependency health
How many dependencies are unmaintained, pinned to old versions or lack support for newer Python.
Services and deploy targets
How many applications, workers and environments share the codebase.
Framework upgrades
Major Django, FastAPI or Celery versions that move with the interpreter.
Who does the work
Our engineers, your team guided by us, or both working together.
Frequently Asked Questions
We do not publish prices. Cost depends on codebase size and age, test coverage, dependency health, the number of services and any framework upgrades. We send a written proposal once we have seen the code on the scoping call.
Usually the newest release your key dependencies support, so the next forced upgrade is as far away as possible. We check the Python developer guide's status table and each dependency's support before choosing.
No. Type hints stay optional in Python. We add them where they pay back most, such as public interfaces, data models and modules that change often, and run the checker in CI on those first.
Only for CPU-bound code that uses threads, and only once every extension module you rely on supports it. We try it on a branch with your real workload before any decision.
Yes. We look at app boundaries, settings per environment, database access, background work and how the project is packaged and deployed, then fix the parts that slow your team down.
Python consulting for startups is usually short: a review of the first production codebase, packaging and CI set up properly, and a few structural fixes before the team grows around the wrong patterns.
Yes, through our Python developers service. Consulting is for a defined outcome, such as an upgrade or a structure review; hiring is for adding people to your team.