レガシーデータを台無しにせずに移行する

公開: 2022-03-11

レガシーデータの移行は困難です。

多くの組織には、古くて複雑なオンプレミスのビジネスCRMシステムがあります。今日、クラウドSaaSの選択肢はたくさんあり、多くの利点があります。従量制で、使用した分だけ支払う。したがって、彼らは新しいシステムに移行することを決定します。

古いシステムに顧客に関する貴重なデータを残し、空の新しいシステムから始めたいと思う人はいないため、このデータを移行する必要があります。残念ながら、展開作業の約50％がデータ移行アクティビティによって消費されるため、データ移行は簡単な作業ではありません。 Gartnerによると、SalesforceはクラウドCRMソリューションのリーダーです。したがって、データ移行はSalesforceデプロイメントの主要なトピックです。

レガシーデータを新しいシステムに確実に移行する方法
すべての歴史を保存しながら。

つぶやき

では、レガシーデータを光沢のある新しいシステムに正常に移行し、そのすべての履歴を確実に保持するにはどうすればよいでしょうか。この記事では、データ移行を成功させるための10のヒントを紹介します。最初の5つのヒントは、使用するテクノロジーに関係なく、すべてのデータ移行に適用されます。

一般的なデータ移行

1.移行を別のプロジェクトにする

ソフトウェア展開チェックリストでは、データ移行は、ターゲットシステムのマッピングが事前定義されている巧妙な「ボタンを1つ押す」データ移行ツールによって処理される「エクスポートおよびインポート」項目ではありません。

データ移行は複雑なアクティビティであり、個別のプロジェクト、計画、アプローチ、予算、およびチームに値します。プロジェクトの開始時にエンティティレベルのスコープと計画を作成する必要があります。「ああ、クライアントの訪問レポートを読み込むのを忘れたのですが、誰がそれを行うのでしょうか」などの驚きがないようにします。締め切りの2週間前。

データ移行アプローチでは、データを一度にロードするか（ビッグバンとも呼ばれます）、毎週小さなバッチをロードするかを定義します。

ただし、これは簡単な決定ではありません。新しいシステムにいつどのようなデータが表示されるかを全員が認識できるように、このアプローチについて合意し、すべてのビジネスおよび技術の利害関係者に伝達する必要があります。これは、システムの停止にも当てはまります。

2.現実的に見積もる

データ移行の複雑さを過小評価しないでください。このプロセスには多くの時間のかかるタスクが伴いますが、プロジェクトの開始時には見えない場合があります。

たとえば、トレーニング目的で特定のデータセットをロードし、現実的なデータの束を使用しますが、機密項目は難読化して、トレーニングアクティビティがクライアントへの電子メール通知を生成しないようにします。

見積もりの基本的な要素は、ソースシステムからターゲットシステムに転送されるフィールドの数です。

プロジェクトのさまざまな段階で、フィールドの理解、ソースフィールドのターゲットフィールドへのマッピング、変換の構成または構築、テストの実行、フィールドのデータ品質の測定など、フィールドごとにある程度の時間が必要です。

Jitterbit、Informatica Cloud Data Wizard、Starfish ETL、Midasなどの巧妙なツールを使用すると、特にビルドフェーズでこの時間を短縮できます。

特に、移行プロジェクトで最も重要なタスクであるソースデータの理解は、ツールでは自動化できませんが、アナリストはフィールドのリストを1つずつ確認する必要があります。

全体的な作業の最も簡単な見積もりは、レガシーシステムから転送されたすべてのフィールドに対して1人日です。

例外は、同じソーススキーマとターゲットスキーマの間で、さらに変換せずにデータを複製することです。これは、1：1移行とも呼ばれ、コピーするテーブルの数に基づいて見積もりを行うことができます。

詳細な見積もりはそれ自体が芸術です。

3.データ品質を確認します

レガシーシステムからデータ品質の問題が報告されていない場合でも、ソースデータの品質を過大評価しないでください。

