データ移行戦略ガイド

データ移行とは、ある保存場所から別の保存場所へデータを移動させるプロセスのことで、オンプレミスのデータセンターからクラウドへ、データベースプラットフォーム間、あるいはレガシーなストレージ・アレイから最新のインフラへの移行などが含まれます。明確な戦略なしに移行を実行すると、予算超過、データ損失、業務の中断を招くおそれがあります。

そのリスクは極めて高いものです。Oracle の調査によると、データ移行プロジェクトの80% 以上が、時間の経過とともに予算を超過しています。この数値は長年にわたりほとんど改善されていません。その原因は技術が不十分だからではなく、組織が、移行を成功させるために必要な計画立案、データ品質の確保、リスク管理を過小評価しているためです。

本ガイドでは、データ移行戦略に関わるあらゆる事項について解説します。移行の仕組み、状況に応じたアプローチ、計画段階で考慮すべきリスク、移行を順調に進めるための段階的なプロジェクト・フレームワークについて詳しく説明します。

新しいシステムへの移行を決定することは、決して容易なことではありません。しかし、容量の制約、パフォーマンスの限界、ライセンスの変更、あるいはクラウドインフラへの移行など、何らかの理由で現在の環境がもはやニーズを満たさなくなった場合、移行は避けられなくなります。問題は、解決すべき問題以上に新たな問題を発生させることなく、どのように対処するかです。

堅牢なデータ移行戦略は、計画から廃止までの構造化された道筋を提供します。この戦略では、データ移行の技術的な仕組み、それに伴うビジネス・リスク、そして移行期間を通じてデータの正確性とアクセス性を維持するために必要なガバナンス・プロセスに対処します。

データ移行とは、あるストレージの場所から別のストレージの場所へデータを移動するプロセスです。新しい環境でデータへのアクセスと正確性を確保するために必要な計画、マッピング、抽出、フォーマットの手順が含まれます。これには、データベース、ファイル、アプリケーション、ワークロード全体を、形式、構造、プラットフォームが異なるシステム間で転送することが含まれます。

組織が、多様な環境において指数関数的に増加するデータを扱うようになるにつれ、データを効率的に移行できることが極めて重要になってきています。かつては単にデータベースをあるサーバーから別のサーバーにコピーするだけで済んだ作業も、現在ではクラウド・プラットフォームや分散型アーキテクチャ、コンプライアンス要件などが関わるようになり、その複雑さが格段に増しています。

ほとんどのデータ移行は、一般的な ETL プロセス（抽出、変換、ロード）が採用されています。しかし、具体的な内容はソース環境とターゲット環境によって異なります。移行の中核となるのは、以下のステップです。

• 移行するデータを分析して、スキーマの違い、データ型の不一致、エンコーディングの不整合など、ソース環境とターゲット環境間の互換性の問題を特定します。
• ソースのフィールドを、ターゲット側の対応するフィールドにマッピングします。本番環境に反映される前に変換エラーを捕捉するためには、適切なデータマッピングのドキュメントが不可欠です。
• 移行を開始する前に、全てのデータをバックアップします。これは絶対に欠かせない手順です。検証済みのバックアップがない場合、移行に失敗すると永続的なデータ損失が発生するおそれがあります。
• 本番環境のコピーに対して移行ロジックをテストし、コミットする前にターゲットシステムのデータ精度を検証します。
• データ・ローダーまたは ETL アプリケーションを使用してソース・システムからデータを抽出します。
• 必要に応じてデータを変換し、ターゲット・システムのフォーマット、スキーマ、またはデータ品質要件に適合させます。
• 変換されたデータをターゲット環境にロードします。
• 行数、チェックサム、アプリケーション・レベルのテストなど、転送されたデータが完全、正確、アクセス可能であることを確認します。

マッピングとテストのステップでは、ほとんどの移行が問題に陥ります。移行を単なるコピー操作として扱い、厳密なデータ・プロファイリングや検証をスキップする組織は、カットオーバー後に初めてデータ品質の問題に気づく傾向があり、その時点では修正が最も困難になっています。

これらは、データ移行に関連する最も一般的なリスクであり、戦略においてそれぞれを明確に考慮する必要がある理由について解説します。

