Django 4.2 LTS to 5.x Migration Before April 2026 End of Support — when and how should I migrate?

Teams still on Django 4.2 LTS need to decide whether to jump to Django 5.1/5.2 now or hold briefly and accept a narrow upgrade window before support ends in April 2026.

Upgrade directly to Django 5.2 LTS now if dependencies already support it; hold on 4.2 only when a documented blocker exists and the cutover date is fixed before April 2026.

Blockers

Who this is for

Candidates

Upgrade directly from Django 4.2 LTS to 5.2 LTS now

As of 2026-04-02, Django 4.2 LTS remains supported only until April 2026, while Django 5.2 is the current LTS and is supported until April 2028. Django is available as open-source software under the BSD license, so this is a support-window and migration-risk decision rather than a framework licensing decision. Django 5.2 supports Python 3.10 through 3.14, but the path from 4.2 to 5.2 crosses important compatibility breaks introduced in 5.0 and 5.1. The main blocker-level checks are Python version, database version floors, removed 4.2-deprecated APIs, and any MySQL or Oracle driver assumptions.

When to choose

Use this when you can allocate upgrade time immediately and want the longest supported landing zone. It is the default choice if your dependencies already support Django 5.2 and you do not want to spend effort on an unsupported intermediate target.

Tradeoffs

Best long-term support outcome and avoids landing on an already unsupported 5.1 release, but it forces you to absorb all 5.0, 5.1, and 5.2 migration work in one project window.

Cautions

Verified blocker items include: Django 5.0 is the first release that drops Python 3.8 and 3.9 support; Django 5.1 removes items deprecated in 4.2 such as Meta.index_together, length_is, BaseUserManager.make_random_password, DEFAULT_FILE_STORAGE, and STATICFILES_STORAGE; Django 5.1 requires MariaDB 10.5+ and PostgreSQL 13+; Django 5.2 requires PostgreSQL 14+ and changes the default MySQL connection character set to utf8mb4. If you use MariaDB 10.7+ with pre-5.0 UUIDField columns, Django documents a migration caveat for existing CHAR(32) data models.

Sources

Use Django 5.1 only as a temporary validation hop, then land on 5.2

As of 2026-04-02, Django 5.1 is no longer a supported destination: Django announced when 5.2 shipped that 5.1 had reached end of mainstream support, and the downloads page lists 5.1 support ending on December 3, 2025. Django's upgrade guide still recommends incremental feature-release upgrades, especially across multiple feature releases and from one LTS to the next. That makes 5.1 useful only as a short-lived CI or staging checkpoint if you need to isolate failures between the 5.0 and 5.1 change sets before finishing on 5.2. It should not be the steady-state production target now.

When to choose

Use this only when the codebase is large enough that a direct 4.2-to-5.2 jump hides too many regressions, or when third-party packages need to be validated one feature release at a time. The decisive factor is whether a temporary unsupported checkpoint reduces migration risk enough to justify the extra testing work.

Tradeoffs

This lowers debugging ambiguity by separating 5.0 and 5.1 removals from 5.2 changes, but it creates extra churn and still ends at 5.2. It is an engineering tactic, not a platform choice.

Cautions

Django 5.1 already removed several 4.2-deprecated features, so treat it as a break-detection step only. Verified 5.1 blockers include MariaDB 10.5+, PostgreSQL 13+, SQLite 3.31.0+, asgiref 3.8.1+, and removals such as Meta.index_together, length_is, DEFAULT_FILE_STORAGE, and STATICFILES_STORAGE.

Sources

Hold briefly on Django 4.2 only for dependency blockers, with a hard stop before April 2026

As of 2026-04-02, this option is still technically open because Django 4.2 LTS support ends in April 2026, but the window is extremely narrow. Django's upgrade guide explicitly notes that some third-party packages may lag new Django support, and in those cases teams may need to wait for dependency releases. This makes a short hold reasonable only if package compatibility is the real blocker and a direct 5.2 cutover date is already scheduled. The hold should be measured in weeks, not quarters.

When to choose

Use this when a specific dependency does not yet support Django 5.2 or when a database or runtime prerequisite cannot be completed immediately. The decisive factor is having a documented blocker and a near-term cutover plan, not a general desire to defer work.

Tradeoffs

This reduces immediate disruption if a real external blocker exists, but it compresses testing and rollout into the final support window for 4.2. It also increases the chance that you end up upgrading under time pressure.

Cautions

Do not treat Django 5.1 as the fallback landing spot while waiting, because as of 2026-04-02 it is already out of support. Before holding, confirm the exact blocker against official package support, and use Django's warning-driven upgrade process so the wait is spent removing deprecations instead of standing still.

Sources

Facts updated: 2026-04-02
Published: 2026-04-03

Related questions

Try with your AI agent

$ npm install -g pocketlantern
$ pocketlantern init
# Restart Claude Code, Cursor, or your MCP client, then ask:
# "Django 4.2 LTS to 5.x Migration Before April 2026 End of Support — when and how should I migrate?"
Missing something? Request coverage