The situation
The agency's software teams depended on a legacy source-control system that had served its purpose and long since become a constraint. Merging concurrent changes was cumbersome, new developers struggled to become productive, the tool had little integration with the project-tracking system the teams lived in, and with twenty-plus applications under management it was showing its limits.
Booolean was engaged to help the agency modernise how its software was delivered. The review quickly showed that source control was the foundation everything else depended on.
Making the case
Git was already the industry standard, but many of the team had used the existing system for years and were understandably cautious. Before any tooling was touched, Booolean prepared a written case the whole team could read:
- the benefits of Git in their terms: distributed work, cheap branching, faster merging, offline commits, and the ability to develop features in isolation and release them independently;
- how other organisations had made the same move;
- the risks, and how phased migration, training and dual running would contain them.
We recommended Bitbucket Server as the in-house Git host, because the agency already tracked its work in Jira. Linking commits, branches and pull requests directly to tickets gave the team traceability they had never had, and made the move feel like a natural progression rather than an upheaval.
The programme
| Phase | What happened |
|---|---|
| Assessment and inventory | Every repository and application catalogued, with dependencies, build pipelines and release cycles mapped. |
| Tooling | Bitbucket Server deployed and configured in-house and integrated with Jira. |
| Workflow design | A branching model inspired by Git Flow, adapted to the agency's release rhythm, with feature branches, release branches and hotfix paths the team could hold in their head. |
| Training | Weekly hands-on sessions over six to eight weeks, from fundamentals through branching, merging and conflict resolution, practised in sandbox repositories. |
| Phased migration | Repositories moved one at a time, lowest risk first, with full history preserved and dual running while developers adjusted. |
| Culture | Daily commits, pull-request review and collaboration over siloed work, reinforced by a named Booolean Git champion who answered every question. |
Overcoming resistance
The concerns were the usual ones: the Git command line looks intimidating, merge conflicts are frightening, and nobody wants to lose history. Each was addressed directly. Workshops used the team's own code. Step-by-step documentation stayed available after the sessions. Every migration preserved the complete history of the repository, and the team could verify that themselves.
By the end of training, developers who had been anxious about merge conflicts were confidently branching, rebasing and reviewing each other's work.
The outcome
Within three months the agency was fully operating on Git in Bitbucket Server. Every project, from small internal tools to the critical financial applications, had been migrated with its history intact.
- Developers could work in parallel on multiple branches without fear of losing work.
- Pull-request review and Jira integration gave every change a traceable path from ticket to release.
- The environment was ready for CI/CD and the cloud-native work that followed.
- The team had modern, transferable skills, and a workflow they owned.
The lesson we took away: convince people first, migrate second. The technical migration was the easy part. The programme succeeded because the team understood why it was happening and had someone beside them while they learned.
What this means for your organisation
If your teams are on TFS, SVN or something older, the path is well understood. Read how we run it in Git migration and delivery modernisation, or read the longer story in Moving a government agency to Git.