新しいシステムには新しいルールがあり、レガシーデータに違反する可能性があります。これが簡単な例です。新しいシステムでは連絡先の電子メールが必須になる場合がありますが、20年前のレガシーシステムは別の見方をしている可能性があります。

長い間触れられていないが、新しいシステムに転送するときにアクティブになる可能性がある履歴データに隠された地雷が存在する可能性があります。たとえば、もう存在しないヨーロッパの通貨を使用する古いデータはユーロに変換する必要があります。そうでない場合は、新しいシステムに通貨を追加する必要があります。

データ品質は労力に大きく影響します。単純なルールは次のとおりです。履歴を進めるほど、より大きな混乱が発見されます。したがって、新しいシステムに転送する履歴の量を早期に決定することが重要です。

4.ビジネスマンを引き込む

データを真に理解しているのはビジネスマンだけです。したがって、どのデータを破棄し、どのデータを保持するかを決定できます。

マッピングの演習にはビジネスチームの誰かが関与することが重要であり、将来のバックトラックのために、マッピングの決定とその理由を記録しておくと便利です。

写真は1000語以上の価値があるので、新しいシステムにテストバッチをロードして、ビジネスチームに試してもらいます。

データ移行マッピングがビジネスチームによってレビューおよび承認された場合でも、データが新しいシステムのUIに表示されると、驚きが生じる可能性があります。

「ああ、そうですね、少し変更する必要があります」というのが一般的なフレーズになります。

新しいシステムが稼働した後の問題の最も一般的な原因は、通常は非常に忙しい人々である対象分野の専門家を雇わないことです。

5.自動移行ソリューションを目指す

データ移行は1回限りのアクティビティと見なされることが多く、開発者は、1回だけ実行することを望んでいる手動アクションでいっぱいのソリューションになってしまう傾向があります。しかし、そのようなアプローチを避ける理由はたくさんあります。

移行が複数のウェーブに分割されている場合、同じアクションを複数回繰り返す必要があります。
通常、すべてのウェーブに対して少なくとも3つの移行実行があります。データ移行のパフォーマンスと機能をテストするためのドライラン、データセット全体をテストしてビジネステストを実行するための完全なデータ検証負荷、そしてもちろん本番負荷です。データ品質が低いと、実行回数が増えます。データ品質の改善は反復プロセスであるため、目的の成功率に到達するには数回の反復が必要です。

したがって、移行が本質的に1回限りのアクティビティである場合でも、手動でアクションを実行すると、操作が大幅に遅くなる可能性があります。

Salesforceデータ移行

次に、Salesforceの移行を成功させるための5つのヒントについて説明します。これらのヒントは、他のクラウドソリューションにも当てはまる可能性が高いことに注意してください。

6.長時間の負荷に備える

オンプレミスからクラウドソリューションに移行する場合、パフォーマンスは最大ではないにしても、トレードオフの1つです。Salesforceは除外されません。

オンプレミスシステムでは通常、基盤となるデータベースへの直接データの読み込みが可能であり、優れたハードウェアを使用すると、1時間あたり数百万のレコードに簡単に到達できます。

しかし、クラウドではありません。クラウドでは、いくつかの要因によって大きく制限されています。

ネットワーク遅延–データはインターネット経由で転送されます。
Salesforceアプリケーション層–データはOracleデータベースに到達するまで厚いAPIマルチテナンシー層を介して移動されます。
Salesforceのカスタムコード–カスタム検証、トリガー、ワークフロー、重複検出ルールなど–これらの多くは並列ロードまたは一括ロードを無効にします。

その結果、読み込みパフォーマンスは1時間あたり数千のアカウントになる可能性があります。

フィールドの数、検証、トリガーなどに応じて、少なくすることも多くすることもできます。ただし、データベースを直接ロードするよりも数段階遅くなります。

Salesforceのデータ量に依存するパフォーマンスの低下も考慮する必要があります。

これは、外部キーのチェック、一意のフィールド、および複製ルールの評価に使用される、基盤となるRDBMS（Oracle）のインデックスが原因で発生します。基本的な式は、ソートおよびBツリー操作の時間計算量部分であるO（logN）が原因で、10のグレードごとに約50％の速度低下です。

