システム移行計画書の書き方｜目次テンプレートと切り戻し判断基準

システム移行計画書とは、旧システムから新システムへ「何を・いつ・だれが・どの順番で」移し、うまくいかないときに「いつ・だれの判断で」元に戻すかを、関係者全員で合意するための文書です。 移行は一度きりの作業になりやすいため、手順だけでなく、判定の時刻と基準を前もって決めておくことが大切です。

この記事では、移行方式（一括・段階・並行稼働）の比較表、移行計画書の目次テンプレート、そして架空の「社内備品管理システム」を例にした記入例（RACI体制表・スケジュール・移行対象一覧・リハーサル計画・当日のタイムチャート・Go/No-Goと切り戻し判定表）を載せます。さらに、PostgreSQL 16.15 で旧テーブルから新テーブルへ移行SQLを実行し、件数・合計値・md5ハッシュで一致を確かめる検証SQLと、その実行結果（不一致を検出した例を含む）も掲載しています。

移行計画書に書く項目の早見表

特に「判定時刻・判定者・条件」の3点を数字と名前で書いておくと、当日に迷わず判断できます。

移行方式の比較：一括・段階・並行稼働

移行方式は「業務を止められる時間」と「旧システムをいつまで動かせるか」で選ぶのが基本です。

どの方式でも、移行計画書には「選んだ理由」を1〜2行で書いておくと、後から見た人が前提を理解できます。

移行計画書の目次テンプレート

そのままコピーして使える目次です。各章に何を書くかを <!-- --> で添えています。

# {システム名} 移行計画書

版：1.0（{作成日}） 作成：{担当}

## 1. 目的と範囲
<!-- 移行の目的、対象システム、対象外、前提条件 -->
## 2. 移行方式
<!-- 一括/段階/並行稼働、選んだ理由、停止できる時間 -->
## 3. 体制と役割（RACI）
<!-- 作業ごとの R/A/C/I、判定者、連絡先 -->
## 4. スケジュール
<!-- 準備、リハーサル、本番、安定化、旧システム停止 -->
## 5. 移行対象一覧
<!-- データ、プログラム、設定、アカウント、外部連携、帳票 -->
## 6. データ移行手順
<!-- 抽出、変換ルール、投入、検証、所要時間 -->
## 7. 移行検証
<!-- 件数・合計値・ハッシュ、画面での確認、合格条件 -->
## 8. リハーサル計画
<!-- 回数、確認内容、合格条件、手順書への反映 -->
## 9. 当日のタイムチャート
<!-- 時刻、作業、担当、判定ポイント -->
## 10. Go/No-Go 判定と切り戻し
<!-- 判定時刻、判定者、条件、切り戻し手順と所要時間 -->
## 11. リスクと対策
## 12. 連絡・周知
<!-- 利用者への告知、当日の連絡ルート、問い合わせ窓口 -->
## 13. 移行後の安定化と旧システムの停止
<!-- 監視強化の期間、旧システムのデータ保管期間 -->
## 付録
<!-- 作業手順書、検証SQL、連絡先一覧 -->

当日の細かいコマンド手順は「作業手順書」として別にし、移行計画書は「全体の段取りと判断の基準」に絞ると、読みやすさと更新のしやすさが両立します。リリース作業の手順書の書き方は「リリース手順書の書き方｜切り戻し付きテンプレートと判定表」の記事で解説しています。

記入例：社内備品管理システムの移行

ここからは、架空の「社内備品管理システム」を例に、主な章を埋めていきます。

• 旧システム：社内サーバー上の業務アプリ（データベースはPostgreSQL）
• 新システム：クラウド上の新しい備品管理アプリ（データベースはPostgreSQL）
• 方式：一括移行（理由：利用者は全社員だが操作は単純で、土日の36時間で移行と検証が終わることをリハーサルで確認できる見込みのため）
• 停止時間：金曜18:00〜月曜6:00（予備を含む）

3. 体制と役割（RACI）

RACIは、作業ごとに R（実行する人）、A（最終責任者。1人だけ）、C（事前に相談する人）、I（結果を報告する人）を割り当てる表です。

判定者（A）は氏名と当日の連絡手段まで書き、不在時の代理も決めておくと、判断が止まりません。

4. スケジュール

5. 移行対象一覧

