今回はGitLabの引っ越し＆アップグレードの際に環境によって発生した問題とその解決法です。
（GitLabについての説明は割愛します）
なお手元の環境はDockerイメージを使っているのですが、そのことは事態にさほど影響しません。
7→8／8→9の間にそれぞれパラメータ類が増加しているので、それにあわせた対処は必要なわけですが、どの方法（Omnibus Packages／ソースインストール／Dockerイメージ）であっても、公式マニュアルを見れば進められます。
今回ご紹介したい件はもうちょっとややこしい内容でして、そもそもどのパッケージを使っても7→8のアップグレードができないパターンがあるというものです。
発生条件は次の通り：
・DBにMySQLを使っている
・MySQLのGTIDがONになっている
というものです。
GTIDについてご存知の方はもうこの時点でピンとくると思うのですが、GitLabの7→8のマイグレーションにCREATE TABLE ... SELECT文が使われているのです。
これはGTIDをONにした場合に使用できなくなるのですよね…。
https://dev.mysql.com/doc/refman/5.6/ja/replication-gtids-restrictions.html
なおこの問題についてはパッチがマージリクエストされているのですが、CREATE TABLE ... SELECTをCREATE TEMPORARY TABLE ... SELECTに書き換えるというものなので、こんどは一時テーブル関連の設定にひっかかる可能性が指摘されています。
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2081
さてではどうするかということになりますが、単純に考えると、次のような手段が可能じゃないかな？と考えられます
・別環境を用意（＋GTIDを使用していないMySQL）
・別環境でマイグレーションを実行し、そのDBのダンプを取る
・ダンプを元DBに投入
・元環境でマイグレーション実行
当然ながら、何かしら想定外の問題が出そうなので、さらに別環境を用意して検証します。
検証の結果とくに問題は出なかったので、上記の方法で正常に7→8アップグレードを完了させました。
（なおこの後、元の環境で8→9へのアップグレードは問題なく完了しました）
フレームワークやミドルウェアによってはDB上のバージョンナンバーだけでアップグレードをスキップしてしまったりしますが、GitLabはDBだけ新しくなっていてもちゃんとソースコード側もアップデートされるようで安心しました。