Short answer: several pieces of a typical Python web stack lost security support in 2026. Django 4.2 LTS stopped receiving security fixes on April 7, 2026. Node.js 20 followed on April 30, Amazon Linux 2 on June 30, and Amazon RDS for MySQL 8.0 moved to paid Extended Support on August 1. Python 3.10 reached end of life on October 1, 2026, and PostgreSQL 14 follows on November 12, 2026.
If your product runs on any of these, the people who maintain that software no longer ship security patches for it. The fix is a planned, tested upgrade, not a rewrite. This guide lists the dates, explains what each one means for you, shows how to check what you actually run, and walks through the upgrade order we use to move production systems with minimal disruption.
The deadlines at a glance
| Component | Support ended or ends | Upgrade target | Target supported until |
|---|---|---|---|
| Django 4.2 LTS | April 7, 2026 | Django 5.2 LTS | April 30, 2028 |
| Node.js 20 | April 30, 2026 | Node.js 24 LTS | April 30, 2028 |
| Amazon Linux 2 | June 30, 2026 | Amazon Linux 2023 | Current AWS release |
| Amazon RDS for MySQL 8.0 | Standard support ended July 31, 2026 | MySQL 8.4 | July 31, 2029 (RDS standard support) |
| Python 3.10 | October 1, 2026 | Python 3.12 or 3.13 | October 2028 or October 2029 |
| PostgreSQL 14 | November 12, 2026 | PostgreSQL 17 or 18 | November 2029 or November 2030 |
Already past their end of life: Python 3.9 (October 2025), PostgreSQL 13 (November 2025), and the non-LTS Django 5.0 and 5.1 releases.
Dates come from each project's own release calendar (Python, Django, Node.js, PostgreSQL) and from AWS's RDS for MySQL version documentation, checked in October 2026.
What "end of life" actually means for your product
Nothing switches off on the deadline. Your app keeps running. What changes is everything around it:
- Security fixes stop. When a vulnerability is found in Django 4.2 or Python 3.10 now, no official patch will be released for it. You either upgrade or carry the risk.
- Your dependencies move on without you. Package maintainers drop old versions quickly. Django 6.0 already requires Python 3.12 or newer, and new releases of popular libraries follow the same pattern, so security fixes in your dependencies stop reaching you too.
- Audits and customers start asking. Security questionnaires, SOC 2 and ISO 27001 reviews, and enterprise procurement routinely ask whether you run supported software. "We're on an end-of-life version" is a hard answer to give.
- Managed services start charging. On AWS, an RDS for MySQL 8.0 instance kept past July 31, 2026 runs under RDS Extended Support, which is billed on top of your normal instance cost from August 1, 2026, steps up again from August 1, 2028, and ends on July 31, 2029.
The practical takeaway: end of life turns a routine upgrade into a risk and cost question. The longer you wait, the more versions you have to jump at once.
How to check what you are running
Check production, not a developer laptop. The commands below cover the usual stack; also look at your Dockerfiles (for example FROM python:3.10-slim), your CI configuration, and any .nvmrc or .python-version files, because those decide what actually ships.
# Python and Django (run inside your app's environment)
python --version
python -m django --version
# Node.js (build servers and frontend tooling count too)
node --version
# Operating system: Amazon Linux 2 reports NAME="Amazon Linux" VERSION="2"
cat /etc/os-release
# PostgreSQL: run this inside psql
# SELECT version();
# Every RDS database engine in an AWS account and region
aws rds describe-db-instances \
--query "DBInstances[].[DBInstanceIdentifier,Engine,EngineVersion]" \
--output tableThe upgrade order we recommend
Upgrades fail in the same places every time: thin test coverage, data migrations, and the cutover itself. This order puts a safety net under each of those before anything changes in production.
- Build the safety net first. Run your test suite with coverage and add tests around payments, authentication, and anything that writes data. If there are no tests, a short set of end-to-end checks on the critical paths is still far better than none.
- Surface every deprecation warning. Run the tests with warnings turned on and fix them while you are still on the old version. Each fixed warning is one less surprise later.
- Upgrade Python first, staying on Django 4.2. Django 4.2 supports Python 3.8 to 3.12, so you can move to Python 3.12, fix what breaks, and ship that on its own.
- Step Django up one release at a time. Django's own upgrade guide recommends moving through each feature release (4.2 to 5.0 to 5.1 to 5.2), on the latest patch release of each, and fixing deprecation warnings at every step, rather than jumping straight to 5.2. Tools like
django-upgradeandpyupgradehandle many of the mechanical code changes; review their diffs like any other change. - Upgrade the database on a copy first. For PostgreSQL or RDS for MySQL, restore a snapshot to a new instance, upgrade that copy, and run your test suite and a sample of real queries against it. AWS's documentation describes exactly this snapshot-and-test approach for major version upgrades.
- Move servers and build tooling. Rebuild servers or container images on Amazon Linux 2023 or a current base image, and move Node.js builds to Node.js 24 LTS in your Dockerfiles, CI, and
.nvmrc. - Cut over with a way back. Keep the old environment ready, verify your backups by actually restoring one, and schedule the switch in a quiet window. A cutover you can roll back is a cutover you can try with confidence.
Our guide to backing up and restoring MySQL, PostgreSQL, and MongoDB databases covers the backup side in detail.
# Show every deprecation warning while your tests run
python -Wa manage.py test
# List installed packages that have newer releases
pip list --outdated
# Rewrite code for newer Django and Python versions, then review the diff
pip install django-upgrade pyupgrade
django-upgrade --target-version 5.2 $(git ls-files '*.py')
pyupgrade --py312-plus $(git ls-files '*.py')What drives the effort
There is no honest one-size answer to "how long will our upgrade take?", but the effort is predictable once you look at a few things:
- Test coverage. Good tests make an upgrade mostly mechanical. Without them, every change needs manual checking.
- Third-party packages. Abandoned packages that never added support for newer Django or Python versions have to be replaced, and that is often the biggest single task.
- Custom code on deprecated APIs. Older apps that override Django internals or rely on removed features take longer than apps that stayed close to the documented API.
- Data size and downtime tolerance. A small database can be upgraded in a maintenance window; a large one with no tolerance for downtime needs replication or a staged cutover.
- How the infrastructure is built. Servers defined in code (Terraform, CloudFormation, Dockerfiles) are quick to rebuild on a new base. Hand-built servers have to be rediscovered first.
AI-assisted tools now do much of the mechanical rewriting. The work that still needs senior judgment is the part above: the tests, the data migration, and the cutover.
Do you need a rewrite instead?
Usually not. If the product still fits the business, upgrading in place keeps the logic that already works and removes the support and security risk underneath it. A rewrite makes sense when the architecture itself is what blocks you, and even then a phased migration that replaces one part at a time beats a big-bang rewrite almost every time.
If you want a second pair of eyes, our Upgrade Assessment gives you a version, dependency, and end-of-life audit, an upgrade path with test gaps and risks called out, and a review of your cloud bill and slowest pages. For Django specifically, see Django modernization; for moving servers and databases, see cloud migration and DevOps. Or book a free discovery call and tell us what you are running.
Frequently Asked Questions
Is Django 4.2 still supported?
No. Django 4.2 LTS received its last security fixes in April 2026, and its security support ended on April 7, 2026. The current long-term support release is Django 5.2, which is supported until April 30, 2028. Django 6.0 and 6.1 are also current but are not LTS releases and require Python 3.12 or newer.
When does Python 3.10 reach end of life?
Python 3.10 reached end of life on October 1, 2026, so it no longer receives security releases. Python 3.11 is supported until October 2027, Python 3.12 until October 2028, and Python 3.13 until October 2029, which makes 3.12 or 3.13 the sensible target for most production apps today.
Can I upgrade straight from Django 4.2 to Django 5.2?
You can, because both are LTS releases, but Django's upgrade guide recommends moving through each feature release (5.0, then 5.1, then 5.2) and fixing deprecation warnings at each step. Upgrading Python to 3.12 first, while still on Django 4.2, keeps each change small and easy to test.
What happens to Amazon RDS for MySQL 8.0 after July 2026?
Your database keeps running, but RDS standard support for MySQL 8.0 ended on July 31, 2026, so it now runs under RDS Extended Support. That is billed as an extra charge from August 1, 2026, the rate rises from August 1, 2028, and Extended Support ends on July 31, 2029. Upgrading to MySQL 8.4, which has RDS standard support until July 31, 2029, removes the charge.
Is Amazon Linux 2 still getting security updates?
No. Amazon Linux 2 reached end of support on June 30, 2026, and AWS recommends moving to Amazon Linux 2023. Rebuilding servers or container images on Amazon Linux 2023 is usually straightforward when the infrastructure is defined in code.
How long does a Django or Python upgrade take?
It depends on test coverage, how many third-party packages need replacing, how much custom code relies on deprecated APIs, and how much downtime you can tolerate. A short assessment of the codebase turns those unknowns into a fixed estimate before any upgrade work starts.