「移行しないもの」も一覧に書くと、移行後に「あのデータはどこ？」という問い合わせに答えやすくなります。

データ移行手順と検証（PostgreSQLで実行）

ここでは、データ移行の中心となる「変換して投入し、一致を確かめる」部分を、PostgreSQL 16.15 で実際に動かした結果とともに示します。旧テーブル（old スキーマ）と新テーブル（new スキーマ）を1つのデータベースに用意していますが、別サーバーの場合も、検証SQLの考え方は同じです。

旧テーブルと新テーブル

-- 旧システム（移行元）
CREATE SCHEMA old;
CREATE TABLE old.equipment (
  eq_cd       varchar(10) PRIMARY KEY,   -- 備品コード（例 EQ00001）
  eq_name     varchar(100) NOT NULL,     -- 前後に空白が入っていることがある
  category_cd char(2)      NOT NULL,     -- 01:PC 02:モニター 03:家具
  price       numeric(10)  NOT NULL,     -- 購入金額（円）
  purchased   char(8)      NOT NULL,     -- YYYYMMDD。不明は '00000000'
  del_flg     char(1)      NOT NULL      -- '0':有効 '1':削除済み
);
CREATE TABLE old.loan (
  loan_no    integer PRIMARY KEY,
  eq_cd      varchar(10) NOT NULL,       -- 一部が小文字で入っている
  emp_cd     varchar(8)  NOT NULL,
  loan_ymd   char(8)     NOT NULL,
  return_ymd varchar(8)  NOT NULL        -- 未返却は ''
);

-- 新システム（移行先）
CREATE SCHEMA new;
CREATE TABLE new.category (code text PRIMARY KEY, name text NOT NULL);
INSERT INTO new.category VALUES ('01', 'PC'), ('02', 'モニター'), ('03', '家具');
CREATE TABLE new.equipment (
  id             bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  code           text NOT NULL UNIQUE,
  name           text NOT NULL,
  category_code  text NOT NULL REFERENCES new.category(code),
  purchase_price numeric(12) NOT NULL CHECK (purchase_price >= 0),
  purchased_on   date,                   -- 不明は NULL
  is_deleted     boolean NOT NULL
);
CREATE TABLE new.loan (
  id            bigint PRIMARY KEY,      -- 旧 loan_no を引き継ぐ
  equipment_id  bigint NOT NULL REFERENCES new.equipment(id),
  employee_code text NOT NULL,
  loaned_on     date NOT NULL,
  returned_on   date                     -- 未返却は NULL
);

テストデータは generate_series で備品10,000件・貸出50,000件を作りました。50件に1件は名前の前後に空白、97件に1件は購入日 '00000000'、貸出の40件に1件は備品コードが小文字、7件に1件は未返却（''）という、移行でつまずきやすい形をわざと混ぜています。

INSERT INTO old.equipment
SELECT 'EQ' || lpad(g::text, 5, '0'),
       CASE WHEN g % 50 = 0 THEN ' ノートPC ' || g || ' ' ELSE '備品' || g END,
       lpad((g % 3 + 1)::text, 2, '0'),
       (g % 200 + 1) * 1000,
       CASE WHEN g % 97 = 0 THEN '00000000'
            ELSE to_char(date '2020-01-01' + (g % 2000), 'YYYYMMDD') END,
       CASE WHEN g % 20 = 0 THEN '1' ELSE '0' END
FROM generate_series(1, 10000) AS g;

INSERT INTO old.loan
SELECT g,
       CASE WHEN g % 40 = 0 THEN lower('EQ' || lpad((g % 10000 + 1)::text, 5, '0'))
            ELSE 'EQ' || lpad((g % 10000 + 1)::text, 5, '0') END,
       'E' || lpad((g % 300)::text, 5, '0'),
       to_char(date '2024-01-01' + (g % 600), 'YYYYMMDD'),
       CASE WHEN g % 7 = 0 THEN ''
            ELSE to_char(date '2024-01-01' + (g % 600) + 14, 'YYYYMMDD') END
FROM generate_series(1, 50000) AS g;

移行SQL（03_migrate.sql）

変換ルールは移行計画書の「6. データ移行手順」に表で書き、SQLはその表どおりに作ると、レビューしやすくなります。

