giip
SES案件登録
移行チェックリスト

大規模データベース移行チェックリスト — 着手前に確定させる項目

大規模移行が失敗するのは、たいてい技術的に不可能だったからではなく、確認すべき項目を決めないまま着手したためです。

このページは、大規模なデータベース移行の計画を立てる立場の方に向けたものです。以下は一般的な確認項目の整理であり、GIIPが特定の案件で実施した内容の全量ではありません。実際に必要な項目は環境ごとに異なります。

こんな状況ではありませんか
!

何を確認すれば十分なのか決まらない

確認項目に終わりが見えず、着手判断が下りないまま時間が過ぎています。

!

切り戻しの手順がない

切り替え当日にうまくいかなかった場合の判断基準と手順が決まっていません。

!

移行後の担当が決まっていない

プロジェクトが終わった時点で、監視と障害対応の担当が空白になります。

なぜ計画段階で止まるのか
01

検証範囲が合意されていない

どこまで確認したら完了とするかが決まっていないため、工数も期間も確定できません。

02

業務条件が技術条件に翻訳されていない

「止められない」という要望が、何時間までなら止められるという条件に落ちていません。

03

棚卸しが人力のまま

対象が多い環境では、機械的に抽出しない限り一覧が完成しません。

GIIPが実行すること

確認項目を並べるだけでなく、確認が終わったと言える基準を先に決めます。

検証範囲の合意

何をもって移行完了とするかを、着手前に文書で確定させます。

切り戻し基準の明文化

何が起きたら戻すのか、戻すのに何分かかるのかを事前に決めます。

移行後の運用の引き受け

移行後の監視・性能分析・障害対応をGIIPが継続するか、引き継ぐかを着手時点で決めます。

関連するページ

着手前に確定させる項目

  • 移行元・移行先の製品とバージョン
  • データ容量と、テーブル・オブジェクトの総数
  • スキーマ定義、データ型、文字コード、照合順序の差異
  • ストアドプロシージャ、トリガー、ジョブの一覧
  • 外部システムとの連携(ファイル、DBリンク、API)の一覧
  • アカウント・ログイン・権限の引き継ぎ方法
  • バックアップとリストアの手順の再定義
  • 許容できる停止時間(業務条件として合意されたもの)
  • 切り替え手順と、切り戻しの判断基準・手順
  • 移行前後の件数・定義の突合方法
  • 移行後に監視する項目と、その担当
  • 性能劣化を検知したときのエスカレーション経路

GIIPが実際に扱った規模

SQL Serverx12largeクラス・5レプリカ構成をAWS RDSへ、12セット
Oracle約12万テーブルのオンプレミス環境をAWSへ
TiDB約3TBの環境をAmazon Aurora MySQLへ
現在の運用複数のクラウドデータベースと約30のWebサービスをAIエージェントと人間の専門家が継続監視

上記チェックリストは一般的な技術説明です。すべての項目がこれらの案件で使用されたという意味ではありません。

よくあるご質問

このチェックリストをそのまま使っていいですか。

出発点としてはお使いいただけますが、必要な項目は移行元と移行先の組み合わせによって変わります。同じ製品間の移行と、別製品への移行では確認すべき内容が異なります。

無停止で移行できますか。

データ量、更新頻度、アプリケーション側の切り替え方式によって変わります。確認せずに可能とはお答えしていません。

検証はどこまでやれば十分ですか。

「十分」は技術ではなく合意で決まります。件数と定義の突合を全対象に対して行うのか、サンプリングで足りるのかを、着手前に業務側と決めておく必要があります。

移行後の監視も依頼できますか。

可能です。GIIPは移行後のクラウドデータベースの監視・運用を継続して担当します。

続けて読む

自社の移行計画の抜けを確認する

現在の構成と検討中の移行先をお知らせください。確定させるべき項目を整理してご回答します。

contact@littleworld.net