Data Migration Checklist

320万ドルの失敗がデータ移行へのアプローチを変えた

2019年3月の火曜日の午前2時47分の電話を今でも覚えています。クライアントの顧客データベース全体—1800万件以上のレコード—が、レガシーのOracleシステムから最新のクラウドベースのPostgreSQLインフラへのルーチン移行の際に破損しました。ロールバックは失敗し、バックアップは不完全でした。そして、私はそのプロジェクトを担当していた主任データアーキテクトでした。

その事件は、会社に320万ドルの損失をもたらしました。これは、失われた収益、緊急回復作業、規制の罰金によるものでした。もっと重要なのは、何千人もの顧客の信頼を失ったことです。デジタルの空白に埋もれた注文があったからです。私はサラ・チェンで、過去14年間をデータ移行スペシャリストとして過ごし、フォーチュン500企業や急成長するスタートアップとともに、最も重要な資産—データ—を一つのシステムから別のシステムに移動してきました。その壊滅的な失敗は、私にデータ移行についてのことを、以前の8年間の成功したプロジェクトの合計以上に教えてくれました。

あの夜以来、私は47の大規模データ移行プロジェクトを指導し、一度も重大な失敗を経験していません。その違いは？計画と実行に対する系統的でパラノイア的なアプローチを、包括的なチェックリストに洗練させました。これは、データ移行について話を読んだだけの誰かからの理論的なアドバイスではなく、物事がうまくいかない場合に何が起こるかを見て、どうすればそれを避けられるかを学んだ人間の戦闘実績に基づく知恵です。

データ移行は、組織が一貫して過小評価するタスクの一つです。ガートナーの2023年の調査によれば、データ移行プロジェクトの83%が完全に失敗するか、予算とタイムラインを超過します。平均的な企業のデータ移行には計画の40%余分に時間がかかり、予算の30%オーバーします。しかし、多くの人が気づかないのは、データを移動する技術的複雑さが通常の問題ではないということです。問題なのは、組織がスキップまたは急いで行う計画、検証、およびリスク管理です。

実際に移行しているものの理解

コードの1行に触れる前に、または移行ツールを構成する前に、正確に何を扱っているのかを理解する必要があります。これは明白のように聞こえますが、チームがデータ環境を知っていると仮定してプロジェクトが失敗するのを数え切れないほど見てきました。ある小売クライアントとのプロジェクトでは、運用に重要な23の文書化されていないデータベースが発見されました—それは、アーキテクチャ図に載っておらず、会社の中でも存在を知っているのは3人だけでした。

"データ移行で最も高価な部分は技術ではなく、ソースデータが実際よりもきれいであるという仮定です。"

包括的なデータインベントリから始めてください。これは、すべてのデータベース、すべてのテーブル、すべてのフィールドをカタログ化し、それらの間の関係を理解することを意味します。しかし、それ以上に深い内容です。データの系譜を理解する必要があります—このデータは最初にどこから来たのか？どのシステムがそれに依存しているのか？このデータが1時間でも利用できなかった場合、どのビジネスプロセスが損なわれるのか？

私はデータ資産のために三層の分類システムを使用しています。Tier 1データはミッションクリティカルであり—このデータが利用できないまたは破損している場合、ビジネスは機能しなくなります。顧客の注文、財務取引、または在庫記録を考えてください。Tier 2データは重要ですが、直ちにクリティカルではないもの—過去の分析データやアーカイブされた顧客コミュニケーションかもしれません。Tier 3データは持っていると良いが必須ではないもの—古いマーケティングキャンペーンデータや廃止された製品情報です。

この分類は、移行戦略のすべてを駆動します。Tier 1データは、最も厳格なテスト、最も慎重な移行アプローチ、最も包括的なバックアップ戦略を受けます。最近の医療クライアントのために、合計34TBのデータセットから847GBのTier 1データを特定しました。そのTier 1データは、残りのデータの合計に対して10倍の検証テストを受けました。