BEGIN;
INSERT INTO new.equipment (code, name, category_code, purchase_price, purchased_on, is_deleted)
SELECT eq_cd,
       btrim(eq_name),
       category_cd,
       price,
       CASE WHEN purchased = '00000000' THEN NULL ELSE to_date(purchased, 'YYYYMMDD') END,
       del_flg = '1'
FROM old.equipment
ORDER BY eq_cd;

INSERT INTO new.loan (id, equipment_id, employee_code, loaned_on, returned_on)
SELECT l.loan_no,
       e.id,
       l.emp_cd,
       to_date(l.loan_ymd, 'YYYYMMDD'),
       CASE WHEN l.return_ymd = '' THEN NULL ELSE to_date(l.return_ymd, 'YYYYMMDD') END
FROM old.loan AS l
JOIN new.equipment AS e ON e.code = upper(btrim(l.eq_cd));
COMMIT;

検証SQL（04_verify.sql）：件数・合計値・ハッシュで突き合わせる

件数だけでは「中身の変化」を見落とすことがあるため、合計値と全列のハッシュも比べます。 ハッシュは、各行を | でつないだ文字列を主キー順に並べて連結し、md5 をとったものです（並び順が違うと一致しないため、両側で同じキー順にします）。旧側は「変換ルールを当てはめた後の期待値」として計算します。

WITH chk(no, item, old_value, new_value) AS (
  SELECT 1, '備品 件数',
         (SELECT count(*) FROM old.equipment)::text,
         (SELECT count(*) FROM new.equipment)::text
  UNION ALL
  SELECT 2, '備品 購入金額合計',
         (SELECT sum(price) FROM old.equipment)::text,
         (SELECT sum(purchase_price) FROM new.equipment)::text
  UNION ALL
  SELECT 3, '備品 有効件数',
         (SELECT count(*) FROM old.equipment WHERE del_flg = '0')::text,
         (SELECT count(*) FROM new.equipment WHERE NOT is_deleted)::text
  UNION ALL
  SELECT 4, '備品 全列ハッシュ',
         (SELECT md5(string_agg(concat_ws('|', eq_cd, btrim(eq_name), category_cd, price,
                                          coalesce(nullif(purchased, '00000000'), ''),
                                          del_flg = '1'),
                                E'\n' ORDER BY eq_cd))
            FROM old.equipment),
         (SELECT md5(string_agg(concat_ws('|', code, name, category_code, purchase_price,
                                          coalesce(to_char(purchased_on, 'YYYYMMDD'), ''),
                                          is_deleted),
                                E'\n' ORDER BY code))
            FROM new.equipment)
  UNION ALL
  SELECT 5, '貸出 件数',
         (SELECT count(*) FROM old.loan)::text,
         (SELECT count(*) FROM new.loan)::text
  UNION ALL
  SELECT 6, '貸出 未返却件数',
         (SELECT count(*) FROM old.loan WHERE return_ymd = '')::text,
         (SELECT count(*) FROM new.loan WHERE returned_on IS NULL)::text
  UNION ALL
  SELECT 7, '貸出 全列ハッシュ',
         (SELECT md5(string_agg(concat_ws('|', loan_no, upper(btrim(eq_cd)), emp_cd, loan_ymd, return_ymd),
                                E'\n' ORDER BY loan_no))
            FROM old.loan),
         (SELECT md5(string_agg(concat_ws('|', l.id, e.code, l.employee_code,
                                          to_char(l.loaned_on, 'YYYYMMDD'),
                                          coalesce(to_char(l.returned_on, 'YYYYMMDD'), '')),
                                E'\n' ORDER BY l.id))
            FROM new.loan AS l JOIN new.equipment AS e ON e.id = l.equipment_id)
)
SELECT no, item, old_value, new_value,
       CASE WHEN old_value IS NOT DISTINCT FROM new_value THEN 'OK' ELSE 'NG' END AS result
FROM chk
ORDER BY no;

実行結果1：紐付けで大文字・小文字をそろえなかった場合

最初に、貸出の紐付けを ON e.code = l.eq_cd（大文字にそろえない）にして実行した結果です。

BEGIN
INSERT 0 10000
INSERT 0 48750
COMMIT
 no |       item        |            old_value             |            new_value             | result
