そんな時間はない、完了まで1年だ……という場合、移転先の環境や移転のタイミングはかなり狭まるでしょう。システムの停止がしにくい場合はトップダウンでの調整が必要になるかもしれません。
システムの更改タイミングにあわせて移行するのであれば、より長い期間がかかります。しかし、そうであっても、データセンターを重複利用する期間は減らしたいですね。
システムに対して更改時期の前倒しを依頼する、また現在のデータセンターのラックを、移転が終わった部分について順々に解約していけないか検討するのも必要です。
また、「新データセンターへの移転はせず、クラウド移行する/システム廃止する」としていたシステムが「やっぱり、更改が間に合わないのでとりあえず移転したいんだけど……」という要望もよく見受けられます。それらのシステムを新データセンターに逃がしきるためにも、計画上の完了とデータセンターの解約の間には余裕を持たせましょう。
2.計画を家族=システムと共有しよう
住宅の引っ越しであれば、実際の回数は1回か2回でしょう。しかし、データセンター移転は、システムを家族それぞれと考えると20~30人の大家族の引っ越しにあたります。各人それぞれの生活や事情、引っ越しのために休める日の制約があるなか、スムーズに引っ越しするにはどうしたらよいでしょうか。
整理するのは「スケジュール」と「役割分担」です。そして、この二つをプロジェクトチームである程度仮決めして「移転計画書」として各システムに周知し、不都合があれば調整する、という進め方をするとスムーズです。
2.1スケジュール
引越期間が長いほど、新居と旧居の平行稼働期間が長くなり、引越回数が多いほど搬送費用がかさみコスト増になります。なるべく移転するシステムを集約し、回数を減らし、早期に現在のデータセンターを明け渡せることが望ましいです。
一方で「年末年始やお盆、ゴールデンウイークしか移転ができない」といったシステムがある場合、リハーサルや失敗時の再実施予定日を含めると計画が長期化する可能性があります。
どのシステムをいつ移転させるか、という観点では、開発・検証環境から先に移転させ、稼働確認後に別日程で本番環境を移転させる、というのが一般的です。また、停止調整のしやすい、比較的小規模なシステムから移転をスタートさせてプロジェクト全体の移転スキルの習熟を図ることが多いです。
・なるべく搬送回数は少なく、引っ越しをまとめる
・開発系→本番系
・最初は小規模システムから
2.2役割分担
各システムにとって、移転の準備でまず知りたいのは「いつ移転するのか(スケジュール)」とともに、「自分たちは何をすればよいのか」ということでしょう。移転プロジェクトチームとの「タスクの役割分担」と「コスト負担の役割分担」の線引きが明確になっている必要があります。