Django 2.0

2.0 released 2 December 2017, latest 2.0.13.

Django 2.0 reached end of life on 1 April 2019.

What changed

Django 2.0 made Python 3 mandatory, ending compatibility with Python 2. It introduced the path() URL-routing API and route converters, alongside re_path() for regular-expression routes, giving projects a simpler alternative to regex-only URL declarations. ForeignKey and OneToOneField definitions must explicitly provide an on_delete behavior. The ORM added window expressions and support for conditional aggregation through an aggregate filter argument. The release also removed APIs that had been deprecated in earlier Django versions, so code relying on long-deprecated imports or behaviors may fail during an upgrade from an older line.

What staying costs

Django 2.0 has reached end of life. Upstream no longer provides security fixes, bug fixes, or compatibility updates for this cycle. Remaining on it leaves production systems exposed when vulnerabilities are found in Django itself and increasingly constrains runtime, database-driver, and third-party-package choices. The longer a project remains on 2.0, the more deprecated and removed behavior accumulates between it and a supported Django target, making the eventual upgrade broader and harder to test.

What to do

First update to the latest available patch release in the 2.0 line and establish a reliable automated test suite around critical views, authentication and authorization flows, background jobs, management commands, and migrations. Inventory the Python runtime, database backend, deployment tooling, and installed Django packages, then choose a currently supported Django target that those dependencies can support or upgrade. Read and apply the Django upgrade notes for each intervening release, addressing removals and deprecation warnings in sequence. Verify every relationship has an intentional on_delete setting, audit URL configuration and deprecated imports, run the Django system checks and full test suite, and test migrations against production-like data before deployment. Use a staged rollout with monitoring and a rollback plan for the application release and any schema changes.

We can tell you what moving off Django 2.0 involves.

What it takes to move off Django 2.0 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.

Not sure yet? Get my plan