Hire a senior Django developer for the hard parts

Python 3.9 end of life and the Django LTS cadence

Python 3.9 reached end of life in October 2025. No more security fixes, and new releases of the libraries you depend on are dropping it. Python 3.10 followed in October 2026. If your app or its base Docker image is still on 3.10 or older, that’s the first thing to fix.

Django has a predictable rhythm: a feature release roughly every eight months, and every x.2 release is a long-term support (LTS) version with about three years of security fixes. Django 4.2 LTS left support in April 2026; 5.2 is the current LTS. For exact dates, check the official supported versions table on djangoproject.com.

My advice for most SaaS teams: move from LTS to LTS, and plan the next hop as soon as you land. Each Django release also sets a minimum Python version – Django 5.x needs Python 3.10 or newer (and 3.10 is itself now end of life), while Django 6.x needs 3.12 or newer – so the two upgrades have to be sequenced together.

How I run a Django upgrade

1. Pin and audit dependencies. Every package in requirements or pyproject, checked against the target Django and Python versions. Abandoned packages – often an old admin theme or REST helper – are replaced first.
2. Turn warnings into errors. Run the test suite with python -W error::DeprecationWarning on the current version and fix what fails. Django deprecates for two releases before removing, so the warnings are a complete to-do list.
3. Automate the mechanical changes. django-upgrade and pyupgrade rewrite old URL patterns, removed imports and outdated syntax in one reviewable commit.
4. Upgrade Python, then Django. CI runs both the old and new combinations in a matrix until production moves.
5. Check migrations. makemigrations --check catches model state drift; large data migrations get split out so they don’t lock tables during deploy.
6. Roll out to a canary first. One instance on the new version, error rates and latency compared, then the rest.

Django and Postgres performance

Django apps get slow in predictable ways. The ORM makes it easy to write a loop that issues a thousand queries without noticing.

• N+1 queries. django-debug-toolbar in development and assertNumQueries in tests; select_related for foreign keys and prefetch_related for reverse and many-to-many relations.
• Fetching too much. only(), values() and iterator() for large querysets; annotate and aggregate in the database instead of summing in Python.
• Missing or wrong indexes. pg_stat_statements to find the expensive queries, EXPLAIN ANALYZE to see why, then composite or partial indexes declared in Meta.indexes. More in PostgreSQL performance tuning.
• Connection churn. CONN_MAX_AGE or Django’s built-in connection pooling for Postgres, or PgBouncer in transaction mode when you run many workers.
• Synchronous side effects. Emails, webhooks and PDF rendering moved to Celery or another task queue, with idempotent tasks and retries.

Architecture choices I’ll push on

Keep it a monolith for longer than feels comfortable – Django’s app structure already gives you a decent way to separate domains. Put business logic in plain service functions rather than in save() overrides and signals, which become invisible coupling. Treat payments and money movement as their own, heavily tested module; I’ve written about why in payment system architecture.

Choosing between frameworks for a new product? I’ve compared them honestly in Rails vs Django.

When a Django consultant isn’t what you need

If your app is healthy and you need feature capacity, hire a solid mid-level Django developer – cheaper, and the right fit. Bring in a Django consultant when the risk is high or the team is stuck: an upgrade that keeps slipping, performance you can’t explain, or an architecture decision nobody wants to own.

Related

• PostgreSQL performance tuning when the database is the bottleneck
• Rails vs Django vs Laravel: an opinionated comparison
• Legacy modernization services that keep the business running
• Payment system architecture: the parts that matter after launch
• Cloud migration consultant for near-zero-downtime moves to AWS and GCP