皆さん、こんにちは。MS開発部の古薮（伊故海）です。
 
前回は移行企画における重要なポイントのうち、「現状の把握」について説明しました。
今回は、「移行対象の選定」について説明いたします。

「移行対象の選定」はなぜ必要か 

移行計画を立てる際、真っ先に考えられる方法として、「全て移行する」事が考えられますが、あまり得策ではありません。
 
家の引越をイメージいただきたいのですが、全ての荷物を運送すると引越業者からの請求が高くなるだけでなく、新しい家に利用していない家具、家電等を設置しても、ただの飾りになってしまいます。
よって必要なものだけを運ぶ方が多いかと思います。
 
またピアノ等の特殊な物は、専門の業者を利用して運搬をするケースが大半です。
 
SharePointでの移行も、家の引越と同様で、必要な物、特殊な物をどのように対処するかを事前に検討しておく必要があります。
 
 

古いデータの扱いの検討

まず考えるポイントとしては、利用していないサイトの扱いです。
 
紙媒体の場合は、物理的にデータが存在する為、データが一杯になってくると
作業スペースの邪魔になり、シュレッダー等で捨ててしまうケースが大半です。
 
一方でグループウェアやファイルサーバーは、データがデジタル化して保管されている関係で、データが一杯になっても利用者が物理的に影響を受けない為、そのまま放置しているケースが大半です。
 
SharePointの現状把握でも挙げた通り、サイト数とサイズはそのままデータ移行時の作業ボリュームに影響します。

ある程度利用していないサイトについては移行対象から外す事で移行ボリュームを減らす事が可能となり、結果的に移行費用と期間の圧縮化につながります。

カスタマイズの扱い 

次に考える内容として、カスタマイズしたアプリの扱いです。
 
カスタマイズしたアプリは、前回の記事でも記載した通り、移行ツールでの移行はできません。
（正確にはモノの移行はできますが、動かない、壊れる等の問題が発生します）
よってカスタマイズしたアプリを移行する際は、チューニングや開発等の作業が必要になってきます。
 
カスタマイズしたアプリの移行可否、移行する場合の責任範囲、ベンダーへの依頼範囲等を予め検討しておく必要があります。
 

 

まとめ

３回にわたって移行企画時のポイントについて纏めてみました。  

「現状の把握」、「移行対象の選定」をきちんと行う事で、作業を行う際の費用とスケジュールのボリューム、難易度が見えてくるだけでなく、後の移行設計時に、技術者がサイト毎に細かい分析を行った際の実情との乖離が少なくなります。
 
移行元のグループウェアに対して、情報システム部等である程度の統制をかけている場合は、使い方が統一されている為に、移行企画を行いやすいのですが、統制をかけずに利用ユーザー側で独自に運用・開発までを行っている場合は、現状の把握で大変時間がかかり、移行企画の段階に持っていくだけで大変苦労します。

移行をまだ検討していない場合でも将来の移行を考慮して、移行先のSharePointの運用設計を一度見直すのも良いかもしれません。

弊社ではSharePointへの移行サービスを行っており、移行企画、設計～切替迄の全フェーズの対応から、特定フェイズのみの支援、カスタマイズしたサイトの移行までフレキシブルに対応しております。
 
その他弊社の業務にご興味のある方は、お気軽にお問い合わせください。
（お問い合わせはこちらのページをご確認の上、メールアドレス「info@deepcom.co.jp」までご連絡ください。）