----+-------------------+----------------------------------+----------------------------------+--------
  1 | 備品 件数         | 10000                            | 10000                            | OK
  2 | 備品 購入金額合計 | 1005000000                       | 1005000000                       | OK
  3 | 備品 有効件数     | 9500                             | 9500                             | OK
  4 | 備品 全列ハッシュ | 49fa1437f3ae05bfc445ac16a824c9c2 | 49fa1437f3ae05bfc445ac16a824c9c2 | OK
  5 | 貸出 件数         | 50000                            | 48750                            | NG
  6 | 貸出 未返却件数   | 7142                             | 6964                             | NG
  7 | 貸出 全列ハッシュ | 97ce7d630ec24f991535529b186215c6 | b5c1f43eb5c233636043d34946694ea5 | NG
(7 rows)

SQLはエラーにならずに完了し、1,250件が静かに抜け落ちました。 JOIN（内部結合）は相手が見つからない行を結果に含めないためです。差分を調べるSQLで原因がすぐわかります。

SELECT l.loan_no, l.eq_cd
FROM old.loan AS l
WHERE NOT EXISTS (SELECT 1 FROM new.loan AS n WHERE n.id = l.loan_no)
ORDER BY l.loan_no
LIMIT 3;

 loan_no |  eq_cd
---------+---------
      40 | eq00041
      80 | eq00081
     120 | eq00121
(3 rows)

抜けた1,250件はすべて備品コードが小文字の行でした。upper(btrim(l.eq_cd)) で紐付けると解消します。

実行結果2：件数は合っているのに中身が違う場合

次は、紐付けは直したうえで、名前の空白除去（btrim）を入れ忘れた場合です。

 no |       item        |            old_value             |            new_value             | result
----+-------------------+----------------------------------+----------------------------------+--------
  1 | 備品 件数         | 10000                            | 10000                            | OK
  2 | 備品 購入金額合計 | 1005000000                       | 1005000000                       | OK
  3 | 備品 有効件数     | 9500                             | 9500                             | OK
  4 | 備品 全列ハッシュ | 49fa1437f3ae05bfc445ac16a824c9c2 | 5d4176c42ed46cf30d21ce7f4bc9aa41 | NG
  5 | 貸出 件数         | 50000                            | 50000                            | OK
  6 | 貸出 未返却件数   | 7142                             | 7142                             | OK
  7 | 貸出 全列ハッシュ | 97ce7d630ec24f991535529b186215c6 | 97ce7d630ec24f991535529b186215c6 | OK
(7 rows)

件数と合計値はすべてOKで、ハッシュだけがNGになりました。 これが、ハッシュでの突き合わせを入れる理由です。

実行結果3：正しい移行SQL（所要時間つき）

Timing is on.
BEGIN
Time: 0.393 ms
INSERT 0 10000
Time: 126.636 ms
INSERT 0 50000
Time: 612.183 ms
COMMIT
Time: 123.922 ms
 no |       item        |            old_value             |            new_value             | result
----+-------------------+----------------------------------+----------------------------------+--------
  1 | 備品 件数         | 10000                            | 10000                            | OK
  2 | 備品 購入金額合計 | 1005000000                       | 1005000000                       | OK
  3 | 備品 有効件数     | 9500                             | 9500                             | OK
  4 | 備品 全列ハッシュ | 49fa1437f3ae05bfc445ac16a824c9c2 | 49fa1437f3ae05bfc445ac16a824c9c2 | OK
  5 | 貸出 件数         | 50000                            | 50000                            | OK
  6 | 貸出 未返却件数   | 7142                             | 7142                             | OK
  7 | 貸出 全列ハッシュ | 97ce7d630ec24f991535529b186215c6 | 97ce7d630ec24f991535529b186215c6 | OK
(7 rows)

Time: 155.025 ms

全項目OKになりました。 この検証環境では投入からCOMMITまでが約0.9秒、検証SQLが約0.2秒でした。本番の件数とサーバーでの所要時間はリハーサルで測り、タイムチャートの時間に反映します。

判定を自動化するシェルスクリプト（verify.sh）

検証結果にNGが1件でもあれば終了コード1を返すようにしておくと、当日の判定が明確になります。