さらに、Salesforceには多くのリソース使用制限があります。

それらの1つは、24時間ローリングウィンドウで5,000バッチに設定されたバルクAPI制限であり、各バッチで最大10,000レコードです。

したがって、理論上の最大値は、24時間でロードされる5000万レコードです。

実際のプロジェクトでは、たとえばカスタムトリガーを使用する場合、バッチサイズが制限されるため、最大値ははるかに低くなります。

これは、データ移行アプローチに大きな影響を及ぼします。

中規模のデータセット（100,000から100万のアカウント）の場合でも、ビッグバンアプローチは問題外であるため、データをより小さな移行の波に分割する必要があります。

もちろん、これは展開プロセス全体に影響を与え、移行の複雑さを増します。これは、以前の移行とユーザーが入力したデータが既に入力されているシステムにデータの増分を追加するためです。

また、移行の変換と検証において、この既存のデータを考慮する必要があります。

さらに、負荷が長くなると、システムの停止中に移行を実行できなくなる可能性があります。

すべてのユーザーが1つの国にいる場合、夜間の8時間の停止を活用できます。

しかし、コカ・コーラのように世界中で事業を展開している企業にとって、それは不可能です。システムに米国、日本、ヨーロッパが含まれると、すべてのタイムゾーンにまたがるため、ユーザーに影響を与えない唯一の停止オプションは土曜日です。

そして、それだけでは不十分かもしれないので、ユーザーがシステムを操作しているときに、オンライン中にロードする必要があります。

7.アプリケーション開発における移行のニーズを尊重する

検証やトリガーなどのアプリケーションコンポーネントは、データ移行アクティビティを処理できる必要があります。システムがオンラインである必要がある場合、移行のロード時に検証をハードに無効にすることはできません。代わりに、データ移行ユーザーによって実行された変更の検証にさまざまなロジックを実装する必要があります。

日付フィールドを実際のシステム日付と比較しないでください。これにより、履歴データのロードが無効になります。たとえば、検証では、移行されたデータの過去のアカウント開始日を入力できるようにする必要があります。
履歴データが入力されていない可能性のある必須フィールドは、必須ではないものとして実装する必要がありますが、検証はユーザーに敏感であるため、移行からのデータには空の値を許可しますが、GUIを介して通常のユーザーからの空の値は拒否します。
トリガー、特に統合に新しいレコードを送信するトリガーは、移行されたデータによる統合のフラッディングを防ぐために、データ移行ユーザーのオン/オフを切り替えることができる必要があります。

もう1つのトリックは、移行されたすべてのオブジェクトでフィールドLegacyIDまたはMigrationIDを使用することです。これには2つの理由があります。 1つ目は明らかです。バックトラックのために古いシステムからIDを保持すること。データが新しいシステムに入った後も、電子メール、ドキュメント、バグ追跡システムなどの場所にある古いIDを使用してアカウントを検索したい場合があります。悪癖？多分。ただし、古いIDを保持しておけば、ユーザーはあなたに感謝します。 2番目の理由は技術的なものであり、Salesforceが（Microsoft Dynamicsとは異なり）新しいレコードに対して明示的に提供されたIDを受け入れないが、ロード中にそれらを生成するという事実に由来します。親オブジェクトのIDを割り当てる必要があるため、子オブジェクトをロードするときに問題が発生します。これらのIDはロード後にのみわかるため、これは無駄な演習です。

アカウントとその連絡先を使用してみましょう。次に例を示します。

アカウントのデータを生成します。
アカウントをSalesforceにロードし、生成されたIDを受け取ります。
連絡先データに新しいアカウントIDを組み込みます。
連絡先のデータを生成します。
Salesforceに連絡先をロードします。

これを行うには、特別な外部フィールドに保存されているレガシーIDを使用してアカウントをロードするだけです。このフィールドは親参照として使用できるため、連絡先を読み込むときに、アカウントのレガシーIDを親アカウントへのポインターとして使用するだけです。

