何年も動かしてきた古いサーバーと新しい移行先を見比べながら、今あるものを一つずつ書き出して落ち着いて移行の段取りを組んでいる一人運用の保守担当者
レガシー・技術的負債約12分

サーバー移行チェックリスト｜塩漬けサーバーを一人で安全に移す

「このサーバー、いつのOSだっけ……」。 何年も動き続けてきた"塩漬けサーバー"を前に、そろそろ移さないと、とは思う。でも、いざ移行を考えると足がすくみますよね。何がインストールされているのか、どんなジョブが夜中に動いているのか、どこから接続が来ているのか——正確に把握しきれないまま新しい環境に移して、動かなくなったらどうしよう、と。

一人で保守を背負っていると、この「中身がよく分からないものを、止めずに移す」というプレッシャーは、かなり重いものです。誰かに聞けるわけでもなく、失敗すれば全部自分に返ってくる。だから、つい後回しになる。よく分かります。

でも、これは度胸や経験の問題ではありません。移行を「一発勝負」だと思っているから怖いだけです。移行は、いきなり切り替える作業ではなく、①今あるものを知る→②同じものを新しい場所に用意する→③データを移す→④確かめてから切り替える、という順番の作業です。順番があれば、いつでも引き返せます。今日は、その順番を一緒に組み立てましょう。全部を今日やる必要はありません。まず「今、何が動いているか」を1枚に書き出すところからで十分です。

結論：①今あるサーバーで動いているもの（OS・ミドルウェア・アプリ・定期ジョブ・接続元）を1枚に棚卸しし、②新環境に同じ構成を用意して、③データとファイルを移して動作を確認し、④DNS/向き先を切り替える。旧環境はすぐ消さず、戻せる状態でしばらく残す。この「棚卸し→複製→移行→切替→保持」の順で、まずは棚卸しの1枚から始めます。

サーバーの構成やコマンドは、OS・バージョン・クラウド/オンプレによって大きく変わります。本文の手順は自分の環境に読み替えつつ、細かなコマンドや設定は必ず本番反映の前に検証環境と公式情報で確認してください。移行は、確認したぶんだけ安全になります。

なぜ「塩漬けサーバーの移行」で手が止まるのか

どれも「気合いで一気にやる」では解けません。むしろ一気にやろうとするほど、見落としが増えて怖くなります。だから、頭の中でぐるぐる不安を回すのをやめて、書き出す→用意する→移す→確かめるという手を動かす作業に変えていきます。移行は判断ではなく、段取りです。段取りは、小さく分ければ必ず終わります。

手順①：今あるサーバーの中身を1枚に棚卸しする

まずは「移行棚卸し表」を1枚作ります。難しく考えず、次の項目を、分かるものから埋めていきます。ここがいちばん大事な工程です。ここさえ埋まれば、移行の8割は見えたも同然です。

旧サーバーの中身を棚卸しし、同じ構成を新サーバーに用意して、データを移し、向き先を切り替えるという移行の流れを示した図
移行は「棚卸し→複製→移行→切替→保持」の順番。旧環境はすぐ消さず、戻せる形で残しておく。

「今あるものが分からないから移行するのに」と思いますよね。だからこそ、記憶ではなくサーバーに聞くのが確実です。思い出そうとせず、コマンドで現状を吐き出させます（環境により異なるので、自分の系統のものを使ってください）。

とくに見落としやすいのがcronの裏方と外部連携です。画面に出てこないぶん、移し忘れると「移行後しばらくして、月次バッチだけ動いていなかった」といった形で後から気づくことになります。棚卸し表の「定期ジョブ」「外部との接続」の欄は、少し時間をかけて丁寧に埋めておくと、後がずっと楽になります。

手順②：新環境に「同じもの」を用意する

棚卸し表ができたら、それを設計図にして、新しいサーバーに同じ構成を用意します。ここでのコツは、いきなり最新版に上げようとしないことです。

移行と、バージョンアップは、別の作業です。両方を一度にやると、動かなくなったときに「移したせいなのか、上げたせいなのか」が切り分けられなくなります。まずはできるだけ近いバージョンで同じ構成を作り、「同じものが同じように動く」ことを先に確認します。バージョンアップは、移行が落ち着いてから、別の作業として腰を据えて取り組めば大丈夫です。

