The language that stopped being supported

Python is one of the most widely used programming languages in business software — it sits behind data tools, internal systems, automation and analytics in companies that would never describe themselves as technical. If a system you rely on was written in Python 2, you are running on a version of the language that was officially retired on 1 January 2020. It still runs. It is no longer supported. And the move to Python 3 is more involved than the version numbers suggest.

Why Python 2 to 3 is not a free upgrade

Python 3 was deliberately designed to break compatibility with Python 2. The people behind the language decided that fixing its long-standing flaws was worth the cost of a clean break. That was a sound decision for the language’s future, but it meant code written for Python 2 does not simply run on Python 3. It has to be reviewed and updated, and the wider ecosystem of tools and libraries had to be rebuilt for the new version too.

For a small script, that is an afternoon. For a real system — one built up over years, with many dependencies and business logic nobody has documented — it is a project. The size depends entirely on how the system was built, which is why a proper assessment, rather than a guess, is the starting point.

Why so much Python 2 is still running

The break in compatibility slowed adoption of Python 3 for years, and the long tail of that is still with us: Python 2 runs in far more production environments than most organisations admit. The pattern is familiar. The system works, so the migration is deferred. The people who wrote it move on. Eventually nobody is quite sure what it would take to move it, so it stays — quietly critical and quietly unsupported.

What the exposure actually is

An end-of-life language means no more security fixes. If a vulnerability is found in Python 2 today, there is no official patch. Systems built on it run on an ageing foundation that the rest of the software world has left behind, which makes everything around them — the libraries, the operating systems, the tools — progressively harder to keep current.

There is also the dependency problem. The libraries a Python 2 system relies on are themselves frozen. As the ecosystem moves to Python 3, the old versions stop being maintained, and the system becomes an island — working in isolation, impossible to extend, and risky to touch. For anything handling data of value, that is a liability that compounds.

What to do now

The first step is to understand the system, not to start rewriting it. What does it do, what does it depend on, how much of it is genuinely in use, and how critical is it to the business. That assessment tells you the size of the task and the safest way to approach it — often an incremental migration rather than a single risky rewrite — and it surfaces the dependencies that tend to cause the surprises.

It is also the moment to ask whether the system should be migrated as-is or reconsidered. A forced migration is a good time to decide whether you are preserving something valuable or carrying forward something you have outgrown.

If a system that matters to your business is still running on Python 2, it is unsupported now, and the risk is not waiting for a deadline — it is already here. We will establish what moving it actually involves.

Start a Conversation