Start with the case, not the tooling
When we were first engaged, the agency was relying on a source-control system that had served its purpose for years and long since become a constraint. Merging concurrent changes was cumbersome, new developers struggled, and the tool barely spoke to the Jira instance the whole organisation lived in.
Everyone in the room knew Git was the answer. That was not the problem. The problem was that a team of experienced developers had built their working lives around the old tool's quirks, and "the industry has moved on" is not a reason anyone finds motivating.
So before touching a single repository, we wrote the case down. Not a slide deck. A document the whole team could read at their desk that set out, in their terms, what Git would give them: cheap branching, offline commits, feature isolation, faster merges, and integration with Jira. It also set out the risks honestly, and how a phased migration with dual running would contain them.
That document did more for adoption than any tool did.
Pick the tooling the team already lives next to
We recommended Bitbucket Server because the agency already tracked its work in Jira. That single decision meant every commit, branch and pull request could be linked to a ticket, which gave the team a traceability benefit on day one and made the migration feel like a natural extension of how they already worked.
The best tool is usually the one that fits what the organisation already trusts.
Design a branching model people can hold in their head
Git Flow is a good starting point and a bad finishing point. We adapted it to the agency's actual release rhythm: feature branches, a develop line, release branches and a hotfix path, with as few rules as we could get away with. If a developer could not draw the model on a whiteboard from memory, it was too complicated.
We also wrote down the conventions that make a model work: commit message shape, when to rebase and when to merge, what a pull request needs before review. Small things, but they are what stop a clean model from decaying in month two.
Train weekly, hands on, on their code
Training was the heart of the programme. Weekly sessions over six to eight weeks, starting with fundamentals and building to branching, merging, rebasing and conflict resolution. Every session was practical, in sandbox repositories built from the team's own code, so the exercises looked like Tuesday afternoon rather than a tutorial.
The fears were the usual ones. The command line looks intimidating. Merge conflicts are frightening. Will we lose our history? Each was addressed by doing the scary thing in a safe place until it was boring.
Migrate in phases, preserve everything
Repositories moved one at a time, lowest risk first, with full history preserved and dual running while developers adjusted. Preserving history was non-negotiable, and being able to show the team that every commit had made the journey removed the last serious objection.
By the time the critical financial applications moved, the process was routine.
Name a champion
For the life of the programme, one Booolean engineer was the Git champion: the person who answered every "how do I..." in the moment, unblocked whoever was stuck, and quietly fixed the mistakes people were embarrassed to ask about. That role is the difference between a team that is trained and a team that is confident.
What changed
Within three months the agency was fully operating on Git. Developers worked in parallel without fear, code review happened through pull requests linked to Jira, and the environment was ready for CI/CD and the cloud work that followed. The team had modern, transferable skills, and a workflow they owned.
When a developer really gets the taste of Git, they do not switch back.
If you are planning the same move
- Write the case in your team's language before you choose a tool.
- Choose hosting that fits what the organisation already uses.
- Design the simplest branching model that fits your release rhythm, and write down the conventions.
- Train weekly, hands on, on your own code.
- Migrate in phases, lowest risk first, and preserve history.
- Name a champion and keep them available.
Booolean runs this as a service. Read Git migration and delivery modernisation, or see the case study.