GitLab 12.9.2迁移至GitLab 14.2的仓库迁移路径有哪些？

以下两个方案均可以避免逐个导入带来的层级、权限匹配错误问题：

优先方案：旧实例先升级到目标版本再全量迁移 #

这个方案可以100%保留所有分组层级、用户权限、项目数据，操作复杂度远低于批量导入导出：

• 先找一台不影响线上业务的临时服务器，将原12.9.2版本的全量备份恢复到临时服务器，和原实例保持完全一致的运行状态。
• 按照官方标准升级路径逐步将临时服务器的GitLab升级到14.2版本，升级路径固定为 12.9.2 → 12.10.z → 13.0.z → 13.12.z → 14.0.z → 14.1.z → 14.2.z，每个节点只升级对应大版本的最新小版本即可，升级过程中GitLab会自动完成数据库schema适配，不需要你手动处理低版本PostgreSQL的数据问题。
• 临时服务器升级完成后，执行内置备份命令 gitlab-backup create 生成14.2版本兼容的全量备份包。
• 在目标服务器B上安装完全相同版本的GitLab CE 14.2，停止业务侧服务 gitlab-ctl stop puma sidekiq 后执行 gitlab-backup restore 即可完成全量数据恢复，所有原有层级、权限关系完全不会错乱。

备选方案：批量导出导入 #

如果没有条件做旧实例升级，可以用官方API批量操作，避免手动逐个导入：

• 先用 python-gitlab 等SDK调用旧实例的导出接口，批量导出所有用户、分组、项目数据，分组导出会自带层级关系，项目导出包含所有代码、提交记录、基础配置。
• 在新实例上先批量创建用户，再从上到下按层级导入分组，最后将项目导入到对应分组下，只要严格按照「用户→分组→项目」的顺序操作，就能完全保留原有权限配置，700个仓库的批量操作半小时内即可完成。

操作前务必对原实例做一次完整的离线备份，避免操作失误导致数据丢失。

内容的提问来源于stack exchange，提问作者Yamil Ortega