1. 予算超過

データ移行に関する Oracle のホワイトペーパーによると、データ移行プロジェクト全体でコストが平均 30% 超過し、時間が平均 41% 超過しています。これらは、ほとんどの場合、ソース・データの複雑さを過小評価することに起因します。具体的には、実際のデータ・プロファイリングが始まってから必要となるクレンジングや変換作業の量です。

予算超過のもう 1 つの一般的な原因は、スコープ・クリープです。移行によって、初期のスコープでは見られなかった依存関係、統合、データ品質の問題が明らかになることがよくあります。こうした発見のたびに、予算に計上されていなかった作業が追加されます。移行予算に予備費（通常、当初の見積もりの 20％～25％ 上乗せ）を組み込んでいる組織は、プロジェクトを頓挫させることなく、こうした発見に対処できます。予備費を設けていない組織は、手抜きをするか、プロジェクトの途中で追加予算の承認を求めることになり、いずれも独自のリスクを伴います。

2. データ損失

バックアップ段階を省略したり、急いで行ったりした移行では、データ損失が頻繁に発生します。あらゆる移行計画において、データの移動を行う前に検証・テスト済みのバックアップ戦略を含める必要があります。これは、バックアップを作成するだけでなく、バックアップからリストアできることを確認することを意味します。

この区別は、一見した以上に重要です。多くの組織は、実際に復元を試みた際に、バックアップが不完全であったり、破損していたり、あるいは移行先環境と互換性がなかったりすることに気づきます。一度もテストされたことのないバックアップは、バックアップではなく、単なる「仮定」に過ぎません。復元テストは、移行の実行が始まる前の正式な承認要件として位置づけるべきであり、移行完了後に予定される後付けの作業であってはなりません。

3. ダウンタイム

地理的レプリケーションや並行稼働アーキテクチャがない場合、データの移行には通常、システムの停止が必要となります。これは、アプリケーションのパフォーマンスとユーザー・アクセスに影響します。選択する移行手法（ビッグバン移行、トリクル移行 、またはゼロ・ダウンタイム移行）によって、ビジネスが許容しなければならないダウンタイムの程度がほぼ決まります。

ダウンタイムの見積もりは、往々にして楽観的になりがちです。4 時間で予測された移行ウィンドウは、データ量が予想よりも大きい場合、変換ロジックがテストよりも遅く実行される場合、または検証ステップでカットオーバーを進める前に解決する必要がある問題が表面化する場合に、12 時間に延びる可能性があります。的なダウンタイムの見積もりを伝え、メンテナンスウィンドウに余裕を持たせておくことで、移行の途中で「継続するかロールバックするか」という判断を誤らせるようなプレッシャーを回避できます。

4. データの破損

データの破損は、不要なデータ、不正なデータ、互換性のないデータが新しいシステムに転送された場合に発生します。破損したデータはアプリケーションのクラッシュを引き起こしたり、不正確な出力を生み出したりすることがあります。これらは完全なデータ損失よりも検出が難しい場合があります。レコードが欠落している場合は一目瞭然である一方で、値がわずかに間違っているレコードは、数週間も気づかれないままになることがあります。

一般的な破損の原因には、ソース・システムとターゲット・システム間の文字エンコーディングの不一致、値をサイレントに切り捨てたり変換したりするデータ・タイプ変換、エッジ・ケースを誤って処理する変換ロジックなどがあります。移行前の厳格なデータ・クレンジングと、カットオーバー後の検証が、主要な防御策となります。検証には、列数、チェックサム、制約検証、実際のビジネスプロセスのコンテキストでデータが正しく動作することを確認するアプリケーションレベルのテストの両方が含まれます。

5. データ・グラビティ

データ・グラビティとは、データが時間の経過とともに、それに関連するアプリケーション、サービス、その他のデータセットといった依存関係を蓄積していく傾向を意味します。データセットの重力が大きいほど、依存関係を中断することなく移動するのが難しくなります。多くの組織は、移行の途中になって初めてデータグラビティの問題に気づきます。データベースを移行すると、それに接続された数十ものサービスも再構成しなければならないことがあるためです。