レガシーIDを含むアカウントのデータを生成します。
アカウントレガシーIDを含む連絡先のデータを生成します。
アカウントをSalesforceにロードします。
親参照としてアカウントレガシーIDを使用して、Salesforceに連絡先をロードします。

ここでの良い点は、生成フェーズとロードフェーズを分離したことです。これにより、並列処理が向上し、停止時間が短縮されます。

8.Salesforce固有の機能に注意してください

他のシステムと同様に、Salesforceには、データ移行中の不快な驚きを避けるために知っておくべきトリッキーな部分がたくさんあります。ここにいくつかの例があります：

アクティブユーザーの一部の変更により、ユーザーの電子メールへの電子メール通知が自動的に生成されます。したがって、ユーザーデータを操作する場合は、最初にユーザーを非アクティブ化し、変更が完了した後にアクティブ化する必要があります。テスト環境では、通知がまったく送信されないようにユーザーの電子メールをスクランブルします。アクティブユーザーは高額なライセンスを消費するため、すべてのテスト環境ですべてのユーザーをアクティブにすることはできません。たとえば、トレーニング環境でアクティブユーザーのみをアクティブ化するには、アクティブユーザーのサブセットを管理する必要があります。
アカウントやケースなどの一部の標準オブジェクトの非アクティブなユーザーは、システム権限「非アクティブな所有者によるレコードの更新」を付与した後にのみ割り当てることができますが、たとえば、連絡先やすべてのカスタムオブジェクトに割り当てることができます。
連絡先を無効にすると、すべてのオプトアウトフィールドがサイレントにオンになります。
重複するアカウントチームメンバーまたはアカウント共有オブジェクトをロードすると、既存のレコードがサイレントに上書きされます。ただし、重複するOpportunity Partnerをロードすると、レコードが追加されるだけで重複が発生します。
Created Date 、 Created By ID 、 Last Modified Date 、 Last Modified By IDなどのシステムフィールドは、新しいシステム権限「レコード作成時に監査フィールドを設定する」を付与した後にのみ明示的に書き込むことができます。
フィールド履歴の値の変更は、まったく移行できません。
ナレッジ記事の所有者は、ロード中に指定することはできませんが、後で更新することができます。
トリッキーな部分は、Salesforceへのコンテンツ（ドキュメント、添付ファイル）の保存です。これを行うには複数の方法があり（添付ファイル、ファイル、フィードの添付ファイル、ドキュメントを使用）、それぞれの方法には、さまざまなファイルサイズの制限など、長所と短所があります。
選択リストフィールドは、ユーザーに許可された値の1つ（たとえば、アカウントのタイプ）を選択するように強制します。ただし、Salesforce API（またはApex DataLoaderやInformaticaSalesforceコネクタなどのその上に構築されたツール）を使用してデータをロードする場合、任意の値が渡されます。

リストは続きますが、要点は次のとおりです。システムに精通し、仮定を立てる前に、システムで何ができるか、何ができないかを学びます。特にコアオブジェクトの場合、標準的な動作を想定しないでください。常に調査とテストを行ってください。

9.Salesforceをデータ移行プラットフォームとして使用しないでください

特にSalesforce開発者にとって、データ移行ソリューションを構築するためのプラットフォームとしてSalesforceを使用することは非常に魅力的です。これは、Salesforceアプリケーションのカスタマイズと同じテクノロジー、同じGUI、同じApexプログラミング言語、同じインフラストラクチャです。 Salesforceには、テーブルとして機能できるオブジェクトと、一種のSQL言語であるSalesforce Object Query Language（SOQL）があります。ただし、使用しないでください。それは根本的なアーキテクチャ上の欠陥になります。

Salesforceは、高度なコラボレーションや豊富なカスタマイズなど、多くの優れた機能を備えた優れたSaaSアプリケーションですが、データの大量処理はその1つではありません。最も重要な3つの理由は次のとおりです。

