A source-control and workflow-platform migration

Moving our clients source control and workflow orchestration onto modern, supported platforms: hundreds of repositories from Bitbucket to GitHub, Airflow from 2 to 3, and the Kubernetes infrastructure around it reconfigured in step - all while day-to-day delivery carried on.

• A purpose-built LLM workflow for analysis. No repository estate this size fits in a context window, so it assembled its own per-repository context from code, build configuration and deployment manifests rather than being handed the lot.
• A shared metadata layer underneath it, recording what each repository was and how it related to the others, so a dependency between two repositories was a lookup rather than a guess.
• Deployment methodologies and patterns categorised across the estate, which turned 214 individual migrations into a handful of repeatable shapes.
• The migration itself in plain Python against REST APIs: Bitbucket, GitHub, AWS, Airflow and Snowflake, so every move was scripted, repeatable and reviewable.
• Automated testing after each move and a report per repository, so the client could see it had landed intact rather than take our word for it.
• Clean-up carried along the way: standardised documentation and auth patterns, Python version upgrades, and Kubernetes-layer infrastructure upgrades that improved the platform and made the automation simpler.

• Let the model read, keep the decisions

  The LLM workflow was the only practical way to understand 214 repositories in the time available, but it produced input to a decision rather than the decision. Everything it inferred landed in the shared metadata layer where it could be checked, corrected and reused.

• Categorise before you migrate

  Sorting the estate by deployment methodology first meant we were solving a handful of patterns rather than 214 special cases. Most of the schedule risk disappeared at that point.

• Boring tools for the moving parts

  The analysis was the novel half. The migration was Python calling REST APIs, because the thing that moves 214 repositories should be the thing you can read, rerun and reason about at two in the morning.

• Earn trust through transparency

  With sceptical engineers, a comprehensive validation report per repository did more for credibility than any amount of reassurance. Showing the plan and the safeguards is what changed the conversation.

Hundreds of repositories is a coordination problem wearing a technical costume. Automating the migration was the straightforward half; the work was sequencing it so nobody's Monday got ruined, and earning the trust of engineers who quite reasonably did not want an external team anywhere near their source control. You win that by being visibly careful in public, not by giving assurances in private.