このリスクは、特に、長年にわたって有機的に成長してきた環境で顕著です。システム連携が構築され、API には接続文字列がハードコードされ、レポート・ツールには特定のデータソースが指定されます。しかも、こうした構成が一元的に文書化されていないことも少なくありません。ランドスケープ分析の際に徹底的な依存関係のマッピングを行うことは、これらの関連性が本番移行当日に予期せぬ問題となる前に、それを明らかにするための最善の方法です。移行するデータに関わるアプリケーション、サービス、スケジュールされたジョブは全て、移行計画の一環として特定、テスト、更新する必要があります。

6. 低品質なデータ

重複したレコード、一貫性のないフォーマット、欠損値、古いデータといったデータ品質の問題は、移行時に解消されません。それらは移行先のシステムにも引き継がれ、新しいシステムの問題となります。移行前のデータ・ガバナンスのレビューとクレンジング・プロセスは、これを防ぐ唯一の信頼できる方法です。移行前にデータプロファイリングを省略した組織は、事前のクレンジングに費やしたはずの時間よりも、移行後のクリーンアップに一貫して多くの時間を費やすことになります。しかも、ユーザーがすでに新しいシステムを利用しており、業務がまだ信頼できないデータに依存しているという、厳しい状況下でその作業を行わなければなりません。移行を単なるデータの移動ではなく、データ品質を向上させる機会と捉えることで、移行後の成果は著しく向上します。

移行戦略とは、データがソースからターゲットへどのように移行されるかを定義するものです。一括移行、段階的移行、あるいは目立った中断なしの移行などがあります。適切なアプローチは、ダウンタイムの許容度、環境の複雑さ、移行するシステムの重要度によって異なります。

1. ビッグバン移行

ビッグバン移行では、通常、予定されたメンテナンス期間中に、単一の操作で全てのデータを移行します。システムをオフラインにし、ETL 処理を実行した後、完全なデータセットを備えたターゲット・システムが稼働を開始します。

メリットはシンプルさと高速性です。並列システムの保守やデータの同期管理は不要です。デメリットは、リスクにさらされることです。移行の途中で失敗した場合、ロールバックを余儀なくされるか、ダウンタイムが長期化するリスクが伴います。ビッグバン移行は、データセットが小規模な場合、定期的なメンテナンス期間が設けられているシステム、短時間のダウンタイムが許容される組織に適しています。

2. トリクル移行

トリクル移行では、旧システムと新システムの両方が並行して稼働している間に、データを段階的に移行します。移行中もソースシステムは稼働し続けるため、ユーザーへのダウンタイムが発生しません。データ同期ツールにより、移行期間中も両環境の一貫性が保たれます。

トリクル移行の実行はより複雑です。並列システムを実行するには、追加のインフラ、慎重な同期ロジック、新しいシステムが権威を持つように定義されたカットオーバー・ポイントが必要です。しかし、ミッションクリティカルな環境においては、この追加の複雑さは多くの場合、適切なトレードオフとなります。

3. ゼロ・ダウンタイム移行

ゼロ・ダウンタイム移行は、継続的なレプリケーションとほぼ即時のカットオーバーにより、サービスの中断を排除するトリクル移行アプローチの延長です。計画的なメンテナンス期間ではなく、ターゲットシステムがソースシステムと同一の状態に達した時点でカットオーバーが行われます。このアプローチは、24 時間 365 日の可用性が求められる組織や、ダウンタイムを一切許容しない SLA の要件がある組織において、ますます一般的になっています。

ゼロ・ダウンタイム移行は、3 つのアプローチのなかで最も複雑であるものの、ビジネスの中断のリスクは最も低くなります。モダンなストレージおよびデータベース・プラットフォームにより、このアプローチがよりアクセスしやすくなりました。地理的レプリケーションやアクティブ・アクティブ・クラスタリングなどのツールは、大規模な継続的な同期をサポートしています。

ほとんどのエンタープライズ移行は、単一のカテゴリにきれいに収まりません。一般的なパターンは、アクティブな実稼働データベースにトリクル移行 またはゼロ・ダウンタイム移行のアプローチを使用し、短時間の可用性を許容できるアーカイブデータにビッグバン移行を使用することです。

