移行が終わったら、旧システムは止まる ── はずですが、実際にはなかなか止まりません。「念のため」で動き続け、保守費用と設備費用だけが発生し続けます。
この回は を扱います。技術的には最も簡単な工程ですが、判断としては最も先送りされやすい領域です。
1. なぜ止まらないのか
止まらない理由は、移行が進まない理由（EP.09）と同じ構造をしています。止めないことに、誰も責任を負わないからです。
| 状況 | 起きること |
|---|---|
| 止める条件を決めていない | いつ止めてよいか誰も判断できない |
| 止めた場合の責任が重い | 動かし続ければ何も起きない |
| 費用が見えていない | 止める動機が生まれない |
| まだ使っている人がいるかもしれない | 確認していないので確信が持てない |
| 止める作業の担当がいない | 誰の仕事でもないので進まない |
3行目は見落とされがちです。旧システムの維持費用が、移行後も同じ予算枠で計上され続けていると、誰も気づきません。EP.04 で試算した移行の効果は、旧を止めて初めて実現します。
新旧が両方動いている間、費用は移行前より増えています。移行の投資対効果を計算したときの前提は、旧を止めることでした。止めないなら、その計算は成立していません。
2. 条件を先に決める
対策は単純で、移行の計画時点で止める条件を決めておくことです。後から決めようとすると、決められません。
- 1新側で全機能が動いている — 機能の一覧と、その確認方法
- 2一定期間、新側だけで問題が出ていない — 期間を数字で決める
- 3連携先の切り替えが完了している — EP.07 の一覧で確認
- 4必要なデータを取り出してある — 参照用の形で保全
- 5旧側へのアクセスが一定期間ゼロ — 記録で確認
2番目の期間は、業務の周期に合わせて決めます。月次処理があるなら最低2か月、年次処理があるなら1年。一度も通していない処理がある状態で止めるのは危険です。特に に収まる前提で組まれた夜間処理は、新側で同じ時間内に終わるかを実際の繁忙期で確認しないと分かりません。
5番目は客観的な判断材料になります。EP.07 で扱った記録の仕組みが、ここで直接役に立ちます。「使われていないと思う」ではなく「3か月間アクセスがゼロ」と言えると、判断が進みます。
3. 止める前にデータを取り出す
止めることへの不安の多くは、「後でデータが必要になったら」というものです。ここはシステムを動かし続ける必要はなく、データがあれば足りることがほとんどです。
| 残す形 | できること | 費用 |
|---|---|---|
| システムを動かし続ける | 全部できる | 最も高い |
| DBだけ残す | SQLで参照できる | 中 |
| ファイルに書き出す | 中身は見られる | 最も安い |
| 何も残さない | 何もできない | ゼロ |
3行目で足りることが非常に多い。「過去の取引を確認したい」という要望は、CSV があれば満たせます。システムを動かし続ける必要はありません。逆に「システムがないと確認できない」と言われたときは、具体的にどの画面で何を見るのかを聞いてみてください。多くの場合、データさえあれば別の手段で足ります。
#!/usr/bin/env bashset -euo pipefail
OUT="./legacy_archive_$(date +%Y%m%d)"mkdir -p "$OUT"
# 1. 全テーブルを CSV に書き出すpsql -Atc "SELECT tablename FROM pg_tables WHERE schemaname='public'" \ | while read -r t; do echo "書き出し中: $t" psql -c "\\COPY $t TO '$OUT/${t}.csv' WITH CSV HEADER" done
# 2. 構造も残す（後から意味を調べるときに要る）pg_dump --schema-only > "$OUT/schema.sql"
# 3. 件数を記録する（後から欠損に気づけるように）psql -Atc "SELECT tablename FROM pg_tables WHERE schemaname='public'" \ | while read -r t; do n=$(psql -Atc "SELECT COUNT(*) FROM $t") echo "$t,$n" done > "$OUT/row_counts.csv"
# 4. まとめて固めるtar czf "${OUT}.tar.gz" "$OUT"sha256sum "${OUT}.tar.gz" > "${OUT}.tar.gz.sha256"
echo "完了: ${OUT}.tar.gz"件数を一緒に記録するのが要点です。数年後に「このデータは全部あるのか」と問われたとき、記録がなければ答えられません。取り出した時点の件数があれば、突き合わせで確認できます。
構造も残してください。列名だけでは意味が分からなくなります。EP.08 で扱った「業務上の意味」と同じで、時間が経つほど復元が難しくなる種類の情報です。
4. 段階的に止める
いきなり削除しないでください。止める → 様子を見る → 撤去するという段階を刻みます。
| 段階 | やること | 戻せるか | 期間の目安 |
|---|---|---|---|
| 書き込み停止 | 参照だけ可能にする | すぐ戻せる | 数週間 |
| アクセス遮断 | 接続を遮断（起動はしたまま） | すぐ戻せる | 数週間〜 |
| 停止 | サービスを止める | 起動すれば戻る | 数か月 |
| 撤去 | 環境を削除する | 戻せない | — |
2番目の「アクセス遮断」が効きます。動いてはいるが、繋がらないという状態にすると、まだ使っている人がいれば必ず連絡が来ます。しかも遮断を解除すればすぐ戻せるので、リスクが低い。
各段階の前に、予告期間を設けてください。「◯月◯日に接続を遮断します」と周知しておけば、心当たりのある人から連絡が来ます。予告なしに止めると、業務が止まってから発覚します。
5. 撤去のときに一緒にやること
最後の撤去では、システム本体以外も忘れずに処理します。ここが漏れると、後で費用や事故の原因になります。
- 契約の解約 — 保守契約、ライセンス、回線
- 認証情報の無効化 — アカウント、鍵、証明書（引き継ぎ EP.01 参照）
- 通信の許可設定を消す — 使わない経路を開けたままにしない
- 監視の停止 — 止めたシステムの警報が鳴り続けないように
- バックアップの停止 — 取り続ける必要がなくなる
- 記録の更新 — 構成図や一覧から消す
1番目が金額として最も大きい。保守契約が自動更新のまま残っているというのは実際によくあります。撤去の作業項目に、契約の確認を必ず入れてください。契約は技術部門の管轄外であることが多く、誰も見ていないまま更新され続けます。止めた事実を、契約を管理している部門へ確実に伝える経路を用意しておいてください。
4番目も実務的です。止めたシステムの監視が生きていると、警報が鳴り続け、やがて誰も見なくなります。これは LLM時代のテスト戦略 EP.11 で扱った「赤に慣れる」のと同じ構造で、他の本物の警報まで無視されるようになります。
6. 止めた記録を残す
止めたら、何をどう止めたかを記録します。数年後に「あのシステムのデータはどこ？」と問われたときに答えられるように。
- 1いつ止めたか — 各段階の日付
- 2なぜ止めてよいと判断したか — 満たした条件
- 3データはどこにあるか — 保管場所と、取り出し方
- 4何を解約したか — 契約の一覧
- 5引き継いだ先 — その機能はいま新側のどこか
5番目が意外に重要です。「昔このシステムがやっていた処理は、いまどこにあるのか」という問いは、数年後に必ず出ます。対応関係を残しておかないと、また考古学を始めることになります。
移行の効果は、旧を止めるまで出ない。止める条件は移行の計画時に決めておく（後からは決められない）。不安の多くはデータを取り出せば解消する（システムを動かし続ける必要はない）。止め方は書き込み停止 → 遮断 → 停止 → 撤去と段階を刻み、各段階の前に予告する。撤去時は契約の解約と監視の停止を忘れずに。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。