環境ごとの設定の違いは、移行でいちばん事故が起きやすいところです。接続先・APIキー・デバッグ設定などを、旧環境と新環境で1枚に並べて見比べておくと、切り替え後に「本番だけ設定が違った」という冷や汗を避けられます。この考え方は環境差で事故らない設定管理｜開発・検証・本番を一人運用でに詳しくまとめてあるので、あわせて使ってみてください。

手順③：データとファイルを移す

構成が用意できたら、中身（データ）を移します。ここで大事なのは、移す前にバックアップを取ること、そして件数や容量で「ちゃんと移ったか」を確かめることです。

rsync -av 旧サーバー:/移したいディレクトリ/ /新サーバーの置き場/ のように使い、コピー後は du -sh でディレクトリの容量を新旧で見比べます。数字が大きくずれていたら、途中で失敗しているサインです。移した「つもり」で切り替えてしまうのがいちばん怖いので、移った証拠（件数・容量）を必ず自分の目で確認します。

移行作業中もサービスを止めたくない場合は、「先に大きなデータをコピー→切り替え直前に差分だけもう一度コピー」の2段構えにすると、止める時間を短くできます。

手順④：確かめてから切り替える（戻せる形で）

データが移ったら、まだ本番の向き先は変えずに、新環境が正しく動くかを確認します。切り替えは、確認が終わってからで十分です。

DNSを切り替えるときは、事前にTTL（切り替えが行き渡るまでの時間の設定）を短くしておくと、切り戻しが必要になったときに素早く戻せます。そして切り替え後は、しばらくエラーログとアクセスを見守ります。「切り替えて終わり」ではなく、「切り替えてから数時間〜1日は様子を見る」までが移行です。

もし新環境で問題が出ても、旧環境を残してあれば、DNSを戻すだけで元に戻せます。戻せる状態を先に用意してから切り替える——これが、一人でも落ち着いて移行できる最大のコツです。戻し方の型はロールバック手順の作り方｜すぐ戻せるリリース設計を一人運用での考え方がそのまま使えます。

手順⑤：旧環境は「すぐ消さない」

無事に切り替わっても、旧サーバーはすぐには消しません。しばらくは「戻せる保険」として、止めた状態（または起動したまま向き先だけ外した状態）で残しておきます。

「もう動いているから」とすぐに旧環境を消すと、後から「あの設定、旧サーバーにしか無かった」と気づいたときに手も足も出なくなります。保険は、いらなくなってから外す。それで十分です。

明日やること・チェックリスト

一度に全部やろうとしなくて大丈夫です。まずは棚卸し表の1枚から。上から順に、埋まったものにチェックを付けていってください。

まず今日やること（棚卸し）

移行の準備・実行

切り替えと後片付け

全部に○が付かなくても大丈夫です。まずは棚卸しの6項目だけ埋めれば、移行はもう「よく分からない怖いもの」ではなくなります。あとは、用意して・移して・確かめる——順番にたどれば、いつでも引き返せます。

塩漬けサーバーを前に足がすくむのは、あなたが臆病だからではありません。中身が見えないものを、止めずに移すのが怖いのは当然のことです。だからこそ、まず1枚の棚卸し表で中身を見えるようにする。見えてしまえば、移行は淡々とした段取り作業に変わります。今日はその1枚から。急がなくて大丈夫です。

よければ、こちらも

サーバー移行は、環境の設定・戻せる備え・変更の記録と地続きの仕事です。あわせて整えておくと、移行だけでなく日々のリリースの不安も軽くなります。

移行を無事に終え、新しいサーバーが安定して動いているのを確認して、肩の力が抜けて穏やかな表情になった一人運用の保守担当者

「よく分からないから移せない」と足踏みしていたサーバーも、中身を1枚に書き出してしまえば、あとは用意して・移して・確かめるだけです。戻せる形にしておけば、失敗しても引き返せます。だから、思い切らなくていいのです。 今日は、対象サーバーで何が動いているかを書き出す——その1枚から始めれば十分です。その小さな地図が、ずっと後回しにしてきた不安から、あなたを少しずつ解放してくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語