移行タイプは、移行対象と環境によって決まります。各タイプには、技術的な考慮事項、障害モード、計画要件があります。どのタイプ、または複数のタイプの組み合わせがプロジェクトに適用されるかを理解することは、移行戦略が下すべき最初の決定の 1 つです。

データベース移行

データベース移行は、ベンダーの切り替えまたはデータベース・ソフトウェアのアップグレードのために、2 つのデータベース・システム間でデータまたはアプリケーションを転送するものです。一般的なトリガーには、データベース・ベンダーからの製品寿命の発表、ライセンス・コストの変更、現在のプラットフォームの性能制限、オープンソースの代替案への移行などがあります。

スキーマの違いは、複雑さの主な原因です。2 つのデータベースは、次のような構造的に互換性のない方法で概念的に類似したデータを保存する場合があります。 

• 異なるデータ型
• 命名規則
• 制約ルール
• インデックス作成のアプローチ

1 つのデータベースの方言に記述されたストアドプロシージャとカスタム関数は、多くの場合、ターゲットシステムの書き換えを必要とします。

アプリケーション間の依存関係も、課題をさらに複雑にします。ほとんどの実稼働データベースは、複数のアプリケーションから読み書きするために使用されます。これらの各アプリケーションは、カットオーバー前にターゲットデータベースに対してテストする必要があり、ベンダー固有の動作に依存するクエリを特定して書き換える必要があります。このステップを省略することは、データベースの移行が検証に失敗する最も一般的な理由の 1 つです。

注意点：

• プラットフォーム間で異なる動作をする暗黙的なデータ型の変換
• テキストデータを破損させる文字エンコーディングの違い（UTF-8 と Latin-1 など）
• ベンダー間でクリーンに転送されないシーケンスと自動増分の動作
• ベンダー固有の SQL 方言で記述されたトリガーとストアド・プロシージャ

クラウドの移行

クラウドの移行は、データやアプリケーションをオンプレミス環境からクラウド・インフラ、またはクラウド・プロバイダ間での移動を意味します。多くの場合、データベースの移行、ストレージの移行、アプリケーションの移行が並行して実行されるため、これらの移行はスコープ内で最大規模で、組織的に最も複雑な移行タイプです。

最小限の変更でワークロードをクラウドに移動させるリフトアンドシフト移行は、実行が最速である一方で、性能やコストの問題が残ることがよくあります。クラウドネイティブ・サービスを活用するためにワークロードをリプラットフォームまたはリファクタリングすることは、移行の複雑さを増大させる一方で、通常は長期的な成果をもたらします。

コンプライアンス要件、データ・レジデンシー・ルール、ネットワーク遅延など、オンプレミスの移行では直面することのできない要素が加わります。GDPR、HIPAA、その他の規制により、データが通過または保存される場所が、たとえ一時的であっても制限される場合があります。大規模なデータセットを移動する組織にとって、ネットワーク帯域幅は真のボトルネックとなり得ます。一部の移行では、ネットワーク経由の転送よりも物理的なデータ転送サービスを利用した方が、高速で低コストになる場合があります。

クラウド間の移行（AWS、Microsoft Azure、Google Cloud など）は、組織がベンダーとの関係を再評価したり、マルチクラウド環境を統合するにつれて、ますます一般的になっています。これらの移行には、ソース・クラウド、オブジェクト・ストレージ API、マネージド・データベース・サービス、サーバーレス機能に蓄積された独自のサービス依存関係を理解し、移行先で同等のサービスが存在するかどうかを判断する必要があります。

注意点：

• 移行予算を大幅に押し上げるアウトバウンド転送コスト
• ターゲット・プロバイダに直接同等のものがない独自のサービス依存関係
• コンプライアンス要件とのデータ居住地の不一致
• 低レイテンシーのオンプレミス・アクセス用に設計されたアプリケーションへの遅延の影響

ストレージの移行

ストレージの移行とは、既存のストレージアレイから新しいハードウェアへデータを移動させることです。これらは、エンタープライズ環境で最も一般的な移行タイプの一つです。ハードウェアの更新サイクル、容量拡張のニーズ、回転ディスクからオールフラッシュ・アーキテクチャへのシフトによって駆動されます。

