The solution I use is to have all Jenkins config and pipelines in DSL (CasC does it for Jenkins, plus seed jobs, plus Groovy pipelines.) Once you have that, it becomes trivial to bring up an additional instance of Jenkins that looks exactly like your current one. You can check your pipelines there for a while, or rsync the build history and switch over to a new instance with a DNS update. Once you reach this point, it ceases to matter how many instances you have, you can have as many or as little as you want.
It's miles better than Jenkins and the horrors people created there. GitLab CI can at least be easily migrated to any other GitLab instance and stuff should Just Work because it is in the end not much more than self contained bash scripts, but Jenkins... is a clown show, especially for Ops people of larger instances. On one side, you got 50 plugins with CVEs but you can't update them because you need to find a slot that works for all development teams to have a week or two to fix their pipelines again, and on the other side you got a Jenkins instance for each project which lessens the coordination effort but you gotta worry about dozens of Jenkins instances. Oh and that doesn't include the fact many old pipelines aren't written in Groovy or, in fact, in any code at all but only in Jenkins's UI...
Github Actions however, I'd say for someone coming from GitLab, is even worse to work with than Jenkins.