LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

サポートが切れるのでデータベースの版を上げてほしいと言われた。でも、どれくらいシステムを止めればよいのか見当がつかない——。情報システム部門では、保守の期限が近づくたびにこうした相談が持ち上がりがちです。データベース移行とは、データベースの製品や版、置き場所を替えて、中のデータと一緒に新しい環境へ移す作業のことです。

移し方にはいくつかの方式があり、どれを選ぶかで止める時間も準備の手間も大きく変わります。ただし万能な方式はなく、業務を止められる時間から逆算して選ぶ必要があります。本記事では、システムの担当者に向けて、移行の種類、方式の違い、停止時間の決め方、そして外部に頼むときに確認したい点を整理します。

データベース移行とは

データベース移行という言葉は、場面によって指すものが少しずつ違います。よく話題になるのは次の3つで、どれに当たるかで確かめる点が変わります。

• 版を上げる：同じ製品のまま、新しいメジャーバージョン（大きな版）へ移す
• 製品を替える：OracleからPostgreSQLへのように、別の製品へ移す（異種移行とも呼びます）
• 置き場所を替える：社内のサーバーから、クラウドのデータベースサービスへ移す

PostgreSQLの公式ドキュメントは、同じメジャーバージョンの中の小さな更新（マイナーバージョン）であれば、サーバーを止めてプログラムを入れ替えるだけで済み、データの置き場所はそのままでよいと説明しています。^*1 一方でメジャーバージョンが変わると、データの内部の保存形式が変わることがあり、移し方を選ぶ必要が出てきます。業務データを新しいシステムへ移し替える話はシステム移行・データ移行を外注する進め方で扱っています。

3つの移行方式の違い

データベースを移す方式は、大きく3つに分かれます。違いは、移している間に業務を止めるかどうかと、止める時間の長さです。

PostgreSQLの公式ドキュメントは、書き出して戻す方法を昔からのやり方としつつ、時間がかかることがあると書いています。専用ツールのpg_upgradeなら数分で版を上げられる場合があり、複製して切り替える方法では停止は数秒で済むと説明しています。^*1 AzureのDatabase Migration Serviceも、停止を最小限にする「オンライン移行」と、止めて移す「オフライン移行」を分けています。^*5

版を上げる移行と製品を替える移行

同じ製品の版を上げる場合でも、アプリケーションの手直しが要らないとは限りません。PostgreSQLの公式ドキュメントは、新しいメジャーバージョンでは利用者から見える互換性のない変更が入ることがあり、アプリケーションの修正が必要になる場合があるとしています。切り替える前に、新しい版でアプリケーションを試すことも勧めています。^*1

• 版を上げる：データの形はほぼそのまま。確かめるのは、新しい版の変更点とアプリケーションの動作
• 製品を替える：テーブルの定義（スキーマ）を、新しい製品で使える形に変換する作業が加わる
• 製品を替える：データベースの中に書いた処理（ストアドプロシージャなど）も、新しい製品で動く形に変換が要る

AWSのDatabase Migration Serviceは、別の製品へ移すときはスキーマを先に変換し、そのあとでデータを移す流れを示しています。^*2 データを写す処理は主キーなどを作りますが、検索用の追加のインデックスや一部の制約、列の初期値は作らないとしています。^*3製品ごとの注意点は脱Oracle DBでPostgreSQLへ移行する進め方やMySQL 5.7から8.0への移行にまとめています。

停止時間の決め方

方式を選ぶ前に決めておきたいのが、業務をどれだけ止められるかです。IPA（情報処理推進機構）の「非機能要求グレード」は、要件の一つに「システム停止可能日時」を挙げ、次の6段階で示しています。^*4

• レベル0：制約なし（必要な期間止められる）
• レベル1：5日以上／レベル2：5日未満
• レベル3：1日（計画停止日を利用）
• レベル4：利用の少ない時間帯（夜間など）
• レベル5：移行のためのシステム停止はできない

この停止時間には、移す作業そのものだけでなく、事前のバックアップや、失敗したときに元へ戻す時間も含めるよう求めています。^*4 たとえば夜間の数時間しか止められないなら、書き出して戻す方式はデータ量によって時間内に終わらないおそれがあり、複製して切り替える方式を検討することになります。

所要時間は机上の見積もりではなく、本番と同じ量のデータでリハーサルをして測ります。非機能要求グレードも、リハーサルの範囲を、主要な正常の手順だけか、移行前の状態に戻す手順まで試すかで分けています。^*4

外部に頼むときに確認しておきたい点

データベース移行を外部に頼むときは、見積もりの前に次の点を確かめておくと、作業の範囲の食い違いを防げます。

• 移行の種類：版を上げるのか、製品を替えるのか、置き場所も替えるのか
• 止められる時間：業務側と合意した停止可能日時に、バックアップと元へ戻す時間が収まる計画か
• アプリケーションの確認：新しい版や製品で試す範囲と、手直しが要ったときの扱い
• リハーサル：本番と同じ量のデータで何回行い、元へ戻す手順も試すか
• 作業の分担：データ件数の照合と、切り替えるかどうかの判断を誰が受け持つか

非機能要求グレードは、移行の作業をどう分担する場合でも、最終的な移行結果の確認は発注する側が行うとしています。^*4 移したあとの件数や主要な画面の動きを誰が確かめるかも、契約の前に決めておきます。テーブルの構造を変える作業を止めずに進めたい場合はゼロダウンタイムでDBスキーマを移行する進め方で扱っています。

まとめ：データベース移行で確かめておきたい3つの点

データベース移行を進めるうえで、確かめておきたい点は3つに整理できます。第一に、版を上げるのか製品を替えるのかを見極め、アプリケーションの手直しが要るかを確かめること。第二に、業務を止められる時間を、バックアップと元へ戻す時間まで含めて決めること。第三に、その時間に収まる方式を選び、リハーサルで所要時間を測ることです。この3点を踏まえておけば、「切り替えの作業が朝の業務に間に合わなかった」という事態を避けやすくなります。移行の計画に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：PostgreSQL Global Development Group「PostgreSQL Documentation: 18.6. Upgrading a PostgreSQL Cluster」（https://www.postgresql.org/docs/current/upgrading.html）。出典：マイナーバージョンとメジャーバージョンの更新の違い、ダンプとリストア・pg_upgrade・レプリケーションの3つの方法と停止時間、互換性のない変更とアプリケーションの事前確認の記述を参照（2026年11月確認）
2. *2　参考：Amazon Web Services「What is AWS Database Migration Service?」（https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html）。出典：別の製品へ移すときのスキーマ変換とデータ移行の流れ、一度きりの移行と変更の継続的な同期の記述を参照（2026年11月確認）
3. *3　参考：Amazon Web Services「Creating a task」（AWS Database Migration Service User Guide）（https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.Creating.html）。出典：全件ロードと変更データの取り込み、移行先に作成されないもの（追加のインデックス・主キー以外の制約・列の初期値）の記述を参照（2026年11月確認）
4. *4　参考：独立行政法人情報処理推進機構（IPA）「非機能要求グレード2018」（https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html）。出典：項目一覧の移行性（システム移行期間、システム停止可能日時、リハーサル範囲、移行作業分担）の記述を参照（2026年11月確認）
5. *5　参考：Microsoft Learn「What is Azure Database Migration Service?」（https://learn.microsoft.com/en-us/azure/dms/dms-overview）。出典：オンライン移行（停止を最小限にする移行）とオフライン移行の区分を参照（2026年11月確認）

Tweet