データ移行のコストダウンは、①移行する量そのものを減らす ②止められる時間に合わせて移行方式を選ぶ ③ツールで工数を置き換える ④検証の工数を最初から予算に入れる、の順に手を付けると効きます。データ移行の費用は抽出・変換・投入・本番切替・検証・リハーサルといった工程に分かれます。削ってよいのは重複した作業と不要なデータで、移行元と移行先を値で突き合わせる検証は削ってはいけません。
データ移行の費用内訳 — 主な確認項目と工程
「データ移行費」として一括で出てくる見積もりも、中身は次の工程に分かれます。コストダウンを検討するときは、まずこの工程に分解し、どこに工数が寄っているかを確認します。移行先への投入と本番切替も、独立した工程として見積もりに含めるか確認してください。
| 工程 | 工数が増える条件 | 依頼前に用意するもの | 見積もりに含むか確認する作業 | 完了基準 |
|---|---|---|---|---|
| 抽出 | 移行元が古い、接続手段が不明、正本の所在が不明 | 移行元のシステム構成図、接続情報、ファイル転送ソフトの設定 | 接続調査、取り出し方法の設計、抽出スクリプト作成 | 移行元から対象データを欠落なく取り出せたことを確認 |
| 変換 | 様式のばらつき、例外規則、表記ゆれ、全角半角混在、欠損値の扱い未定 | 項目の対応表、業務ルール、例外規則の一覧、サンプルデータ | 変換ルールの設計、変換スクリプト作成、単体テスト | 変換後のデータが業務ルールに沿っていることを業務部門が確認 |
| 投入 | 移行先の制約、データ量、投入方式、再実行の必要性 | 移行先の仕様、投入可能な形式、メンテナンス時間 | 投入スクリプト作成、投入リハーサル、エラー処理 | 合意した対象範囲と変換ルールに基づく期待件数・期待値に一致 |
| 本番切替 | 止められる時間、切替手順の複雑さ、切り戻しの難易度 | 切替手順書、連絡体制、停止時間の合意 | 切替作業、切り戻し手順の準備、当日の待機 | 切替後の動作確認が完了し、業務が再開 |
| 検証 | 件数だけでなく値を突き合わせる、業務部門の受け入れ確認 | 検証用の移行元データ、正しい値の定義、検証項目 | 突き合わせツールの作成、検証の実行、差異の原因調査 | 期待値に一致し、差異を説明でき、業務部門が受け入れ |
| リハーサル | 本番と同じ手順を一度通す、所要時間の実測、切り戻しの確認 | 本番同等の環境、リハーサル用データ、参加者の日程 | リハーサル実施、手順の改善、所要時間の記録 | 本番手順が確立し、所要時間と切り戻し手順が文書化 |
工程別の見積もりと費目別の集計は、同じ見積もりの異なる見方です。工数は、様式と例外規則を分類し、サンプルで抽出・変換・照合を試して、固定の調査設計と処理量に応じる作業に分けて見積もります。確認項目は様式数、例外処理、手修正、再実行、受け入れ確認です。費目別では、設定・検証・環境構築の作業を人件費、ライセンスやサービス利用料をツール費・環境費に分け、ツール導入の総額を示す場合は工程別の内訳の再掲として扱います。これらを工程ごとに割り振ると、どこに費用が寄っているかを比較できます。
ダウンタイム許容時間で移行方式を選ぶ
方式の選択は、「業務を止められる時間」が主要な条件の一つで、依存関係、更新の整合性、切り戻し可能性も合わせて確認します。まず抽出・転送・投入・検証・切替にかかる時間を実測または見積もり、許容できる停止時間と比較します。収まる場合は一括切替を候補にします。収まらない場合は、対象を分けて段階的に移す、事前にデータを同期しておく、差分を継続的に反映する仕組みを足す、といった方法を検討します。
「止められない」を前提にすると、並行稼働や複製環境の用意、差分反映の設計に工数がかかり、費用は上がります。まず業務部門に「何時間なら止められるか」を確認し、許容できる停止時間を確保できるかどうかを判断してください。止められないシステムでは、本番と同じサーバー上に検証環境を作らず別に用意する、対象を安全に分離できる場合は段階反映を検討する、反映前の状態を退避してロールバック手順を文書にしておく、といった手当てが費用を左右します。検証の範囲と、問題があった場合に同じ手順を再実行する条件は、方式とは別に定めておきます。
移行量そのものを減らす(クレンジングと不要データの削除)
移行量や様式を減らすと処理・確認の負担は下がりますが、削減幅は、固定的な調査・設計・検証の費用とデータ量に依存する作業の割合で変わります。
- 稼働していないサーバー、使われていないシステムを先に洗い出す。利用実態のない環境が残っていることもある
- 参照しかしない過去データは移さず、アーカイブとして別に置く。保存義務のあるデータは、適用される保存期間・保存形式・改ざん防止・閲覧などの要件を確認し、それらを満たす形で保管する。移行対象から外すことと削除することは分けて判断し、削除は保存義務と業務上の参照関係を確認した後に限定する
- 重複レコード、使われていない添付ファイル、テスト用の残骸を削除する
- 表記ゆれ・全角半角・コードの揺れは、移行用コピーや変換工程で直す方法も比較する。移行元を直す場合は、バックアップ、変更ルールの承認、参照関係の確認を前提にする
現状分析は、自社のITリソースが限られている場合は外部に依頼する方法もあります。
移行ツール・標準ユーティリティで工数を置き換える
移行ツールは、抽出と変換の作り込みを減らすために使いますが、役割は一つではありません。使う条件・減らせる作業・残る作業・確認する制約は次のとおりです。
| 手段 | 使う条件 | 減らせる作業 | 残る作業 | 確認する制約 |
|---|---|---|---|---|
| 標準のダンプ/リストア(pg_dumpなど) | 移行元と移行先が同じ系統のデータベース | 抽出・投入の作り込み | 所要時間の見積もり、整合性の確認 | 対応バージョンとオプションは公式資料で確認 |
| 継続複製ツール | 止められない、差分を継続的に反映したい | 切替時の停止時間、差分投入の実装 | 同期方式の設計、遅延の監視 | 対応する移行元・移行先、再同期の手順 |
| スキーマ変換ツール | 移行元と移行先の種類が違う、独自関数がある | 定義・型の手作業での変換 | 自動変換できない箇所の手修正 | 変換できる型の範囲 |
選定は、移行元・移行先、バージョン、変換対象、差分反映の要否から候補を絞り、件数・容量・停止要件・再実行・設定検証の工数で判断します。公式資料で対応範囲と残る手作業を確認します。ツールの費用にはライセンスだけでなく設定と検証の時間が含まれ、この時間を見積もりから落とすと後で戻ってきます。
データ品質チェックと移行後の検証を予算に入れる
見積もりで削られやすいのが検証の工数です。ここを削ると、黙って壊れたデータが本番に出て、後から直す費用のほうが大きくなります。
- 合意した対象範囲と変換ルールから期待件数・期待値を定め、投入済みデータと照合する。除外や変換の差異は説明できるようにする
- 業務ルールと例外は社内の責任者が承認し、外部は整理や照合の仕組みづくりを支援できる
- 抽出・変換の実装、ツールの設定、突き合わせ用の照合の仕組みは外注に向く
- 受け入れ確認は実際に使う業務部門が行う。その人の時間も工数として見積もりに入れておく
内製にすると費用は安く見えますが、兼務の担当者が本来業務で動けなくなると工程が止まります。どの工程を誰が持つかを決めたうえで、外注する範囲を決めるほうが結果的に安く収まります。
補足:クラウド移行全体の費用をどう見るか
データ移行を含むクラウド移行全体の費用は、システムの規模と方式で振れるため、一律の目安は示せません。ここでは費用を構成する項目を整理します。
- 初期費用:システム設計、データ移行、アプリケーション改修、テスト、社内研修。設計・移行・テスト・研修が独立した項目か、改修範囲がどこまで含まれるかを確認する。
- 月額運用費:サーバー使用料、データ転送料、サポート契約料、ライセンス料。利用人数、本番と検証の環境数、データ転送量、契約期間と更新条件で変動する。
- 5年間のTCO:初期費用、比較期間中の運用費、更新・撤去費用で整理。運用費に利用料・ライセンス・通信費・運用人件費を重複なく含め、両案で期間と費目をそろえる。
- 費用を左右する確認項目:アプリケーションの改修範囲、データの暗号化、アクセス権限、ログ保全、保存要件への対応。必要な対応と担当範囲を事先に確認し、見積もりに含めるか決める。
BENTEN Web Works の対応事例から
当方の経験は、大規模な基幹データベースの移行そのものではなく、Webサイトのサーバー移管、業務システムの改修と検証環境の構築、データの変換と投入といった周辺です。ただ、費用が膨らむ分岐点は同じところにあります。
移管の本体は「移設」ではなく旧環境の棚卸しだった
防災啓発プロジェクト「おもてなし防災」(企画屋プレス様)の公式サイトを、制作会社の管理環境から事務局側のサーバーへ移管した案件です(おもてなし防災のサーバー移管の記録)。ファイルを置いてネームサーバーを向け替えれば終わり、という見積もり方では足りませんでした。SNSでシェアしたときに参照されるURLが制作時のテストサーバーを指したまま残っていたり、肩書・事務局名・問い合わせ先が旧体制のままであったり、ネームサーバーの切替前にSSL証明書を申請していたために発行に失敗していたり。作業の分量は、移設そのものより旧環境の残り物を洗い出すほうに寄りました。一般には、利用する証明書サービスの認証方式とDNS設定を確認し、HTTPSの動作確認を含めて切替順序を決めることが重要です。
実データを全件数え直してから見積もった
表計算ファイルに入った記録データを集計してCSVに変換する案件で、先方の申告件数と、共有された実データを全件解析した結果が一致しませんでした。1ファイルに複数回分の記録が入っていたり、集計対象外のものが混ざっていたりしたためです。着手前に掲載の単位で数え直し(結果は16件)、そのうえで金額を出しました。実データには、区分ごとに異なる計算表、例外規則、欠損行の扱い、同じ値の表記ゆれ、全角半角の混在、様式のバージョン違いが同居していました。
検証の粒度と、ツールを入れない判断
ある案件では、生成したCSVと、実際に管理画面へ取り込まれたデータを1行ずつ照合し、39行17列がすべて一致することを確かめました。運用中には、元の表に列が挿入されてデータだけが右へずれ、見出しを頼りに列を探す処理が誤った列を読み、エラーも出ないまま集計値が全員分空欄になる状態が起きたことがあります。実データとの突き合わせテストが落ちたことで、公開前に止められました。対処は列の位置を決め打ちする方法ではなく、元の表の見出しを直してもらう方法をとっています。
別の案件では、既存コンテンツ30ページをWordPressへ投入する依頼(依頼側は全件手作業の想定)に対し、大規模インポート用の高機能プラグインは入れず、コンテンツを構造化データに整えてAPIで一括投入し、投入後に人が全ページを目視確認する構成にしました。この規模ではプラグインの設定と検証のコストのほうが大きい、という判断です。目視確認まで省く完全自動化も見送りました。
止められないシステムでは、切り戻しまでを範囲に入れる
業務システムの改修では、本番と同じサーバー上に検証環境を作る案を、本番へ影響が及ぶ経路を作るとして見送り、お客様が用意したテスト機に本番の複製環境を構築しました。2つの機能をまとめて本番反映する案も見送り、1つ目を先に出して結果を確認してから2つ目に進めています。反映前の状態は本番上に退避し、取り込み手順とロールバック手順を文書にしました。
別の案件では、別の業者がサーバーのPHPを上げる都合で「WordPressのバックアップだけ」を頼まれましたが、バックアップ単体では受けず、「切替前のバックアップと本体・プラグインの更新と動作確認」「切替後の再確認と切り戻し」の2段に組み直し、切り戻しを基本の作業範囲に含めました。時間がかかるのは切替そのものではなく、サーバーからのバックアップ、本番と同構成での事前検証、切替後の確認、更新が止まっていたプラグインと本体の追随です。契約中のプランで必要なPHPが提供されているかによって、切替で対応できるか、サーバー移転が必要かが変わります。見積もりから切り戻しを落とすと、壊れた後の対応が空白になります。
移行しなくてよいものを移行しない
クラウド上で動く業務アプリが週末に止まり、「週明けまでに復旧、予算はなるべく抑えたい」という依頼を受けた案件では、全面的な作り直しと、別のクラウドへの全面移行を提案しませんでした。動いている前提を壊して予算が膨らむためです。代わりに、1つの案件を障害復旧・構成把握・仕様書整備・改修と運用整備の4回の発注に分けて進めました。
見積もりで確認しておきたい項目
データ移行の費用は、次の項目で上下します。金額の多寡より、この項目が埋まっているかどうかで見積もりの外れ幅が変わります。
- 移行対象の範囲(システム、テーブル、対象期間)と、移さないデータの線引き
- 件数と様式の数。申告値ではなく実データで数え直したか
- 業務を止められる時間と、止められない場合の代替手段
- 本番から分離した検証環境の費用と、本番との構成差を確認する作業が含まれるか
- 切り戻しの手順と、当日それを実行する担当
- 移行ツールのライセンスと、設定・検証にかかる時間
- クラウド利用料。利用する人数と、本番・検証など環境の数で変わる
- データ転送量と、外部連携にかかる通信費
- 移行後の運用体制(監視、バックアップ、障害対応)を誰が持つか
相場を調べる場合も、これらの項目を自社の条件で埋めてから見積もりを依頼すると、比較できる形になります。
隠れたコスト(データ通信費や人件費)を見落とさない
クラウド移行では、サーバー使用料だけでなく、データ通信費や人材育成費といった「隠れたコスト」が発生します。外部とのデータ連携が多い企業では、データ転送量に応じて追加料金がかかる場合があります。また、これまで社内でサーバー管理を担当していた社員が、クラウド運用のスキルを習得するための研修費用も必要です。こうしたコストを最初の見積もりに含めておかないと、後から「聞いていなかった」という事態になりかねません。
特定のクラウドベンダーの技術に依存しすぎると、別のベンダーやオンプレミスに戻ることが難しくなる「ベンダーロックイン」のリスクもあります。専用APIやデータ形式を使った場合、移行先でそのまま利用できないことがあるため、データの輸出可能性や互換性を移行前に検証しておきます。解約時のデータ取り出し方法や費用も、契約条件として確認しておく範囲です。
移行後の運用体制を事前に整える
クラウド移行は「移行して終わり」ではなく、移行後の運用保守が継続します。インフラ監視、セキュリティパッチの適用、バックアップの取得、障害対応といった日々のタスクが発生します。社内にこれらを担当できる人材がいない場合は、情シス代行サービスを利用するのが現実的な選択肢です。特に中小企業では専門人材の採用が難しくコストもかかるため、外部に委託することで安定した運用とコスト削減を両立できます。運用フローと担当者を決めずに移行を進めると、トラブル発生時の対応が遅れます。
補助金・助成金の活用
クラウド移行にかかる費用は、補助金や助成金を活用できる場合があります。利用する制度の現行要領で、対象ツール、移行作業費の対象可否、申請者の条件、契約・発注時期を確認してください。対象年度の公式公募ページを直接確認することをおすすめします。
見積もり項目を自社の条件で埋めても判断がつかない場合は、お問い合わせから30分のオンライン無料相談(Web会議)を受け付けています。現在のお困りごとを伺います。お問い合わせには24時間以内に返信します。