Listen to this article
AI may have been used to generate this audio.
Press Space or K to play or pause, and J or L to go back or forward 15 seconds.An "Ask HN" thread collecting alternatives to GitHub went wide this week. The trigger was the outage. The question underneath it is much older, and it goes well beyond hosting.
Most of the answers were about features and pricing. The replies from people who had migrated were better, because they all described the same surprise.
Git is portable by design. That was the entire point of it. You can clone the whole history onto a laptop and walk out of the building with it.
Everything that grew around it stays behind: the review conventions nobody wrote down, the issue taxonomy that made sense in 2021 and has been load-bearing ever since, and the CI configuration that quietly encodes six years of hard-won knowledge about which tests are flaky and why, in the form of retries nobody dares remove.
So teams discover mid-migration that a surprising amount of their engineering practice was stored in a vendor's UI affordances. It is a memory problem. The practice was never written anywhere a human could read it independently of the tool enforcing it.
There is a cheap way to find out how much of this applies to you, and it costs an afternoon.
Ask someone to describe your team's path from a merged pull request to production, without opening the tool. Where they hesitate is where the knowledge has been externalised.
The same spot is where onboarding is slowest. A new joiner learns a UI affordance only by being shown it, which means that knowledge transfers at the speed of somebody else's availability, and it disappears entirely when that somebody changes team.
The concentration is usually a rational trade, and staying is often the right call. You get an enormous amount of working practice for free, and rebuilding it yourself would be a poor use of a decade.
Know which parts of your practice you could carry out by hand, and accept that the rest is rented. That is a fine position, as long as you made that decision yourself before a migration makes it for you.
Write down the five paths that would hurt most to lose (deploy, rollback, release, access review, incident escalation) as instructions a competent person could follow from a plain document.
Do it even if you plan to stay. Writing it down is the only reliable way to find out that three of the five live entirely inside one person's habits.
One email when we publish. Research, product decisions, and what teams report back.
