Yes, for Django applications and the Python underneath, because that is where I can show the work. For another stack, write me a short note and I will tell you whether I am the right person for it.
Software modernization for Django apps. Upgrades that start with a plan.
Software modernization here means: a Django application that runs on outdated versions comes back onto versions that still receive support. I do this as a developer and consultant in Vienna and work with teams across time zones. Mainframes, .NET and Java applications are not part of it. The first step is an audit at a fixed price.
Django 4.2 has had no security updates since 7 April 2026, and Python 3.10 reached the end of its support in October 2026.
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 on request, or your team does it with the plan in hand.
Not sure yet how big this is for you? The seven-question self-check gives a first answer without reading any code.
My work on legacy systems
This is what I have done on legacy Django applications: raised versions, switched the database and rebuilt one legacy system.
Django Versions
Django versions on a production system, one after the other: from 2.2 through 3.0 and 3.1 to 3.2, between 2019 and 2021. In the same system, Celery, the software for background jobs, went from 4 to 5. I moved another client project, outside that system, to Django 4 or newer.
Database
MySQL to PostgreSQL: I worked on character set and collation beforehand, and the move itself ran with pgloader, a tool for moving data.
Rebuilding Legacy Systems
A Python 2.7 product on Django 1.7 from 2014, which I rebuilt on Django 6.1 and Python 3.14. It is my own product.
A Tool for Upgrade Plans
I maintain django-upgrade-report, a free open-source tool. It reads your lockfile, the list of pinned package versions, and prints a plan for the route to the target version. On 28 September 2026 I also analyzed which Django versions the authors of the 200 most downloaded Django packages list.
What the upgrade audit covers
Versions and Deprecations
Django, Python and PostgreSQL versions against their support calendars. Then the deprecation warnings the code raises on the target version, meaning notices about features that are going away. Sorted by effort.
Third-Party Packages
The packages in your requirements, the list of dependencies, 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
The migrations, meaning the steps that change the database schema: their history, candidates for squashing and the schema changes the upgrade forces. Large tables get a migration strategy that does not lock them for long.
Deployment and CI
Build, pipeline and server setup checked against the new versions, with a rollback path in case a step does not hold.
Plan and Estimate
The upgrade split into steps that can go live one at a time, with effort in days and risk for each step.
HOW IT RUNS
Audit
Three working days at a fixed €2,900. Read access to the repository is enough, production stays untouched. The result is the written plan.
Carrying Out the Upgrade
Carried out along the plan, by me or by your team. The quote for it comes from the estimate in the plan. The steps go live one at a time, so a problem tends to show up in one small change instead of one large release.
Staying Current
Optional afterwards: ongoing upgrades and security updates for your dependencies. The price depends on what the audit found.
WHY NOT WAIT
When a release leaves support, it gets no more security fixes. The Django team no longer checks whether a vulnerability published later also affects your version.
Libraries such as Django REST framework and django-filter have dropped Django 4.2 from their new releases. Staying behind means staying on their older versions too.
One release behind is routine work. Several releases behind means many removed features at once, and an estimate that is harder to trust.
What has happened since the end of support, with sources: Django 4.2 is end of life: what now?.
QUESTIONS BEFORE BOOKING
Related Case Studies
Related Services
Manuel Kasbarian - CEO, SophistiXWe have enjoyed working with Daniel for 10 years now. We highly appreciate his fast response times around the clock and his all-round knowledge. Whether server configurations or programming, he always has the right solution.
Join Manuel and launch your next project with confidence.
Open to new ProjectsGet In Touch