データベースやアプリケーションの移行とは異なり、ストレージの移行には、本質的にデータの変換は必要ありません。データ形式は変わりません。ブロックやファイルを物理的な場所から別の場所に移動させるだけです。しかし、運用上のリスクも同じように現実的です。本番データへのアクセスを妨げるストレージ・アレイの移行は、そのストレージに応じて、全てのアプリケーションとユーザーに影響を及ぼします。

ホストベースの移行では、サーバー上で実行されているソフトウェアを使用して、ソースからターゲット・ストレージにデータをコピーします。柔軟性があり、特殊なハードウェアは必要ないものの、移行時にサーバーの CPU とメモリ・リソースを消費します。アレイベースの移行では、ストレージ・ハードウェアに組み込まれたレプリケーション機能を使用します。これは、通常、ホスト側のオーバーヘッドが少なく、無停止のカットオーバーが可能になります。

オールフラッシュ・アレイを使用している組織では、多くの場合、ストレージの移行は、インフラのモダナイゼーション作業と一致します。ハイブリッド・ストレージや回転ディスク・ストレージからオールフラッシュへの移行により、性能特性が大幅に変化します。高レイテンシー・ストレージ用に調整されたアプリケーションは、新しい環境を最大限に活用するために再構成が必要になる場合があります。

注意点：

• ホストのマルチパス構成は、ストレージのターゲットが変更された場合に更新が必要
• 移行後に動作しなくなる、ストレージ・パスがハードコードされたアプリケーション
• アプリケーションの動作に影響を与えるソース・アレイとターゲット・アレイの性能の違い
• 新旧のハードウェア間で異なるデータ削減率を考慮した容量計画

アプリケーションの移行

アプリケーションの移行とは、環境間、オンプレミスからクラウド、クラウドからクラウド、または新しい SaaS プラットフォームにアプリケーションへ移行することを意味します。これらは、ほとんどの場合、データベースやストレージの移行を依存関係としてトリガーするため、計画と実行が最も複雑な移行タイプです。

その複雑さは急速に増大します。例えば、ERP システムの移行には、基礎となるデータベース、実行されるストレージ、依存するネットワーク・サービス、他のアプリケーションとの統合が必要になる場合があります。これらのアプリケーションには、それぞれ独自の移行要件とシーケンシングの制約があります。

また、アプリケーション移行は、ユーザーやビジネス・プロセスに直接影響するため、移行の種類を問わず、リスクが高くなります。ストレージの移行が失敗した場合は、インフラの問題となります。アプリケーションの移行が失敗すると、業務遂行に不可欠なワークフローが中断されてしまいます。

SaaS の移行は、自己管理型アプリケーションからベンダー管理型クラウド・サービスへの移行に、さまざまな課題をもたらします。多くの場合、カスタマイズオプションが限定されたマルチテナント環境に移行することになるため、データを移行する前に、ターゲット・プラットフォームが現在のワークフローを実際にサポートできるかどうかを評価する必要があります。

注意点：

• 文書化されているか否かを問わず、APIを介してアプリケーションに接続するサードパーティ製統合機能
• レプリケーションまたは移行が必要なユーザー認証の依存関係（LDAP、Active Directory）
• 移行先環境に引き継げない可能性があるカスタム設定や拡張機能
• プロジェクトのスケジュールに組み込む必要があるエンドユーザーのトレーニング要件

これらの依存関係を理解することは、シーケンシングにおいて重要です。一般的に、ストレージの移行は、アプリケーションの移行を検証する前に完了させる必要があります。また、データベースの移行は、アプリケーションのカットオーバーの前に実行する必要があります。これらを依存シーケンスではなく独立したワークストリームとして扱うと、カットオーバー時に予期しない問題が発生する可能性があります。

データ品質は、移行計画において最も見落とされがちな要素です。組織は、移行の途中で、ソースデータに重複、不整合な書式、孤立レコード、および新しいスキーマに準拠する必要が生じるまで気づかなかった欠損値が含まれていることに、常に気づかされます。

移行前評価には、次の 3 つの要素を含める必要があります。

