|
今回は「まず最初に何をすべきか」を書いていこうと思います。 最初に実施するのは ・既存システム内の全データの洗い出しと移行先の選定 ・移行検証用の環境構築 です。 ※「最初」と言いながら、2つ挙げてますが・・・ データ量の多少にかかわらず、すべてのデータを一覧化（見える化）し「移行考慮漏れ」のリスクを可能な限り減らしましょう。 すでに移行先が決まっているデータも、一覧に載せてください。（抜け漏れ防止） ※一覧を作成する際、そのデータの最終更新日と管理者も明記します。（結構重要です） 一覧ができたら次は移行先の検討と検証用環境の構築です。 検証用環境は”一旦デフォルト（初期値設定）”で構築します。 細かい設定は “運用設計時” や “移行方針検討時” に実施するといいでしょう。 （最初からガッチリ設計すると、後で変更するのが難しくなる場合があるので。） |
| 検討方針としては |
|
1. 移行するもの／しないもの／破棄するもの 2. 移行はするが「移行先がSharePointではない」もの 3. SharePointに移行するもの を考えます。 では「移行方針」についてちょっと細かくお話しします。 |
目次
1. 移行するもの／しないもの／破棄するもの
|
※ある意味「棚卸」です。 ここでは、「移行する／しない／削除する」を判断します。 なので、「SharePointに移行」とか「○○サイトに移行」は一旦無視します。 この作業で以下を確定させます。 ・「管理者不明のデータ」の処遇 例）新しい管理者を立てる ／ 移行せず削除する ／バックアップ目的でデータのみ移行する（権限は移行しない） ・確実に移行しないデータの洗い出し 例）長期間使用していないデータ且つ、将来利用しないと判断できたもの ・移行するデータの洗い出し（不要アイテムの棚卸） 例）現在利用中且つ、今後も利用する予定の情報 ／ 過去アイテムの棚卸 |
2. SharePointに移行しないもの
|
次に、「SharePoint にもっていくか否か」を判断します。 判断ポイントとしては ・SharePoint の標準機能で対応可能か否か ・ワークフロー機能を有しているか否か となります。 SharePoint 側にカスタマイズを施すことで、すべてのデータベースを移行することは可能かもしれませんが、移行後の運用負荷は非常に高くなります。（最悪、仕様変更などで動作しなくなるリスクもあります） また、移行不可となったデータベースについてもフォローする必要があります。 ・他の代替システムを提示する ・SharePoint に移行可能な業務運用を提案する（SharePoint への移行対象とする） |
3. SharePointに移行するもの
|
最後に「どのように移行するか」を検討します。 ・移行ツールを利用（3rdパーティ製、独自開発のスクリプト など） ・csvにエクスポートしたものをSharePoint にインポートする ・利用者に手動で移行してもらう |
|
さて、ここまでで移行元の対応方針はほぼ完了しましたので、次のステップに進みましょう。 次回は構築した検証環境の使い道についてお話ししようと思います。 |
