移行前にワークロードを評価して前提条件を検証するAssess workloads and validate assumptions before migration

既存のワークロードの多くは、クラウドへの適切な移行候補ですが、すべての資産がクラウド プラットフォームと互換性があるわけではなく、すべてのワークロードがクラウドでのホスティングからメリットを得られるわけではありません。Many of your existing workloads are ideal candidates for cloud migration, but not every asset is compatible with cloud platforms and not all workloads can benefit from hosting in the cloud. デジタル資産計画によって、移行できる可能性があるワークロードの総合的な移行バックログを作成できます。Digital estate planning allows you to generate an overall migration backlog of potential workloads to migrate. ただし、この計画は概要計画です。However, this planning effort is high-level. それは、クラウド戦略チームによる前提条件に依存しており、技術的な考慮事項については深く掘り下げていません。It relies on assumptions made by the cloud strategy team and does not dig deeply into technical considerations.

その結果、ワークロードをクラウドに移行する前に、ワークロードに関連付けられている個々の資産を評価して、移行に適しているかどうかを確認することが重要です。As a result, before migrating a workload to the cloud it's critical to assess the individual assets associated with that workload for their migration suitability. この評価では、クラウド導入チームが、技術的な互換性、必要なアーキテクチャ、期待されるパフォーマンス/サイズ、および依存関係を評価して、移行されたワークロードをクラウドに効率的にデプロイできることを確認する必要があります。During this assessment, your cloud adoption team should evaluate technical compatibility, required architecture, performance/sizing expectations, and dependencies to ensure that the migrated workload can be deployed to the cloud effectively.

この "評価" プロセスは、イテレーション中に発生する 4 つの積み上げアクティビティの最初のアクティビティです。The assess process is the first of four incremental activities that occur within an iteration. 技術的な複雑さと変更管理に関する前提条件の記事で説明したように、このフェーズの実行方法を判断する前に、意思決定を行っておく必要があります。As discussed in the prerequisite article regarding technical complexity and change management, a decision should be made in advance to determine how this phase is executed. 具体的には、実際の移行作業と同じスプリント中にクラウド導入チームが評価を完了するのか?In particular, will assessments be completed by the cloud adoption team during the same sprint as the actual migration effort? または、別のイテレーションで、ウェイブまたはファクトリ モデルを使用して評価を完了するのか?Alternatively, will a wave or factory model be used to complete assessments in a separate iteration? この基本的なプロセスの質問に対して、チームの全メンバーから回答を得ることができない場合は、前提条件に関するセクションに戻ることをお勧めします。If the answer to this basic process question can't be answered by every member of the team, it may be wise to revisit the prerequisites section.

目的Objective

移行に先立って、ワークロード、関連付けられている資産、および依存関係を評価して、移行候補を評価します。Assess a migration candidate, evaluating the workload, associated assets, and dependencies prior to migration.

完了の定義Definition of done

このプロセスは、単一の移行候補に関して、以下が識別されたときに完了します。This process is complete when the following are known about a single migration candidate:

  • 本番環境への昇格方法に関する意思決定を含むオンプレミスからクラウドへのパスが定義されている。The path from on-premises to cloud, including production promotion approach decision, has been defined.
  • クラウド導入チームが移行を実行するために必要な、承認、変更、コストの見積もり、または検証プロセスがすべて完了している。Any required approvals, changes, cost estimates, or validation processes have been completed to allow the cloud adoption team to execute the migration.

評価中の説明責任Accountability during assessment

評価プロセス全体の説明責任は、クラウド導入チームにあります。The cloud adoption team is accountable for the entire assessment process. ただし、クラウド戦略チームのメンバーにも、次のセクションで説明するいくつかの責任があります。However, members of the cloud strategy team has a few responsibilities, as listed in the following section.

評価中の責任Responsibilities during assessment

