Back to Homepage

Django upgrades that start with a plan.

Django 4.2 has had no security updates since 7 April 2026. Python 3.10 follows in October 2026. Every release you skip makes the next one harder: more deprecations, more packages that have moved on, more code nobody remembers writing.

The audit shows what the upgrade involves before anything changes: the work, the cost and the places where it can break. You get a written plan. I carry out the upgrade, or your team does it with the plan in hand.

WHAT THE AUDIT COVERS

Versions and Deprecations

Django, Python and PostgreSQL versions against their support calendars. Every deprecation warning the code raises on the target version, sorted by effort.

Third-Party Packages

Every package in your requirements, checked for a release that supports the target version. Abandoned packages get a named replacement or a note that the code has to move into your project.

Test Coverage

Where tests protect the upgrade and where they are missing. What counts is coverage of the code the upgrade touches, not an overall percentage.

Database and Migrations

Migration history, candidates for squashing and the schema changes the upgrade forces. Large tables get a migration strategy that does not lock them.

Deployment and CI

Build, pipeline and server setup checked against the new versions, with a rollback path. The upgrade can then go live on a normal working day.

Plan and Estimate

The upgrade split into steps that can go live one at a time, each with its effort in days and its risk.

HOW IT RUNS

Audit

Three working days at a fixed €2,900 plus VAT. Read access to the repository is enough, production stays untouched. The result is the written plan.

Upgrade

Carried out along the plan, by me or by your team. The quote for it comes from the estimate in the plan. Each step goes live on its own, so a problem shows up in one small change instead of one large release.

Staying Current

Optional afterwards: two upgrades a year and security updates for your dependencies. The price depends on what the audit found.

WHY NOT WAIT

  • When a release leaves support, its security fixes end. A vulnerability published after that date stays open in your application.

  • Libraries drop old Django versions in their new releases. Staying behind means keeping their old versions too, bugs included.

  • One release behind is routine work. Several releases behind means every removed API at once, and an estimate that is harder to trust.

QUESTIONS BEFORE BOOKING

Related Case Studies

Daniel made a decisive contribution to the founding and implementation of the companies Solvster and VIARES. He was responsible for the entire technical setup of the online presence, including server setups, developing and optimizing the website, and ensuring functionality. I was particularly impressed by how proactively and solution-oriented he always worked on improvements. Daniel was always very responsive and reliable - it was a pleasure working with him. His expertise and commitment contributed significantly to the success of both projects!

Dietmar Eglhofer - CEO, Solvster & VIARES

Follow in the footsteps of Dietmar and bring your vision to life.

Get In TouchGet In Touch