• データ・プロファイリング：ソース・データの体系的な分析により、品質問題、データ・タイプの分布、NULL 率、制約違反を特定します。プロファイリングは、実際に移行しているものを正確に把握し、移行していると考えているものを正確に把握します。
• データ・クレンジング：移行開始前にプロファイリング中に特定された問題を解決します。これには、重複排除、フォーマットの標準化、エンコーディングの問題の修正、古いレコードの削除やアーカイブが含まれます。
• ソースからターゲットへのマッピングの検証：全てのソース・フィールドが有効なターゲット宛先を有し、データ型が互換性があり、変換ロジックが文書化され、テストされていることを確認する。

この評価の結果は、データ移動前に利害関係者が署名するデータ品質レポートである必要があります。これにより責任の所在が明確になり、移行後に発見されたデータ品質の問題が、以前から存在していたソースデータの問題ではなく、移行そのもののせいだと非難されるというよくある事態を防ぐことが可能です。

データ移行により、リスクが一時的に高まります。システム間で転送中のデータは、既知の安全な環境に保存されているデータよりも、潜在的に脆弱である可能性があります。個人情報、財務記録、医療データなど、規制対象のデータを扱う移行戦略は、コンプライアンス要件に明示的に対応する必要があります。

移行時のセキュリティに関する主な考慮事項は次のとおりです。

• 転送中の暗号化：移行パイプライン全体でデータが暗号化されていることを確認します。これは、ネットワーク転送と中間ステージング環境の両方に適用されます。
• アクセス制御：移行システムへのアクセスは、権限のある担当者のみに制限します。移行目的で付与された一時的な昇格権限は、完了後直ちに取り消す必要があります。
• 監査ログ：移行期間中の全てのデータ・アクセスと移動の詳細なログを維持します。これらのログは、運用記録とコンプライアンス文書の両方として機能します。
• データ・レジデンシー：GDPR、HIPAA、またはその他のデータガバナンス規制の対象となる組織は、移行中にデータが非準拠の管轄区域を経由したり、一時的に保存されたりしないことを確認する必要があります。
• ロールバック・ポリシー：移行をロールバックする条件を定義し、カットオーバーの前にロールバックが技術的に実行可能であることを確認します。紙面のみに存在するロールバック計画は、ロールバック計画とはいえません。

規制コンプライアンス要件は、移行実行中に発見されるのではなく、移行前の計画段階で検討・文書化されるべきです。セキュリティ・チームとコンプライアンス・チームを早期に連携させることで、2 週間の移行を 3 か月のプロジェクトに変えるような直前の中断を回避できます。

全てのデータ移行には何らかの形の ETL が伴います。しかし、移行計画の正確な形式は、ビジネス固有のニーズによって異なります。データ・プロファイリング、戦略の選択、セキュリティ・レビューなどの上記のステップは、実行を開始する前に正式な移行計画に盛り込まれる必要があります。

移行計画では、移動するデータの範囲、選択した移行戦略、その理由、ロールバック・ポリシー、検証のテスト基準、ステークホルダーとのコミュニケーションのタイムライン、ソース環境の廃止計画を指定する必要があります。

データセンター移行プロジェクト計画は、移行をスケジュール通りに、予算内で進めるために不可欠です。ここでは、確立された移行手法に基づいた段階的なフレームワークを紹介します。

1. 移行前の計画

移行前の影響評価を実施し、実際の移行コストを検証します。コストの見積もりが具体的な分析や推測に基づいているかどうかを調べます。ベンダーの見積もりや業界平均から抽出された予算の数値が、特定の環境を参照せずに不正確になる可能性があります。経営陣およびIT部門に対し、求められる関与内容について説明を行います。これには、期限が過ぎてからでなければ過小評価されがちな時間的コミットメントも含まれます。

技術的な作業を開始する前に、正式なセキュリティ・ガバナンスの承認を取得してください。プロジェクトの実施体制（アジャイル vs ウォーターフォール）を決定し、役割と意思決定権限を定義し、トレーニング計画を設計し、構成管理ポリシーを確認します。このフェーズの目標は、システムに触れる前に、実施内容と責任者について全員が同意していることを確認することです。

