Moving a 20-year-old SaaS product onto GitHub

Lessons learned moving source code, development workflows and operations into the GitHub ecosystem.

---

Plenty of software companies still run on the tooling of the 2000s. Lock-based version control in SourceGear Vault, notes in OneNote, a homegrown work tracker, manual builds and deployments. It all works, in the sense that software ships and customers are happy. A current engagement involves moving a small team, and their mature B2B SaaS product, off exactly that setup and onto GitHub. Source code, per-client configuration, work tracking, support and documentation, all of it. Copying the files across was the quick part. Nearly all the effort since has gone into how the team operates.

Why teams finally move

A change like this usually has several drivers converging. Here the strongest were customer requests for SOC 2 compliance and a growing awareness that a wider modernisation needed to start soon. A more modern operating model with automation built in was a route to the first and groundwork for the second. Reducing manual overhead mattered too, as did the simple fact that modern development tooling assumes Git underneath. The wider industry settled the question some time ago. In Stack Overflow’s 2022 developer survey, around 96% of professional developers reported using Git. Tools worth adopting, AI coding assistants among them, are built on that assumption.

Why Vault worked for so long

Vault, at least as this team used it, follows the lock-modify-unlock model it inherited from Visual SourceSafe. Check a file out, lock it, make the change, check it back in. Edits never collide because nobody else can edit. A checked-out file also tells the whole team who’s working on what, so the tool quietly handles coordination too. It’s genuinely easy to understand, and it served a small team well for two decades.

Git takes the copy-modify-merge approach. Every developer holds a complete copy of the repository, work happens on branches, and merging reconciles parallel changes. For developers who’ve spent a career with locks, that’s a genuine conceptual shift, and treating it as a quick training exercise underestimates it. Something real is lost in the move, too. Vault’s mental model was simpler. The payoff arrives elsewhere, in review, automation and the audit trail.

The end of editing in place

The largest workflow change sat beside version control rather than inside it. Client configuration work used to happen directly on a shared development server, a developer connecting over RDP and editing live, with locks doing the coordination. A distributed model ends that. Each developer now works on their own copy of the configuration repo, which only makes sense if they can also see their changes running. So each developer needs a personal preview environment, their own copy of a client site, wired up to configuration held in a separate repository.

Designing that workflow took more thought than anything involving Git itself, and it proved the most sensitive part of the move. The old way of working had been in place for years, and whatever replaced it would shape somebody’s entire working day. So the design started with interviews rather than a proposal. The person who does most of the client configuration, the person who runs operations, developers who’d worked on the system in earlier years. Each saw the workflow from a different angle, and each knew details the others didn’t.

From there it was brainstormed into shape over several rounds, until a workflow emerged that was fit for purpose without adding unnecessary overhead. It’s the kind of detail that sometimes doesn’t appear on a migration checklist.

Boundaries and pipelines

Client configurations previously lived together in one large repository. They’ve been split so each client’s configuration is a repository of its own, a clear boundary that deploys to its own environment.

Feature branches deploy to a development environment, main deploys to staging, and a release tag deploys to live. Main is protected, so every change arrives through a pull request and gets reviewed before it’s merged. For a team that had never raised a pull request, that’s a whole new development cycle, and the pipeline enforces it rather than a document asking politely.

Work and support in the same place

The homegrown tracker and OneNote are retiring in favour of GitHub Issues and Projects. An inbound support email now becomes a ticket automatically, so customers notice very little while everything behind the scenes changes.

A custom tracker fits a team precisely because it grew up alongside them, and some of that tailoring is gone. GitHub’s tools are more generic. The compensation is that tickets, work items, code changes, reviews and releases now live in one system and link to each other.

An audit trail as a by-product

The product serves a compliance-heavy domain, and audit trails used to be assembled by hand across several disconnected systems. Tedious, slow and easy to get wrong. In the new setup, a ticket links to a branch, the branch to a pull request, the pull request to a review and a release tag, and the tag to a deployment. The audit trail assembles itself as a side effect of doing the work, and it’s much of what a SOC 2 conversation needs. Of everything in the migration, that’s probably the change with the most lasting value.

Budget for the operating model

For teams planning a similar move, the file migration is the smallest line in the budget. Most of the effort goes on designing branching, deployment and release workflows, and documenting them properly. The most expensive line is the mental shift, taking developers from a lock-based world to a distributed one. That’s also where the value is. What the business ends up with is a more automated, more connected way of operating, and a team that understands why.

That understanding needed to be earned. To a small team, branching and pull requests can look like unnecessary overhead, so it proved important to set out the benefits beyond supporting multiple developers. Seeing those written down gave the team its motivation for the change.

• Every change carries a connected ticket-to-deployment history, which helps demonstrate the effort that goes into quality.
• A pull request is a worthwhile quality gate even for a single developer, and a natural place to keep a record of testing.
• The model is what CI/CD expects, and automated testing and deployment are next on the list.
• The main branch always stays deployable, or at least the process exists to protect that assumption.
• Squash merging keeps history clean. Each branch is merged into main as a single tidy commit and is then deleted, with the pull request holding the detailed record.
• Expensive automated tests can run when a pull request merges rather than on every small commit to a branch.

The GitHub move is also groundwork rather than an end point. A larger migration is now underway, taking the product from virtual servers onto Azure App Services for automated deployments and resilience, and it involves significant code changes. That platform should make client config editing smoother still, so the preview workflow designed here will be revisited once it’s in place.

Businesses planning a similar move can start with a short exploratory conversation.

References

• Stack Overflow Developer Survey 2022, version control, Stack Overflow
• GitHub flow, GitHub Docs
• About protected branches, GitHub Docs
• About Projects, GitHub Docs