> Selfhost something like gitea with drone
I actually recently did just that, moving over everything from my self-hosted GitLab instance into Gitea, Drone CI and Nexus: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-... (the same would apply when moving from a cloud GitLab instance to the other self-hosted solutions)
Edit: fixed the link now.
Honestly, it wasn't so bad, given that I didn't couple what I had too tightly to the functionality of GitLab in particular - having an external issue tracker, though moving CI and build artifact storage systems can indeed necessitate porting them over (which was easy, given that I mostly use Dockerfiles and shell scripts for builds anyways) and cause additional work.
> And then set up the users; Then set up the permissions; And move repos to it
Thankfully, nowadays neither is too hard to do, given that there are pretty good migration scripts which will work, unless you're doing something very non-standard and peculiar. I migrated close to a 100 repositories with not a single failure, though perhaps that's also because I don't mess around with Git LFS after being burnt whilst trying to sync GitLab and GitHub repos with LFS data going into a black hole.
> And the hooks; Then set up deployments, figuring out how to replace any missing Gitlab features
The good thing here in particular was the fact that I use Docker for builds as mentioned before, so getting "docker build -t ... -f ... ." working across different build systems is generally pretty easy (except for Jenkins which is needlessly hard sometimes), especially when the software for the CI runner nodes themselves runs in Docker containers (with trusted code you can also just share the Docker socket, otherwise you probably want a DinD setup).
Deployments are also just telling another system (Portainer/Docker Swarm in my case; sometimes Helm for Kubernetes) that it should retrieve the latest build artifacts from some OCI compatible repo and run the new version of the application with any given configuration.
> Then update the docs that describe how the repo structure works for onboarding
I don't think that I've ever actually needed to change this, since while the UI itself does change (e.g. organizations vs groups), the actual contents of a particular repository itself remain the same. Might need to update an URL or two, but for the most part I saw no blockers here.
> Moving infrastructure is a couple of days work at least for a small team. If you factor than cost into it then it's rarely worthwhile.
It took me less than a day, total. But maybe that's because I've built a bit of a pipeline around running containers in my infrastructure and have the ingress/reverse proxy setup around them all established. Not to sound cocky, there are also caveats and things that I do agree with you in regards to pain points (below).
> And that's before any time lost to investigating and fixing outages, updating the software, and so on.
This is probably the bigger issue here, though. All of the sudden, the stability of it all is your responsibility. Now, in my case that wasn't such a change in circumstances because I started out with GitLab and with my limited hardware setup moving over to Gitea and friends was actually a win from a resiliency standpoint vs an integrated GitLab Omnibus install (that loves to eat RAM). For for anyone moving from the cloud to an on-prem infrastructure, this is definitely one of the main concerns.
That said, for many out there storing their code and other stuff in the cloud is a non-starter (e.g. certain government orgs or enterprises), which is where self-hosting can indeed be very helpful, though in most cases I've seen GitLab instances be used instead of Gitea. That said, Gitea is also an excellent option for anyone who just wants to embrace self-hosting out of principle or other reasons.
Being in control of your data is pretty cool (at least until you misconfigure something and everyone is in control of your data). That said, if you don't buy into the balkanization of software platforms nowadays too much and focus on the common standards of the systems instead, overall it's not as painful as one might think.
Of course, you can also pick a platform that's too hard to actually use and administer (which is why I switched away from GitLab) by yourself, but then the question becomes of why you're even using it in the first place. Honestly, GitLab is an excellent platform with amazing features, but handling updates and its hardware requirements wasn't fun: https://blog.kronis.dev/everything%20is%20broken/gitlab-upda...
Oh, also sometimes migrating data can be downright hellish, like when I tried migrating SVN to Git, with migration scripts not working due to non-standard repo layouts, which meant that I had to rewrite the layouts and history on the SVN end so things would actually work properly and those scripts wouldn't hang. Though it was ages ago and I haven't used SVN that much recently, Tortoise SVN was a nice piece of software though, RIP.