2. プロジェクトの開始

バックオフィスの体制が整っていることを確認してください。関係者とのコミュニケーション計画を作成し、誰がどのチャネルを通じて、どのくらいの頻度で更新を受けるかを指定します。プロジェクトのコラボレーション・プラットフォームをセットアップし、サードパーティのサプライヤー契約を正式なものにし、後のフェーズのハードウェアとソフトウェアの要件を定義します。

サプライヤー契約を省略しないでください。ハードウェアやライセンスが必要になった時点でベンダー契約が締結されていなかったため、移行が停滞するケースは後を絶ちません。これらの作業を早期に完了させることで、遅延の原因となる可能性を排除できます。

3. 環境分析

環境分析は、移行計画の最も重要な段階です。この段階で「移行すると想定しているもの」ではなく、「実際に移行する対象」を特定するからです。この 2 つは、ほとんどの場合一致しません。

詳細なデータ・ディクショナリ、大まかなソースとターゲット間のマッピング仕様、範囲レポートを作成します。ボリューム（データ量、レコード数、依存関係数）を特定し、データ品質管理プロセスを確立し、リスク登録を作成し、発見した内容に基づいてプロジェクトの見積もりを絞り込みます。環境分析前に作成された見積もりは暫定的なものです。分析後に作成された見積もりは確約となります。

4. ソリューション設計

ソースからターゲットへの変換を詳細にマッピングし、構築のための最終的な設計を作成します。このフェーズでは、詳細なマッピング設計仕様、インターフェース設計仕様、データ品質管理仕様など、構築チームが作業の基盤とする成果物が生成されます。

本番ハードウェアの要件を定義し、移行後のターゲット環境だけでなく、移行自体のサービスレベル契約（SLA）について合意します。移行には独自の性能と可用性の要件があり、実行開始前に文書化し、合意する必要があります。

5. 構築とテスト

移行アーキテクチャを実装し、小規模なサンプルではなく、本番環境のミラー環境に対してテストします。実稼働データのごく一部でテストを行っても、性能やスケーラビリティの問題が表面化することはよくあります。移行ロジックを完全に文書化し、チーム・メンバーが組織的な知識に頼ることなく移行を実行またはトラブルシューティングできるようにします。

対象システムのデータ精度を独自に確認するための検証エンジンを開発します。継続的なデータ品質監視を確立し、フォールバック・ポリシーを作成し、実行トレーニングを完了します。カットオーバー当日に移行を実行するチームは、プレッシャーの下で初めて実行するのではなく、事前にリハーサルを済ませておく必要があります。

6. 移行と検証

選択したアプローチ（ビッグバン移行、トリクル移行 、ゼロ・ダウンタイム移行）で移行を実行します。検証は、現段階では形式ではなく、移行が実際に完了したかどうかを決定する基準です。行数、チェックサム、アプリケーション・レベルのテストが全て合格したことを個別に確認してから、成功を宣言します。

このフェーズの一環として、監査担当者やビジネス・スポンサーへのコンプライアンスを実証します。コンプライアンスに関する文書が後回しの場合は、新しい環境の本番稼働に遅れが生じることを覚悟しなければなりません。

7. 廃止と監視

ターゲット・システムが検証され、実稼働負荷下で安定して動作した後でのみ、レガシー環境を廃止します。両方の環境を無期限に実行するとコストが増大し、同期化のリスクが発生します。しかし、安定性が確認されるまでに、あまりにも早く削減しすぎると、さまざまな問題が発生します。

データ品質の監視の責任を適切なチームに転送し、引き継ぎを明確に文書化します。システム廃止の検証を完了し、監査目的で廃止プロセスを文書化します。正式な廃止フェーズなしに移行がカットオーバーで終わると、孤立したシステムが意図したよりも長く動作し、多くの場合、実際のインフラ・コストが発生する傾向があります。

データ移行を成功させている組織には、移行に苦労している組織がしばしば見落としがちな、いくつかの共通した実践方法があります。

