How do I move off Django 4.2 LTS to 5.2 Migration Before April 30, without getting stuck?
Decide when to move from Django 4.2 LTS to 5.2 before 4.2 security support ends in April 2026, balancing Python version constraints, ORM behavior changes, and extension compatibility.
Blockers
- framework/django-4-2 — EOL 2026-04-30
- requires_version: framework/django-5-2 → runtime/python-3-10
- requires_version: framework/django-5-1 → runtime/python-3-10
- Django 4.2 is the last series that supports Python 3.8
- Django 4.2 is the last series that supports Python 3.9
- requires_version: framework/django-5-2 → package/postgresql-14
- requires_version: framework/django-5-1 → package/postgresql-13
Who this is for
- enterprise
- small-team
Candidates
Upgrade directly from Django 4.2 LTS to 5.2 LTS now
As of 2026-04-01, Django 5.2 is the current LTS release and Django says support for Django 4.2 ends in April 2026. Django 5.2 supports Python 3.10, 3.11, 3.12, 3.13, and 3.14, while Django 4.2 is the last series that supports Python 3.8 and 3.9. Django's release process explicitly keeps LTS-to-LTS upgrades easier by not dropping deprecation shims in the new LTS release itself, but removals from the 5.0 and 5.1 cycle still apply when you land on 5.2. The main blockers to audit before the jump are Python 3.10+ readiness, database version floors, timezone and storage setting removals, and queryset/session behavior changes.
When to choose
Use this when you can move the runtime to Python 3.10+ immediately and you want the longest supported landing point with one migration program instead of repeated framework churn. This is the default choice if your third-party packages already support Django 5.2 or you can verify them quickly in their official docs.
Tradeoffs
Best long-term support position and least repeated upgrade work, but it compresses all 5.0 and 5.1 migration fixes into one window. You must absorb removed features such as `pytz` support, `Meta.index_together`, legacy storage settings, and some ORM/queryset behavior changes before release.
Cautions
Django 5.2 supports PostgreSQL 14+ and changes MySQL connections to default to `utf8mb4`; legacy PostgreSQL 13 and `utf8mb3` assumptions are blockers. Django 5.0 removed `pytz` support, changed the default `USE_TZ` value to `True`, removed `django.contrib.sessions.serializers.PickleSerializer`, and no longer allows `QuerySet.iterator()` with prefetched relations unless `chunk_size` is provided. Third-party apps are free to set their own Python and Django version requirements, so package-specific compatibility must be checked in official package docs.
Use Django 5.1 briefly as a compatibility checkpoint, then move to 5.2 before April 30, 2026
As of 2026-04-01, this is a short-lived fallback path for teams blocked from landing directly on 5.2. Django 5.1 supports Python 3.10, 3.11, 3.12, and 3.13 and still supports PostgreSQL 13, while Django 5.2 raises the PostgreSQL floor to 14. This makes 5.1 useful if application code can leave 4.2 now but infrastructure or extensions are not yet ready for the 5.2 database floor. The checkpoint should be temporary because 5.1 is not an LTS target and does not solve the April 2026 4.2 support deadline by itself.
When to choose
Use this only when a direct 5.2 cutover is blocked by PostgreSQL 13, staged Python upgrades, or package validation work that cannot be finished in one pass. The decisive factor is whether you need a short compatibility bridge without remaining on 4.2 until support ends.
Tradeoffs
Reduces immediate infrastructure pressure, especially for PostgreSQL 13 estates, but creates two migrations instead of one and extends the period where teams must carry upgrade context across multiple releases. It is safer operationally only if the bridge is tightly time-boxed.
Cautions
You still inherit 5.0 and 5.1 removals, including `Meta.index_together`, `DEFAULT_FILE_STORAGE`, `STATICFILES_STORAGE`, `get_storage_class()`, and the earlier timezone and session serializer removals from 5.0. Django 5.1 also drops PostgreSQL 12 and MariaDB 10.4, so very old databases are still blockers. If you are on Python 3.8 or 3.9, you must upgrade Python before any 5.x move because Django 4.2 is the last series that supports those versions.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "How do I move off Django 4.2 LTS to 5.2 Migration Before April 30, without getting stuck?"