サーバー移行のリスクを回避するための5つのアクションのヒント

私たちは全員これを知っています：ソリューションAはサーバー1でホストされていますが、サーバー1の信頼性は何らかの理由で問題があるかもしれません。これにより、サーバーの障害、更新の遅延、またはリソースを節約するための仮想化の必要が生じる可能性があります。これは、サーバー2に移行するための正当な理由のほんの一部にすぎません。ユーザーにとっての課題は、ソリューションAに必要な機能とリソースを失うことなく、またはIT部門に対してユーザーからの苦情を招くような過度のダウンタイムを引き起こすことなく、サーバーの移行を完了することです。

では、移行プロセスを慎重に実行し、システム全体を失う危険性がない場合は、このジレンマにどう対処しますか。ダウンタイムゼロを求めるユーザーの厳しい要件をどのように満たしていますか？これらのリスクを回避するのに役立つ5つのヒントがあります。

ヒント1：システム間の依存関係を理解する

ITスタッフはこれを認めたがらないかもしれませんが、確立された移行戦略の解決策を完全には理解していない従業員もいます。それはどのように機能しますか？例としてExchange Serverを取り上げます。 Exchange Serverへの変更は、単一ユーザーの単純な移行から（必要に応じて）サーバー全体の単純な移行から新しいドメインへの簡単な移行まで、いくつかの方法で行うことができます。

この移行は、グッドテクノロジーズサービス、BlackBerry Enterprise Server、Lync、Mobile Technology SuiteなどのシステムからExchangeへの影響（Outlook Web Access /App、Outlook Anywhere、ActiveSync）にローカルで影響を与えることになります。 。電子メールサーバーの移行プロセス中にこれらのエコシステムソリューションを考慮に入れるアプローチとは異なり、すべてのモバイルユーザーをすばやくエクスポートできます。しかし、すべての周辺システムを完全に理解することはできず、ターゲット移行システムはこれらの周辺システムに依存しているか、または相互依存している可能性があるため、実際の移行の悪夢に陥ります。

ヒント2：移行に必要なものを知ってください。

一連のソリューションは、1つ以上のサーバーまたはハードウェアリソースを含む1つ以上のコンポーネントで構成されています。移行プロセスの正しい手順により、実際の移行を開始する前に、ソリューションの機能と移行されたシステム内の移行部分の量を最初に理解しておく必要があります。ファックスサーバーは、この種のソリューションの最良の例です。多くのビジネスでは、正常な動作を保証するために物理的なファックスカードが必要です。ファックスカードが移行しようとしている新しいハードウェア/仮想化プラットフォームと互換性があることを確認しないと、最良の移行計画が妥協されます。

ヒント3：移行する必要があるものを理解する

現在のプラットフォームから移行する必要があるコンポーネントを計算したら、移行が必要かどうかを徹底的に分析する必要があります。新しいプラットフォームに移行する必要のないシステムコンポーネントは常にいくつかありますが、ダウンタイムの可能性と複雑さを最小限に抑えるために移行が必要になる場合があります。

たとえば、Windowsのシステムステータス情報には、あるハードウェアプラットフォームから別のハードウェアプラットフォームに移行するための適切なツールが必要な場合があります。この情報を移行できれば、少なくともWindowsシステムとソフトウェアの観点からは、新しいサーバー構成の複雑さを大幅に軽減できます。

ヒント4：期待値を設定し、目標に固執する

ユーザーはダウンタイムの移行を達成したい。しかし、残念なことに、このゼロチャーピングの夢は実際の移住の世界では通常不可能です。物理的な移行（ExchangeやNotesでの電子メールの移行など）を実装するときに目に見えるダウンタイムがない場合でも、予期しない緊急事態に対処するために従業員に余裕を持たせる必要があります。システムステータス情報とバイナリの慎重な計画と移行前のすべての作業を移行することで、ダウンタイムの可能性を最小限に抑えることができます。ただし、すべての主要なハードウェア移行プロセスでダウンタイムをなくすことは単なる予想事項であり、達成するのは難しい場合があります。

適切な数のダウンタイムを設定して、ITスタッフからユーザーまで、ダウンタイムが発生する可能性がある時間と所要時間を確実に把握します。このダウンタイムがユーザーに受け入れられない場合は、その理由を実行する必要がある理由と、システムから発生する可能性がある壊滅的な結果について説明してください。

ヒント5：あなたが必要とするツールを手に入れよう

移行はしばしばルールの理解不足により予期せぬ結果を招く。例：ローカルの物理マシンから仮想マシンに移行する多くのツールでは、移行プロセス中にデータを静的に保つ必要があります（データベース管理者のみ）。 SQLまたはこのようなサーバーの場合、これは、プロセスでデータが失われる大きなリスクがあるため、移行プロセス中はデータベースをオフラインにする必要があることを意味します。物理マシンが仮想マシンに移行するツールも、物理サーバーから仮想マシンへの一方向の移行です。これは操作上の制限です。物理マシンから仮想マシンへの移行のみが実行可能な場合は、別の物理マシンに移行しようとしても役に立ちません。移行しても問題が解決しない場合は、アプリケーションソフトウェアは新しい環境では期待した状態に到達しません。

ニーズに合ったツールライブラリを選択します - 一般的な方法は、ローカルツールとサードパーティ製ツールを組み合わせて、移行を安全に実行し、計画どおりに実装できるようにすることです。これら5つのヒントを一緒に使用すると、その点を見逃すことがなくなり、移行の実装時に最小限のダウンタイムで新しいプラットフォームに移行できます。