• 移行計画ではなく、データ監査から始める：ソース・データの現状、すなわち品質問題、依存関係、ボリュームを理解することは、戦略的計画に先立って行う必要があります。データ・プロファイリングの前に対象を絞り込んだ移行には、ほとんどの場合、プロジェクト中程度の再構成が必要です。
• 不要なデータは絶対に移行しない：移行は、もはやビジネス目的に役立たないデータをアーカイブまたは削除する好機です。不要なデータを移動することで、コスト、時間、リスクが増大します。
• 本番環境規模のデータでテストを行う：少量のサンプルを用いたテストでは、本番環境の全データ量で初めて顕在化するパフォーマンスやスケーラビリティの問題を、しばしば発見できません。テスト環境で ETL 処理に 2 時間かかる場合、本番環境の全データでは 20 時間かかるものと見込んでください。
• カットオーバー前に成功基準を定義する：開始前に「移行の成功」が具体的に何を意味するのかを明確に把握しておく必要があります。具体的には、行数の正確な数値、整合性チェック、アプリケーション機能テストなどです。明確な基準がなければ、移行が完了したことを宣言する客観的な根拠が得られません。
• 影響を受けるユーザーとのコミュニケーションをとる：エンドユーザーやアプリケーションの所有者は、移行後に問題が発生した場合に何を、いつ、何をすべきかを知る必要があります。コミュニケーション不足は、技術的な成功を組織の問題に発展させます。
• 必要になる前にロールバック計画を策定する：ロールバック計画は、単に文書化するのではなく、テストする必要があります。ロールバック手順を知ることは、技術的に妥当であり、カットオーバー期間のプレッシャーを大幅に低減します。

データ移行は、プロジェクトベースの活動から、継続的な運用能力へと進化しています。多くの組織がマルチクラウド戦略を採用し、ワークロードを環境間で動的に移動するにつれ、「移行」と「日常的なデータ管理」の境界は曖昧になってきています。

の変化を牽引しているのは自動化です。AI を活用したデータ・プロファイリング・ツールは、手動分析なしで品質の問題を特定し、変換ルールを提案できるようになりました。インテリジェントな移行プラットフォームは、データの同期をリアルタイムで監視し、問題が発生する前に、移行中の異常にフラグを立てることができます。データ・ファブリック・アーキテクチャ上に構築されたストレージ・プラットフォームは、例外的な手順ではなくネイティブな機能として、無停止のデータ・モビリティをますますサポートするようになっています。

データ移行への対応を一時的な取り組みと捉えるのではなく、継続的に対応できる体制をデータ・インフラに組み込んでいる組織は、データ環境が進化し続けるなかで、競争上の優位性を確立できます。移行に必要なプロセスやツールを整備する最適なタイミングは、次の移行計画が持ち上がる前です。

データ・ストレージは、あらゆる移行の基盤となります。業務を中断させずにデータを移動できるストレージ・インフラがなければ、組織は長引くダウンタイムと複雑な回避策のどちらを選ぶかという難しい選択を迫られます。

Evergreen アーキテクチャを基盤とする Everpure のサブスクリプション・サービスは、従来のストレージ・アレイが必要とするアップグレード・サイクルやメンテナンス機関を排除し、データ移行を容易で手頃な価格で実現するように設計されています。

• Evergreen//One は、ストレージの管理とサポートの複雑さとコストを削減し、IT リスクを軽減するとともに、財務面での柔軟性と運用の簡素化を実現します。
• Evergreen//Flex は、需要や用途の変化に柔軟に対応し、ストレージの俊敏性を高め、初期コストを抑えつつ容量利用における ROI を最大化します。
• Evergreen//Foreverは、真の IT 俊敏性を実現します。ストレージを一度購入すれば、ペナルティなしで、業務に支障をきたすことなく、無期限に拡張が可能です。

クラウド環境への移行、またはクラウド環境間で移行する組織のために、Everpure の統合ストレージ・プラットフォームは、移行ライフサイクル全体を通じてデータ・レジリエンシーと継続性をサポートします。その結果、移行による業務への影響が軽減され、予測可能性が高まり、多くの移行プロジェクトに見られるようなコストやスケジュールの超過が発生しにくくなります。

Everpure の Evergreen ポートフォリオでは、次回のデータ移行をシンプルにする専用のストレージ・インフラについて解説しています。