Technology

Python 2 Migration
so the dependencies start receiving fixes again.

Python 2.7 reached end of life on 1 January 2020. Every current library targets Python 3, so a Python 2 codebase is frozen against a set of dependencies that stopped receiving fixes years ago.

You get the codebase moved to Python 3, with the tests to prove behaviour did not change along the way. We do this for businesses in Australia, New Zealand, the UK and the US, at a fixed price.

  • Independent No licence commission, no reseller agenda
  • 18+ yrs Building business software
  • Fixed Price scopes, no surprises
  • AU NZ UK US Perth-based, working remotely
Australian owned and operated

Built here. Your data stays here.

  • No offshore development. Everything is written by our own team in Australia. Nothing is subcontracted overseas.
  • Your data stays onshore. Hosted in Australia, on infrastructure you own, under Australian law.
  • Every state, not just ours. Perth, Melbourne, Sydney, Brisbane, Adelaide and everywhere between.
Where we fit

Scripts nobody looks at, with no security fixes

Python 2 code tends to be scripts and services that do something important and unglamorous: processing files, moving data between systems, generating reports, running scheduled jobs. Nobody looks at them because they work.

The exposure is in the dependencies. Every package pinned to a Python 2 version stopped receiving security fixes, and the strings-and-bytes distinction that makes the migration awkward is exactly what makes automated conversion unreliable.

What the work actually is

Upgrade the code, and prove nothing changed

Automated conversion gets part of the way and hides the part that matters. The strings-and-bytes change is where behaviour shifts silently, so the work is deliberate conversion plus tests that prove the output has not changed.

What you have now

  • Python 2.7 scripts and services
  • Pinned packages with no Python 3 release
  • Scheduled jobs nobody documented
  • A server kept on an old OS for this
What we build

Convert deliberately, and verify the string handling

Automated conversion gets part of the way and hides the part that matters. The strings-and-bytes change is where behaviour shifts silently, so the work is deliberate conversion plus tests that prove the output has not changed.

Get a fixed-price scope

What you end up with

  • Running on current Python with maintained dependencies
  • Tests around the behaviour, often for the first time
  • A server that can be patched again
What we do

Only the Python 2 work you actually need

Most engagements are some combination of these, and most start with the first.

  1. Inventory the dependencies

    Which packages have a Python 3 release, which are abandoned, and which need replacing. This usually determines the effort more than the code does.

  2. Convert the code

    Automated tooling as a starting point, then a deliberate pass over the string and bytes handling where silent behaviour changes hide.

  3. Write the tests first

    Capture what the current code produces before changing it. Without that you cannot prove the migration preserved behaviour.

  4. Replace abandoned packages

    Anything with no Python 3 release gets a maintained equivalent or a small purpose-built replacement.

  5. Modernise the deployment

    These scripts usually live on a server kept old solely for them. Once converted, that constraint disappears.

Meet the person

From Python 2 to your new system, one seamless process

Your Python 2 Migration, handled by the founder from start to end.

HELLO PEOPLE designs, builds and looks after AI, software, app and data solutions for Australian businesses, with senior expertise on every project and a scope agreed before work starts. For a migration, that means every balance is proven before the old system is switched off.

Since 2007, HELLO PEOPLE has delivered more than 100 projects from Perth for small and medium businesses across Australia: custom software and apps, system integrations, data migrations, reporting and dashboards, and AI that works inside the systems a business already runs.

I lead every engagement myself. I trained in accounting before moving into IT, hold accounting and IT professional qualifications and an MBA, and bring more than 20 years of experience across sales, service delivery, inventory and compliance. I am also a PhD candidate in AI at Curtin University, researching retrieval-augmented generation (RAG), so the technology is always judged by what it does for the business.

  • An old-fashioned service

    Small and boutique. The person who scopes your migration is the person who moves your data, and the same person is there on cutover weekend.

  • Quick responses

    No ticket queue and no account manager in between. You hear back within one business day, usually sooner.

  • A long-term partner

    The migration is the start, not the end. When you need the next system, integration or report, you call the same person, who already knows your business.

Where you are now

It works, and nobody will touch it

  • Python 2.7 past end of life since 1 January 2020
  • Pinned packages receiving no security fixes
  • A server held on an old OS purely for this code
  • Nobody certain what the scripts actually do

After

Supported, documented and yours

  • Current Python with maintained, patched dependencies
  • Tests that prove behaviour was preserved
  • Deployment on a supported operating system
  • Documentation of what each job actually does

Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.

Get a fixed-price scope
Common questions

What people ask us about Python 2

Can 2to3 do this for us?

It gets part of the way and it will not tell you about the part that matters. The strings and bytes distinction changes behaviour silently, so automated conversion needs a deliberate review pass and tests behind it.

Our code works fine. Why change it?

The code is not the exposure, the dependencies are. Packages pinned to Python 2 stopped receiving security fixes in 2020, and the server is usually being held on an old operating system to keep them running.

We have no tests. Is that a problem?

It is the first thing to fix. We capture what the current code produces and turn that into tests, so the migration can be proven rather than hoped. It is also useful long after this project ends.

What if a library we depend on has no Python 3 version?

Either a maintained equivalent exists, or the small part you actually use gets rebuilt. In practice most codebases use a fraction of the libraries they import.

Is this urgent?

It depends on exposure. An internal script on an isolated server is a slow burn. Anything processing external input or reachable from the internet should be dealt with now.

Tell us what your Python 2 system does

What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.

Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.