How would you upgrade a Django CRM from 4.2 LTS to 5.2 LTS with the least risk?

## Why this upgrade is manageable Moving from one LTS to the next spans three feature releases (5.0, 5.1, 5.2). Django's **deprecation policy** is what makes that safe: anything removed in 5.0 or 5.1 was deprecated in 4.0, 4.1 or 4.2, so on the latest **4.2** it still works *and* raises a warning. A CRM that runs on 4.2 with **no Django deprecation warnings from its own code** has already fixed every removal on the way to 5.2. What remains are the few documented backwards-incompatible changes that had no deprecation path, the dependencies, and the Python version. ## Step 1 — the interpreter first | Django | Supported Python | |---|---| | 4.2 | 3.8 – 3.12 (3.12 from 4.2.8) | | 5.0 | 3.10 – 3.12 | | 5.1 | 3.10 – 3.13 (3.13 from 5.1.3) | | 5.2 | 3.10 – 3.14 (3.14 from 5.2.8) | 5.0 dropped Python 3.8 and 3.9. A CRM still on 3.9 must move its interpreter while on 4.2; **3.12** is the natural target, since every release from 4.2 to 5.2 supports it and 6.x will require it. Changing Python and Django in separate steps keeps every failure attributable to one cause. ## Step 2 — a clean 4.2 1. Upgrade to the **latest 4.2 patch**. 2. Run `python -Wa manage.py test` (or `PYTHONWARNINGS=always` with another runner, without output capture). 3. Fix every warning pointing into the CRM's code. Typical 4.2-era items: - `DEFAULT_FILE_STORAGE` / `STATICFILES_STORAGE` → the `STORAGES` setting (removed in 5.1). - `Meta.index_together` → `Meta.indexes` (removed in 5.1). - The `length_is` filter → `length` (removed in 5.1). - `assertQuerysetEqual()` → `assertQuerySetEqual()` (removed in 5.1). - Logging out with a `GET` request → a `POST` form (removed in 5.0). - `USE_L10N` and `pytz` time zones (removed in 5.0). 4. Check settings whose **defaults** changed. `USE_TZ` defaults to `True` from 5.0; a CRM whose settings never set it would silently switch to aware datetimes. Set it explicitly before upgrading. ## Step 3 — dependencies List every Django-related package (admin themes, REST toolkit, auth add-ons, storage backends) and find the release that supports 5.2. Upgrade them on 4.2 where their newer versions still support 4.2; otherwise note which must move together with Django. ## Step 4 — one feature release at a time The upgrade guide recommends stepping through each feature release even between LTS versions: **4.2 → 5.0 → 5.1 → 5.2**, each on its latest patch. At each step: - Read that release's notes, especially **Backwards incompatible changes**. - Run the full suite with `-Wa`; new warnings are the next release's removals. - Run `manage.py check`, and `check --deploy` against production settings. - Generate and review migrations for anything the release changed in your models or in contrib apps. Intermediate steps do not all need to reach production; they need to be green in CI so a failure points at one release's changes. ## Estimating the work before starting - Count the warnings from a `-Wa` run, grouped by class and by message, to size the code changes. - Search settings for names on the 5.0 and 5.1 removal lists and for settings whose defaults change. - Build a small table of dependencies: current version, first version supporting 5.2, and whether that version still supports 4.2. - Note custom code that subclasses Django internals (admin templates, form rendering, custom fields); those are where undocumented behaviour changes bite. ## Step 5 — rollout - Deploy 5.2 with a rollback plan: know which migrations are reversible. - **Clear the cache** after the switch; the upgrade guide warns that pickled objects, such as responses cached by `cache_page`, are not guaranteed to be compatible across Django versions. - Watch error rates and logs for a few days. ## Common failure modes - Upgrading Python, Django and twenty packages in one commit, then bisecting by hand. - Ignoring warnings on 4.2 and meeting them as `ImportError`s and `AttributeError`s on 5.1. - Assuming defaults stayed the same because settings did not change.