パフォーマンス– Salesforceでのデータの処理は、RDBMSよりも数段階遅くなります。
分析機能の欠如– Salesforce SOQLは、Apex言語でサポートする必要のある複雑なクエリや分析機能をサポートしておらず、パフォーマンスをさらに低下させます。
アーキテクチャ*–特定のSalesforce環境内にデータ移行プラットフォームを配置することはあまり便利ではありません。通常、特定の目的のために複数の環境があり、コードの同期に多くの時間を費やすことができるように、アドホックに作成されることがよくあります。さらに、その特定のSalesforce環境の接続性と可用性にも依存することになります。

代わりに、RDBMSまたはETLプラットフォームを使用して、別のインスタンス（クラウドまたはオンプレミスの場合があります）でデータ移行ソリューションを構築します。ソースシステムに接続し、必要なSalesforce環境をターゲットにして、必要なデータをステージング領域に移動し、そこで処理します。これにより、次のことが可能になります。

SQL言語またはETL機能のすべての機能と機能を活用します。
すべてのシステムで分析を実行できるように、すべてのコードとデータを1か所にまとめます。
- たとえば、最新のテスト用Salesforce環境の最新の構成を、実稼働のSalesforce環境の実際のデータと組み合わせることができます。
ソースシステムとターゲットシステムのテクノロジーにそれほど依存することはなく、ソリューションを次のプロジェクトに再利用できます。

10.Salesforceメタデータの監視

プロジェクトの開始時に、通常、Salesforceフィールドのリストを取得して、マッピングの演習を開始します。プロジェクト中に、アプリケーション開発チームによってSalesforceに新しいフィールドが追加されたり、一部のフィールドプロパティが変更されたりすることがよくあります。アプリケーションチームに、すべてのデータモデルの変更についてデータ移行チームに通知するように依頼することはできますが、常に機能するとは限りません。安全のために、すべてのデータモデルの変更を監督下に置く必要があります。

これを行う一般的な方法は、Salesforceからいくつかのメタデータリポジトリに移行関連のメタデータを定期的にダウンロードすることです。これを取得すると、データモデルの変更を検出できるだけでなく、2つのSalesforce環境のデータモデルを比較することもできます。

ダウンロードするメタデータ：

ラベル、技術名、およびcreatable可能またはupdatableなどの属性を持つオブジェクトのリスト。
フィールドとその属性のリスト（すべてを取得する方がよい）。
選択リストフィールドの選択リスト値のリスト。入力データをマッピングまたは検証して正しい値にするために、それらが必要になります。
新しい検証が移行されたデータに問題を引き起こしていないことを確認するための検証のリスト。

Salesforceからメタデータをダウンロードする方法は？標準のメタデータメソッドはありませんが、複数のオプションがあります。

エンタープライズWSDLの生成– SalesforceWebアプリケーションでSetup / API ]メニューに移動し、Salesforceのすべてのオブジェクトとフィールドを説明する厳密に型指定されたエンタープライズWSDLをダウンロードします（ただし、選択リストの値や検証は含まれません）。
直接、またはJavaまたはC＃ラッパーを使用してSalesforce describeSObjects Webサービスを呼び出します（Salesforce APIに相談してください）。このようにして、必要なものを取得します。これは、メタデータをエクスポートするための推奨される方法です。
インターネットで利用可能な多数の代替ツールのいずれかを使用します。

次のデータ移行の準備

Salesforceなどのクラウドソリューションはすぐに利用できます。組み込みの機能に満足している場合は、ログインして使用するだけです。ただし、Salesforceは、他のクラウドCRMソリューションと同様に、データ移行のトピックに特定の問題をもたらし、特にパフォーマンスとリソースの制限に関して注意する必要があります。

レガシーデータを新しいシステムに移動することは常に旅であり、過去数年間のデータに隠された歴史への旅である場合もあります。この記事では、12の移行プロジェクトに基づいて、レガシーデータを移行し、ほとんどの落とし穴をうまく回避するための10のヒントを紹介しました。

重要なのは、データが何を明らかにするかを理解することです。したがって、データ移行を開始する前に、Salesforce開発チームがデータが抱える可能性のある潜在的な問題に十分に備えていることを確認してください。

関連：リレーショナルデータベースで立ち往生しているデータアナリストのためのHDFSチュートリアル