データの品質問題を前もって文書化してください。すべてのレガシーシステムには問題があります—重複レコード、一貫性のないフォーマット、孤立した参照、存在すべきでないヌル値があります。私は、完璧にクリーンなソースシステムに出会ったことはありません。ある金融サービスクライアントでは、さまざまなフィールドに14種類の異なる日付フォーマットがある顧客レコードがありました。別のクライアントには、製品コードが数値の場合もあれば、英数字の場合もあり、ターゲットシステムを破損する特別な文字を含むことさえありました。

フィールド名やタイプを超えたデータ辞書を作成してください。各フィールドのビジネスの意味、許容される値の範囲、他のフィールドへの依存関係、適用する必要のある変換ルールを文書化します。これが移行プロセス全体での真実の唯一の情報源になります。質問が発生した場合—必ず発生します—あなたは決定的なリファレンスを持っています。

移行チームとガバナンス構造の構築

データ移行は単独スポーツではなく、ただのITプロジェクトではありません。私が主導した最も成功した移行は、技術チームだけでなく、ビジネスステークホルダーからの強い代表がありました。あなたは、データが何を意味するのかを理解している人々が必要です、ただ技術的にどのように構造されているのかだけではありません。

コア移行チームには、技術的な側面とビジネス的な側面の両方を理解するプロジェクトマネージャー、実際の移行作業を行うデータエンジニア、ソースシステムとターゲットシステムの両方からのデータベース管理者、データがどのように使用されるのかを理解するアプリケーション開発者、移行されたデータがビジネスの観点から妥当であることを検証できるビジネスアナリストを含めるべきです。

しかし、同じくらい重要なのは、あなたのステークホルダーや意思決定者です。問題が発生したときに迅速に決定を下せるエグゼクティブスポンサーを特定してください。信じてください、あなたはそれらの人々が必要です。ある移行プロジェクトでは、ターゲットシステムがビジネスが移行したいと考えている歴史データの量を処理できないことを発見しました。古いデータをアーカイブする決定は、すべてを移行するのではなく、エグゼクティブの承認を必要とし、そのスポンサー関係がすでに確立されていたため、数週間ではなく数時間で決定を得ることができました。

RACIマトリックスを使用して、明確な役割と責任を確立してください—移行の各側面について、誰が責任を持つのか、誰が説明責任を持つのか、誰が相談されるのか、誰が通知されるのか。プロジェクトが重要な決定を承認する権限を持つ人が誰なのかを知らないために停止するのを見てきました。あるケースでは、重複する顧客レコードをどう扱うかについての単純な質問が、誰か他の人がその決定を下す責任があると思っていたために、解決するのに3週間かかりました。

定期的なチェックポイントを持つガバナンス構造を作成してください。私は、移行のアクティブなフェーズ中は毎日のスタンドアップ、ステークホルダーとの週次の運営委員会ミーティング、各主要フェーズの前の正式なゴー/ノーゴーの決定ポイントをお勧めします。これらのチェックポイントは官僚主義ではなく—問題のための早期警告システムです。

エスカレーションパスを明確に文書化してください。移行ウィンドウ中の午前3時に何かがうまくいかなくなった場合、あなたのチームは誰にどの順序で電話するべきか正確に知っている必要があります。私は、すべての重要な役割に対して一次およびバックアップの連絡先を含む連絡先リストを維持しています。自宅の電話番号や複数の通信チャネルも含まれています。先ほど述べた2019年の移行で、ロールバックを承認できる人が連絡が取れないという理由で2時間を失いました。

移行戦略とアプローチの設計

データ移行には万能のアプローチはありません。適切な戦略は、データボリューム、許容できるダウンタイム、システムの複雑さ、およびリスク許容度に依存します。私は、シンプルなデータベースのダンプやリストアから、複雑で多段階の移行、並行稼働システムまで、さまざまな方法を使用してきました。

"私が主導したすべての成功したデータ移行には共通点がありました：移行そのものを計画するよりも、ロールバックの計画にもっと多くの時間を費やしました。"

ビッグバンアプローチ—