Skip to content
APAdam Probert
← All work

An enterprise engineering organisation

A large-scale source-control and workflow-platform migration

Led the migration of hundreds of repositories and a major orchestration upgrade against a demanding timeline.

Context

The situation

An engineering organisation needed to move its source control and workflow orchestration onto modern, supported platforms (across hundreds of repositories and the pipelines built around them) while day-to-day delivery continued.

Problem

What actually needed solving

Migrating hundreds of repositories from Bitbucket to GitHub and upgrading Airflow from version 2 to version 3 is as much a coordination and trust problem as a technical one. The work had to be automated to be feasible, sequenced to avoid breaking teams mid-flight, and delivered by an external team that engineers were initially sceptical of.

Constraints

What I had to work within

  • Hundreds of repositories with tangled, undocumented dependencies
  • A demanding delivery timeline with limited room to slip
  • Kubernetes-based infrastructure that had to be reconfigured in step
  • Initial scepticism from client engineers toward an external delivery team
Approach

How I moved it forward

  1. 01

    Analysed repository metadata and dependencies to understand the true shape of the estate before moving anything.

  2. 02

    Automated migration and discovery tasks so the volume was tractable and the process was consistent rather than manual and error-prone.

  3. 03

    Upgraded Airflow from 2 to 3 and reconfigured the Kubernetes-based infrastructure around it, sequenced to keep teams working.

  4. 04

    Coordinated closely across client and internal engineers, building credibility by being visibly careful with their systems.

Key decisions

The trade-offs that mattered

  • Discovery before migration

    Understanding dependencies up front turned a risky big-bang into a sequenced programme where each step was predictable.

  • Automate the repetitive, supervise the risky

    Automation made the scale feasible; human judgement was reserved for the cases that genuinely needed it.

  • Earn trust through transparency

    With sceptical engineers, showing the plan and the safeguards did more for credibility than any assurance could.

Outcome

What changed

  • The migration was delivered successfully within the timeline.
  • It became a reference example of combining technical detail, automation, and delivery structure.
  • Client engineers moved from scepticism to confidence in the external team.
Lessons

What I took from it

  • At this scale, the migration mechanics are rarely the hard part: sequencing, coordination, and trust are.
  • Credibility with a sceptical team is won by being careful in public, not by promising in private.
Contact

Have a difficult, important problem?

I’m happiest where the problem is unclear, several teams need to work together, and the outcome actually matters. If that sounds like your situation, let’s talk.

  • Talk through a hard technical problem
  • Scope a platform, data, or distributed-systems build
  • Get a second opinion on an architecture or delivery plan
  • A role or engagement worth a conversation