翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ワークロードの移行：標準プロセス
<a name="mp-migrate-stack-process"></a>

**注記**  
このプロセスには 2 つの関係者が必要なため、このセクションでは、AMS クラウド移行パートナー (移行パートナー) とアプリケーション所有者 (ユーザー) の各タスクについて説明します。

![\[Workflow diagram showing migration steps from on-premises to AWS EC2 and AMS.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/appguide/images/migration-ams-wigs.png)


1. 移行パートナー、セットアップ:

   1. 移行パートナーは、インスタンスを移行する目的で、IAM ロールのサービスリクエストを AMS に送信します。サービスリクエストの送信の詳細については、[「サービスリクエストの例](https://docs.aws.amazon.com/managedservices/latest/userguide/serv-req-mgmt-examples.html)」を参照してください。

   1. 移行パートナーは[管理者アクセスリクエスト](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-access-admin-request-col.html)を送信します。AMS オペレーションチームは、リクエストされた IAM ロールを通じて移行パートナーにアカウントへのアクセスを提供します。

1. 移行パートナー、個々のワークロードの移行:

   1. 移行パートナーは、IAM AWS インスタンスプロファイル ( アカウントに存在する必要があります) を使用して、ネイティブ Amazon EC2 またはその他の移行ツールを通じて、非インスタンスを AMS `customer-mc-ec2-instance-profile` アカウントのサブネットに移行します。

   1. 移行パートナーは、移行パートナー移行インスタンスからのデプロイ \$1 取り込み \$1 スタック \$1 CT の作成 (ct-257p9zjk14ija) を使用して RFC を送信します。この RFC の作成と送信の詳細については、「」を参照してください[ワークロード取り込みスタック: の作成](ams-workload-ingest.md#ex-workload-ingest-col)。

      RFC の実行出力は、インスタンス ID、IP アドレス、AMI ID を返します。

      移行パートナーは、アカウントで作成されたワークロードのインスタンス ID を提供します。

1. 移行にアクセスして検証します。

   1. 移行パートナーから提供された実行出力 (AMI ID、インスタンス ID、IP アドレス) を使用して、アクセス RFC を送信し、新しく作成した AMS スタックにログインして、アプリケーションが正しく動作していることを確認します。詳細については、[「インスタンスアクセスのリクエスト](https://docs.aws.amazon.com/managedservices/latest/ctref/ex-access-admin-request-col.html)」を参照してください。

   1. 問題がなければ、起動したインスタンスを 1 層スタックとして引き続き使用したり、AMI を使用して Auto Scaling グループを含む追加のスタックを作成したりできます。

   1. 移行に満足できない場合は、サービスリクエストを提出し、スタックと RFC IDs を参照します。AMS はお客様と協力して問題に対処します。

 

CloudEndure ランディングゾーンのワークロード取り込みプロセスを次に示します。