#!/usr/bin/env bash
# 使い方: ./verify.sh {DB名}   （NG が1件でもあれば終了コード 1）
set -euo pipefail
DB="$1"
psql -d "$DB" -X -q -f 04_verify.sql
NG=$(psql -d "$DB" -X -At -f 04_verify.sql | awk -F'|' '$5 == "NG"' | wc -l)
if [ "$NG" -eq 0 ]; then
  echo "判定: OK（全項目一致）"
else
  echo "判定: NG（不一致 ${NG} 件）"
  exit 1
fi

新側の購入金額を1件だけ1円変えて実行すると、次のように検出されました（表の部分は抜粋）。

  2 | 備品 購入金額合計 | 1005000000                       | 1005000001                       | NG
  4 | 備品 全列ハッシュ | 49fa1437f3ae05bfc445ac16a824c9c2 | a54160b8470ed7c0bcd6780ce53b04c8 | NG
判定: NG（不一致 2 件）

終了コードは 1 でした。データベースの権限設計は「PostgreSQLのロールと権限｜GRANT設計テンプレートとエラー対処」の記事も参考になります。

リハーサル計画

リハーサルは「本番と同じ手順・同じ件数・同じ時間の測り方」で行い、毎回の結果を手順書に戻すのがポイントです。

切り戻し手順もリハーサルで一度実際に行い、所要時間を測っておくと、判定時刻を逆算できます。

当日のタイムチャート（記入例）

金曜18:00に旧システムを停止し、日曜18:00までに完了する計画です。所要時間はリハーサル2回目の実測に余裕を加えた値として書きます。

Go/No-Go判定と切り戻し判断の基準

Go/No-Go判定とは、決めた時刻に「次へ進む（Go）か、止めて切り戻す（No-Go）か」を、決めた人が決めた条件で判断することです。条件は「だれが見ても同じ結論になる」書き方にします。

最終の切り戻し期限は「切り戻しにかかる時間（リハーサルの実測）＋余裕」を業務再開の時刻から逆算して決めます。 この例では、切り戻しに約4時間、確認に2時間かかる想定で、月曜の業務開始までに十分な余裕をとって土曜15:00としています。

切り戻し手順（概要）

旧システムのデータを停止時点から変更しない運用にしておくと、切り戻しが「設定を戻すだけ」になり、短時間で済みます。

リスクと対策

よくある失敗を防ぐチェックリスト

移行後の監視や問い合わせ対応を含む、日々の運用の決め方は「運用設計書の書き方｜項目一覧と記入例付きテンプレート」の記事にまとめています。

よくある質問

Q. 移行計画書と移行手順書の違いは何ですか？ A. 移行計画書は「方式・体制・スケジュール・判定基準」といった全体の段取りと合意事項を書く文書で、移行手順書は当日のコマンドや画面操作を順番に書く作業用の文書です。計画書から手順書を参照する形にすると、それぞれを更新しやすくなります。

Q. データ移行の検証は件数の一致だけで十分ですか？ A. 件数が一致しても、空白の除去漏れや値の変換違いは見つけられません。この記事の実行結果2のように、件数と合計値がOKでもハッシュでだけ差が見つかることがあります。件数・合計値・ハッシュの3つを組み合わせるのがおすすめです。

Q. 切り戻しの判断時刻はどう決めればよいですか？ A. 「業務を再開する時刻」から「切り戻しにかかる時間（リハーサルで実測）」と「確認の時間」と「余裕」を引いて決めます。判定時刻を過ぎたら新システムで対応を続ける、という線も合わせて決めておくと、当日の判断が明確になります。

まとめ

• 移行計画書は「何を・いつ・だれが・どの順番で」と「いつ・だれの判断で戻すか」を合意する文書
• 方式は停止できる時間と旧システムを動かせる期間で、一括・段階・並行稼働から選ぶ
• 体制はRACI表で、判定者（A）と代理を名前で決める
• 当日のタイムチャートに判定時刻を入れ、Go/No-Goの条件を数字で書く
• 最終の切り戻し期限は切り戻しの所要時間から逆算する
• データ検証は件数・合計値・md5ハッシュの3つで突き合わせると、抜け落ちも中身の違いも見つかる
• リハーサルは本番と同じ件数・手順で行い、切り戻しも一度試す

株式会社RJCでは、システム移行の計画と検証の進め方を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。