概要レベルの説明責任に加え、個人またはグループが直接責任を負う必要があるアクションがあります。In addition to the high-level accountability, there are actions that an individual or group needs to be directly responsible for. 責任者の割り当てを必要とするいくつかのアクティビティを次に示します。The following are a few activities that require assignments to responsible parties:

  • ビジネスの優先順位。Business priority. チームが、このワークロードを移行するための目的を、ビジネスに対する意図された影響も含めて理解します。The team understands the purpose for migrating this workload, including any intended impact to the business.
    • このアクティビティの最終的な責任は、クラウド導入チームの指示の下で、クラウド戦略チームのメンバーが引き受ける必要があります。A member of the cloud strategy team should carry final responsibility for this activity, under the direction of the cloud adoption team.
  • 利害関係者の調整。Stakeholder alignment. チームが、内部の利害関係者の期待と優先順位を調整して、移行の成功基準を識別します。The team aligns expectations and priorities with internal stakeholders, identifying success criteria for the migration. 移行後はどのようになれば成功なのか?What does success look like post-migration?
  • 合理化の調整。Refined rationalization. 合理化に関する初期の想定を評価します。Evaluate the initial assumptions regarding rationalization. この特定のワークロードの移行に、別の合理化アプローチを取る必要はあるか?Should a different rationalization approach be used to migrate this specific workload?
  • 最新化の決定。Modernization decisions. 合理化の決定にかかわらず、PaaS ベースのソリューションを使用するためにワークロードのさまざまな資産を最新のものにする必要があるか?Regardless of the rationalization decision, should various assets in the workload be modernized to use PaaS-based solutions?
  • コスト。Cost. ターゲット アーキテクチャのコストが見積もられ、全体の予算が調整されます。The cost of the target architecture has been estimated, and the overall budget has been adjusted.
  • 移行のサポート。Migration support. チームが、パートナーまたは Microsoft サポートに関する意思決定を含めて、移行の技術的な作業の完了方法を決定します。The team has decided how the technical work of the migration will be completed, including decisions regarding partner or Microsoft support.
  • 評価。Evaluation. ワークロードの互換性と依存関係が評価されます。The workload is evaluated for compatibility and dependencies.
    • このアクティビティは、候補になっているワークロードのアーキテクチャと動作に精通している該当分野の専門家に割り当てる必要があります。This activity should be assigned to a subject matter expert who is familiar with the architecture and operations of the candidate workload.
  • 設計。Architect. チームが、移行されたワークロードの最終的なアーキテクチャの状態に同意します。The team has agreed on the final state architecture for the migrated workload.
  • 移行ツール。Migration tooling. 近代化とアーキテクチャのアプローチによっては、移行の自動化にさまざまな移行ツールを使用できます。Depending on modernization and architecture approaches, a variety of migration tools could be used to automate the migration. 提案されているアーキテクチャの場合、この移行で最適な移行ツールが使用されるか?Based on the proposed architecture, will this migration use the best migration tools?
  • バックログの調整。Backlog alignment. クラウド導入チームが要件をレビューし、候補になっているワークロードの移行にコミットします。The cloud adoption team reviews requirements and commits to the migration of the candidate workload. コミット後に、それに基づいて、リリース バックログとイテレーション バックログが更新されます。After commitment, the release backlog and iteration backlog are to be updated accordingly.
  • 作業分解構造またはワークバック スケジュール。Work breakdown structure or work-back schedule. チームが、計画、実装、およびレビュー プロセスで目標とする完了期限を識別する主要なマイルスローンのスケジュールを確立します。The team establishes a schedule of major milestones identifying goals for when planning, implementation, and review processes are completed.
  • 最終承認。Final approval. 必要な承認者が計画をレビューし、資産を移行するためのアプローチを承認します。Any necessary approvers have reviewed the plan and have signed off on the approach to migrate the asset.
    • プロセスの後半で予想外の問題を避けるために、ビジネスの 1 人以上の代表者が承認プロセスに関与している必要があります。To avoid surprises later in the process, at least one representative of the business should be involved in the approval process.

注意事項

この責任とアクションの完全な一覧は、責任のレベルが異なる複数のロールが関与し、詳細な承認プロセスを必要とする、大規模で複雑な移行をサポートできます。This full list of responsibilities and actions can support large and complex migrations involving multiple roles with varying levels of responsibility, and requiring a detailed approval process. 小規模の単純な移行作業では、ここで説明されているロールとアクションのすべてが必要なわけではない可能性があります。Smaller and simpler migration efforts may not require all of roles and actions described here. これらのアクティビティのどれに価値があり、どれが不必要であるかを判断するために、クラウド導入チームとクラウド戦略チームは、最初のワークロードの移行の一環としてこの完全なプロセスを使用する必要があります。To determine which of these activities add value and which are unnecessary, your cloud adoption team and the cloud strategy team should use this complete process as part of your first workload migration. ワークロードを検証してテストした後、チームは、このプロセスを評価して、今後も使用するアクションを選択できます。After the workload has been verified and tested, the team can evaluate this process and choose which actions to use moving forward.

次のステップNext steps

評価プロセスをおおまかに理解したうえで、ワークロードを分類することで、このプロセスを開始できます。With a general understanding of the assessment process, you're ready to begin the process by classifying workloads.