I've gone through such a migration. Huge Go code base distributed across a lot of git repositories had to be moved to a different git host.

It was horrible. A team of people spent weeks. Different projects depended on different versions of the same internal libraries, we had to create a branch for each depended-on commit and make a version of that commit with the new URLs. The expressed goal was to end up with a system that's "exactly the same" as the old, just on a new host. Changing which version of libraries projects depends on would introduce unnecessary risk.

And the result is a code base where bisects are broken and where it's impossible to build an old version of any of the code without a ton of work.

I don't know enough about git but shouldn't you be able to take all your git data (refs, blobs etc) and import it to your destination host and have this work without issues? It might be a lot of data sure but the infra is surely cheaper than multiple weeks of engineering effort

I think is usually a symptom of how hard it is for the organization to do things, the technical side of this is not actually that hard.

I say this because I’ve gone through a few of these, some with monorepos (the easiest, search and replace and you’re done), some not (yes the hardest but you can just vendor).

At least in the situations I’ve faced this was genuinely not horrible beyond just the organization itself being complicated about the solution.

> And the result is a code base where bisects are broken and where it's impossible to build an old version of any of the code without a ton of work.

That makes no sense? As long as you’re using go modules, you can just host an internal go proxy for internal modules similar to proxy.golang.org to archive the old versions, and they won’t depend on the old git host.

Isn’t this exactly why the Go team recommended vendoring deps for years and years before go modules came up? Even now it takes one simple command to vendor them.

> Different projects depended on different versions of the same internal libraries, we had to...

This is one of the main motivations for using a monorepo with all third party dependencies imported all the way in, and only one version for everything.

Of course it causes a whole bunch of other problems and is kinda expensive to scale, so most places won't do it.