# VMware migration
AWS Transform can help you migrate your VMware environment to Amazon EC2 by using generative AI. This document provides an overview of AWS Transform and of the workflow of the migration process.
## Capabilities and key features
AWS Transform offers the following capabilities and key features for migrating your VMware environment to AWS.
+ Three discovery options:
+ Assisted discovery of your VMware environment by using collectors from AWS Application Discovery Service.
+ Use the open-source [Export for vCenter](https://github.com/awslabs/export-for-vcenter) tool.
+ Importing independently collected discovery data.
+ AI-driven conversion of your source VMware network configuration to an Amazon VPC network architecture.
+ AI-driven generation of migration plans, including application grouping and suggested migration waves.
+ Rehosting your servers to run natively on Amazon EC2.
AWS Transform supports migrating Windows and Linux servers of supported operating systems. For the full list of supported operating systems, see [Supported operating systems](https://docs.aws.amazon.com/mgn/latest/ug/Supported-Operating-Systems.html) in the *AWS Application Migration Service User Guide*.
## AWS Transform VMware migration architecture
This diagram displays an overview of AWS Transform VMware migration architecture.
![\[AWS Transform VMware architecture\]](http://docs.aws.amazon.com/transform/latest/userguide/images/atx-vm-architecture_v2.png)
## Limitations
AWS Transform has the following limitations:
+ If you stop a running migration job, and then ask the agent to restart it, the job will start again from the beginning and you will lose any progress you have made in the job. However, artifacts created in the job before restarting it will still be available.
+ You can specify one target AWS Region per VMware migration job. To migrate applications to different target Regions, create multiple VMware migration jobs.
+ NSX imports are only supported for end-to-end migration jobs.
**Important**
AWS Transform generates network configurations and migration strategies based on your environment assessment. Review these configurations with stakeholders to ensure that they meet your organization's security, compliance, and business requirements. While AWS Transform provides automated configuration recommendations, you are responsible for validating and adjusting the settings to match your security and compliance needs before proceeding with migration.
# VMware migration jobs
To use AWS Transform for VMware migrations, you first need a workspace, which is a logical container in which you can create one or more transformation jobs. The sections in this topic describe how to get a workspace and how to create and start a VMware migration job in it.
## Getting a workspace
For information about getting a workspace, see [Getting started](https://docs.aws.amazon.com/transform/latest/userguide/getting-started.html).
The workspace that you use determines the AWS Region where you can create transformation jobs. That is the AWS Region where your jobs will reside. Your discovery data and AWS Transform recommendations will also reside in this AWS Region. To create workspaces and jobs in a different AWS Region, ask your administrator to create a different workspace for you. For information about supported AWS Regions, see [Supported Regions for AWS Transform](regions.md).
Even though the AWS Region where you can create jobs and store discovery data and recommendations is determined by your AWS Transform administrator, you can specify a different AWS Region as your target for the migration. In other words, you can run discovery and receive AWS Transform recommendations in one AWS Region, but then create your target environment in a different AWS Region. If you do that, you will be transferring your data across AWS Regions. For more information, see [Connect target AWS accounts](transform-vmware-connect-target-account.md).
## Job types
AWS Transform offers the following types of VMware migration jobs that you can choose from depending on your migration needs. In addition to these preset options, you can dynamically add or remove any step from your job at any time to customize your migration workflow.
### End-to-end migration
1. Perform discovery
1. Build migration plan
1. Connect target accounts
1. Build landing zone
1. Migrate network
1. Migrate servers
### Discovery and migration planning
1. Perform discovery
1. Build migration plan
### Network migration
1. Connect target accounts
1. Migrate network
### Landing zone
1. Connect target accounts
1. Build landing zone
### Landing zone, network, and server migration
1. Connect target accounts
1. Build landing zone
1. Migrate network
1. Migrate servers
### Migration planning and server migration
Includes discovery, wave plan, and rehost.
1. Perform discovery
1. Build migration plan
1. Connect target accounts
1. Migrate servers
## Creating and starting a job
The first step of a migration project is to create an AWS Transform job. For VMware migration projects, you can choose different job types, depending on your goals. The following procedure describes how to create and start a new VMware migration job of any type. For information about the different job types, see [Job types](#vmware-job-types).
**To create and start a new VMware migration job**
1. On your workspace landing page, choose **Create a job**.
1. Choose the VMware migration option, and then specify the type of VMware migration job that you want to create. For information about the steps included in each of the four VMware migration job types, see [Job types](#vmware-job-types).
1. After you answer all the chat questions, choose **Create job**.
# Discover source data
To discover and collect on-premises data, you can use the [AWS Transform discovery tool](discovery-tool.md), AWSMigration Evaluator collector, or upload exports from RVTools and ModelizeIT, as well as AWSMigration Portfolio Assessment (MPA) format exports generated by tools like Cloudamize. AWS Transform can process AWS Transform discovery tool exports as CSV and JSON files in a ZIP file format, RVTools exports as either an Excel file or a ZIP file containing CSV files, and ModelizeIT CSV exports in a ZIP file. For each data source AWS Transform accepts the primary server file individually. However, supplementary files such as connections will only be processed when they are included in a ZIP file with the server files or in an Excel file with the server sheet.
We recommend that you upload the most detailed data available and review your export files before uploading to ensure data completeness and accuracy. Verify that all required files are included in your upload, and confirm that the data reflects your current environment state. This preliminary review helps minimize the need for re-uploads and ensures that AWS Transform can more accurately capture your on-premises environment and better support migration planning, including application grouping and wave planning. You can also incrementally add data as you obtain better data.
AWS Transform automatically detects file format and structure, parses and extracts structured entity records, removes duplicates across multiple files, validates data quality and reports issues, and then prepares a summary ready for downstream migration planning.
After you share and confirm your on-premises data, you can review discovery data by expanding **Discover on-premises** data in the **Job Plan** and choosing **Inventory readiness summary**. You can also ask questions about the data you uploaded to verify that AWS Transform correctly ingested everything or to identify and correct any mistakes in the data processing. For example, you can ask about operating system and versions. If you need to correct mistakes you can re-upload your inventory data from the discovery tool you used, and AWS Transform will automatically process, de-duplicate, and merge the updated records. You can also remove a previously uploaded file if you no longer want to use that inventory data.
# Build migration plan
The Migration planning job step within AWS Transform for VMware is a collaborative chat-based experience for planning large migrations. AWS Transform agents apply AWS Prescriptive Guidance to guide customers from analysis of on-premises data to finalized migration wave plans.
After the Discover on-premises data job completes successfully, AWS Transform uses the discovery data to group applications into migration waves. AWS Transform guides you through steps to analyze and scope your servers, group them into applications, generate move groups, and build migration waves. When analyzing your on-premises environment, you can ask questions to better understand how AWS Transform analyzed your installed software, for example, server dependencies and network architecture.
AWS Transform supports scope adjustments within application groups and waves. You can re-upload discovery data at any time, and AWS Transform will automatically process, de-duplicate, and merge new records with existing data. When changes are detected—such as newly discovered dependencies or infrastructure additions, AWS Transform will flag impacted dependency groups and provide recommendations for wave plan adjustments. Migration planning can also make use of unstructured text data to enrich the planning process.
There are four migration planning stages:
+ In **Scope and analyze**, you can review your discovery data, ask questions about your software and network environment and determine the resources in scope for migration.
+ In **Group apps**, you can provide a combination of business and technical rules regarding, for example, hostname analysis, network dependencies, and business rules, so that migration planning can group your infrastructure into applications. If you already have an inventory of your applications, migration planning can use that instead.
+ In **Generate move groups**, you can give migration planning your technical and business requirements so that it can determine which applications must be moved together. Technical dependencies include databases, message queues, or other resources shared between multiple apps. Business and operational dependencies include business criticality, RPO and RTO, data center location, and application owners.
+ Finally, in **Build waves**, you can give migration planning context about your timelines and priorities so it can build a wave plan that you can migrate. You can select move groups for inclusion in a wave based on factors such as priority score, move group size, user counts, and application complexity.
**Migration Planning Terminology:**
+ *Migration waves* are logical groups that are migrated together. Migration waves are comprised of one or more move groups.
+ A *move group* is a set of co-dependent applications that must be moved together. They may have technical dependencies such as a shared database or they have business dependencies such as supporting a shared business function.
+ A *dependency* is a relationship between systems. There are several types of dependencies including:
+ Critical or hard dependencies, where systems cannot operate without the dependency. Common examples of this are applications that depend on databases, other applications, or services.
+ Soft dependencies, which are not critical for the operation of the system. Common examples of this include latency insensitive dependencies that can be migrated independently.
+ Non-technical dependencies include business, organizational, operational and compliance dependencies. These are dependencies related to your organization and its priorities. Examples of this include shared business function and organizational ownership.
## Workflow
Migration planning is an interactive and iterative workflow. You can go back and make changes to previous steps at any time. A typical migration planning workflow is:
1. Migration planning starts by summarizing the discovery data that is available. Review the available data and return to the discovery step at any time to provide additional data.
1. Within the scoping and analysis step you can ask questions about your on-premises environment to validate the data you have collected. Example questions include:
1. List my servers by operating system
1. Summarize my on-premises network topology
1. List the most common technologies running in my environment.
1. While analyzing your environment, if you identify servers that should not be in scope for migration you can tell AWS Transform to exclude those resources. Examples of this include:
1. Remove all servers which have *legacy* in their hostname
1. Remove all servers in the 10.0.2.0/24 subnet
1. Remove all servers running versions of Windows older than 2022
1. Once you have sufficiently explored your environment and determined your migration scope you can tell AWS Transform to move to the next migration planning step.
1. The next step is application grouping. If you already have your servers mapped to applications, you can tell AWS Transform to use that mapping and skip this step. If you do not have your applications pre-defined you can provide the technical and business logic that defines your applications. AWS Transform will guide you through the application grouping process and suggest the data points that you can provide to effectively group your servers together into applications. The more information you can provide about your on-premises applications, the more effectively AWS Transform can group your servers into apps. Once you have provided sufficient information, you can then instruct AWS Transform to perform application grouping.
1. Once application grouping has been performed, review the application groups. You can instruct AWS Transform to make any necessary changes, for example:
1. Move server example-server to application-5
1. Rename application-5 "HR App Test Environment"
1. Remove all Linux servers from IIS Dev Farm
1. Once your apps are grouped, instruct AWS Transform to move to the next step
1. The next step is move grouping. In the move grouping step you identify applications that must be moved together. Provide context around your technical and non-technical dependencies. AWS Transform will guide you through the process and suggest data points that you can provide to group your apps together. There are several considerations to make at this stage including:
1. What should be the target size of move group?
1. Do you want to combine environments, for example dev, test, and prod, for each app, or split them?
1. How do you want to consider network dependencies? Are all dependencies critical or can some dependencies be considered soft dependencies and be split across move groups?
1. Once you have provided your rules for move grouping, instruct AWS Transform to execute your move grouping strategy. You can then review and modify your move groups. Once you have reviewed your move groups you can instruct AWS Transform to move to the final migration planning step.
1. Wave planning is the final step within migration planning. In this step, you group your move groups into migration waves and prioritize those waves. Within the wave planning step, AWS Transform will guide you through providing the business prioritization required to group your move groups into waves and then prioritize those waves. Considerations within wave planning include:
1. The business criticality of each of your move groups
1. The migration timelines and the timelines for each move group
1. The risks associated with each move group
1. The number of servers to migrate per wave
1. Once you have provided sufficient guidance on how to group into waves, instruct AWS Transform to execute the wave planning. You can then review your waves and modify them.
1. Once you have finalized your wave plan, you can complete migration planning and move to execution. You can return to migration planning at any time to refine and iterate on your plan.
# Connect target AWS accounts
Configure your target AWS account connector for network migration, landing zone build, and server migration. This involves three steps: selecting your migration type, providing your MAP agreement details (if applicable), and setting up the connector. These settings apply across all migration stages — network migration, landing zone, and server rehost.
## Step 1: Migration type selection
Choose whether you are performing a single-account or multi-account migration:
+ **Single-account migration** – All workloads migrate to one target AWS account. The connector target account and the target account are the same.
+ **Multi-account migration** – Workloads migrate to different target accounts. The connector must be connected to the organization management account or a Delegated Administrator (DA) account registered for both Application Migration Service and CloudFormation StackSets.
## Step 2: MAP agreement
If your migration is part of the **AWS Migration Acceleration Program (MAP 2.0)**, provide your MPE ID — a 10-character code using uppercase letters and digits (for example, ABCDE12345). AWS Transform applies the MAP tag to all resources created across network migration, landing zone, and server rehost stages. The tag format is:
+ **Key:** `map-migrated` **Value:** `migMPE_ID`
MAP tags are required to receive MAP credit. For more information, see [AWS Migration Acceleration Program](https://aws.amazon.com/migration-acceleration-program/).
## Step 3: Connector configuration
The target account connector connects your migration job to the AWS environment where your workloads will reside after migration. It's important to ensure that the target AWS account is properly set up with the necessary permissions, quotas, and configurations to support your migrated infrastructure.
When you approve the connector request, you grant AWS Transform permissions to:
+ Manage Amazon S3 bucket operations (read/write) for VMware migration, along with access to AWS Migration Hub and AWS Application Migration Service (Application Migration Service). This includes permissions for the following items, all restricted to resources within the target account and tagged with `CreatedBy:AWSTransform` or `CreatedFor:AWSTransform`:
+ Managing migration waves
+ Network configurations (Amazon EC2, VPC, Transit Gateway, Direct Connect, Load Balancers, Network Firewall)
+ CloudFormation stack deployments
+ Automated agent installations via Systems Manager
+ Migrate your on-premises workloads to the target AWS account and Region by using the information stored in the discovery Region.
+ Provision and manage landing zone infrastructure in the target AWS account and Region. This includes permissions for the following items, restricted to resources tagged with `CreatedBy:AWSTransform` where applicable:
+ Amazon S3 bucket operations (create, read, write, delete) for buckets starting with `transform-vmware-landing-zone-`
+ CloudFormation stack deployments and change set management for landing zone stacks
+ AWS Control Tower operations (managing landing zones, enabling baselines and controls)
+ AWS Organizations management (creating and managing organizational units, creating accounts, and moving accounts)
+ Service control policy (SCP) management via AWS Control Tower
+ AWS Service Catalog provisioning artifact management
**Note**
AWS Transform may update connector types when introducing features requiring permission changes. The current version for the target account connector type is 2.0. New connectors are always created with the latest version.
Before setting up the connector, understand the account roles involved in your migration:
| Account | Description |
| --- | --- |
| AWS Transform account | Any member account in your AWS Organization where you set up AWS Transform. This is where your AWS Transform workspace runs. It does not need to be the management account. |
| Connector target account | The account your AWS Transform connector is configured to. This depends on your migration type: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/transform/latest/userguide/transform-vmware-connect-target-account.html) |
| Target account | The AWS account where your workloads are migrated to. In a single-account migration, this is the same as the connector target account. In a multi-account migration, these are the individual member accounts receiving the migrated workloads. |
### Using a delegated administrator account
For multi-account migrations, AWS recommends using a Delegated Administrator (DA) account rather than the organization management account directly. The DA account must be registered as delegated administrator for both Application Migration Service and CloudFormation StackSets in your AWS Organization.
The key difference between the two options is:
+ **Management account** – Can enable trusted access for Application Migration Service and CloudFormation StackSets across the organization. AWS Transform calls CloudFormation StackSets APIs with `CallAs: SELF`.
+ **Delegated Administrator account** – Cannot enable trusted access directly (that must be done from the management account), but can manage Application Migration Service source servers, launch instances, and deploy CloudFormation StackSets across member accounts. AWS Transform calls CloudFormation StackSets APIs with `CallAs: DELEGATED_ADMIN`.
For more information, see [Delegated administrator for Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/mgn-delegated-admin.html) in the *Application Migration Service User Guide*.
### IAM roles created during setup
During migration setup, AWS Transform deploys a CloudFormation StackSet (`MGNMultiAccountRoles`) to create the required IAM roles across your target accounts. The following roles are created:
+ `AWSApplicationMigrationConnectorManagementRole` – Used during agent installation to access source server credentials from AWS Secrets Manager.
+ `AWSApplicationMigrationConnectorSharingRole_` – Contains permissions for agent installation across accounts.
+ Application Migration Service service roles – Created automatically during Application Migration Service initialization in each target account. These include roles for replication and launch operations, and cross-account roles for multi-account migrations.
**Note**
IAM roles are created idempotently — if they already exist in the account, the setup process skips creating them again.
### How to set up the connector
**Important**
AWS Transform creates an Amazon S3 bucket on your behalf in the target AWS account. This bucket won't have `SecureTransport` enabled by default. If you want the bucket policy to include secure transport, you must update the policy yourself. For more information, see [Security best practices for Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).
**To use an existing target account connector**
1. In the **Job Plan** pane, expand **Choose target account**, and then choose **Create or select connectors**.
1. In the **Collaboration** tab, select an existing connector and then choose **Use connector**. If a connector is grayed out, its version isn't compatible with the job type you selected.
**Important**
If you specify a connector with a target AWS Region that is different from the AWS Transform Region, AWS Transform will transfer your data across AWS Regions.
1. Choose **Continue**.
**To create a new connector**
1. In the **Job Plan** pane, expand **Connect target account**, and then choose **Create or select connectors**.
1. Specify the AWS account and AWS Region for your target, and then choose **Next**.
**Important**
If the target AWS Region differs from the discovery AWS Region, AWS Transform will transfer your data across AWS Regions.
1. Choose whether to use Amazon S3 managed keys for encryption. If you specify your own KMS key, you can use the default key policy or a less permissive one. For information about creating a KMS key, see [Create a KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) in the *AWS Key Management Service Developer Guide*.
AWS Transform uses the `kms:DescribeKey` permission to verify the key exists, and `kms:GenerateDataKey` and `kms:Decrypt` to encrypt and decrypt job data in the Amazon S3 bucket. For more information, see [Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-key.html).
1. Choose **Continue**.
1. Copy the verification link, share it with an administrator of the target AWS account, and ask them to approve the connection request.
1. After the administrator approves the request, select the newly created connector from the list and choose **Use connector**.
1. Choose **Send to AWS Transform**.
If you plan to modify the AWS Application Migration Service template to enable post-launch actions, add the following permission to the target connector role. You can find the role name in the **Collaboration** tab after the connector is created. For information about adding permissions to a role, see [Update permissions for a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) in the *IAM User Guide*.
```
{
"Sid": "MGNPostLaunchActions",
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": "arn:aws:iam::target-account-ID:role/service-role/AWSApplicationMigrationLaunchInstanceWithSsmRole"
}
```
### Supported target regions
When you create the connector, specify a target AWS Region. You can use any of the following AWS Regions:
+ US East (N. Virginia)
+ US East (Ohio)
+ US West (Oregon)
+ Asia Pacific (Mumbai)
+ Asia Pacific (Tokyo)
+ Asia Pacific (Seoul)
+ Asia Pacific (Osaka)
+ Asia Pacific (Singapore)
+ Asia Pacific (Sydney)
+ Canada (Central)
+ Europe (Frankfurt)
+ Europe (Ireland)
+ Europe (London)
+ Europe (Paris)
+ Europe (Stockholm)
+ South America (São Paulo)
**Important**
If you specify a target AWS Region that is different from the AWS Transform AWS Region, that means AWS Transform will be transferring your data across AWS Regions.
**Note**
If you plan to run a job that includes server migration only (without network migration execution), additional commercial AWS Regions are available as target Regions: US West (N. California), Europe (Milan), Asia Pacific (Jakarta), Europe (Zurich), Europe (Spain), Asia Pacific (Hyderabad), Asia Pacific (Melbourne), Middle East (Tel Aviv), Asia Pacific (Bangkok), Asia Pacific (Kuala Lumpur), Middle East (Bahrain), Africa (Cape Town), Asia Pacific (Hong Kong), and Middle East (UAE). To use one of these additional Regions before Q3 2026, contact your AWS account team to have your account allow-listed. Starting in Q3 2026, these Regions will be generally available without the need for an allow-list request.
# Build landing zone
AWS Transform guides you through designing and deploying an AWS landing zone as part of your migration project. A landing zone is a multi-account AWS environment that serves as the foundation for your workloads with organizational boundaries, governance controls, and account structure in place before any workloads arrive. AWS Transform analyzes your migration inventory and business requirements to recommend an Organizational Unit (OU) and account structure, apply recommended Service Control Policies (SCPs), and generate and/or deploy the infrastructure as code (IaC).
The landing zone agent walks you through two phases:
+ **Foundation setup** – Establish the core landing zone structure: AWS Control Tower, foundational OUs, and core accounts.
+ **Workload account design** – Design and create workload OUs and accounts based on your migration waves, business units, and environment separation requirements.
AWS Transform supports both greenfield environments (no existing landing zone) and brownfield environments (existing OUs and accounts already deployed). In brownfield scenarios, AWS Transform detects your existing organization structure and recommends only the changes needed to fill gaps against AWS best practices.
## Connector setup
The landing zone agent requires a target AWS account connector to provision resources in your organization management account. The connector has permissions to:
+ Set up [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ Create [organizational units and accounts](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_ous.html)
+ Configure [Service Control Policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
When you approve the connector request, you grant AWS Transform permissions to:
+ Provision and manage landing zone infrastructure in the target AWS account and Region. This includes permissions for the following items, restricted to resources tagged with `CreatedBy:AWSTransform` and by `ATWorkspace:{workspace-id}` where applicable:
+ S3 bucket operations (create, read, write, delete) for buckets starting with `transform-vmware-landing-zone-`
+ CloudFormation stack deployments and change set management for landing zone stacks
+ AWS Control Tower operations (managing landing zones, enabling baselines and controls)
+ [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html) management (creating and managing organizational units, creating accounts, and moving accounts)
+ Service control policy (SCP) management via AWS Control Tower
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) provisioning artifact management
When you create the connector, you specify a target AWS Region. This Region should be the same as your home Control Tower Region. For more information about Control Tower Regions, see [How AWS Regions work with AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/region-how.html).
At the start of the landing zone setup, AWS Transform retrieves your connector configuration and presents the AWS Organization management account ID and target Region for confirmation. For more information, see [AWS Transform Connectors](transform-user-connectors.md).
**Important**
**IAM Identity Center Region dependency** – AWS Transform requires AWS IAM Identity Center (IAM Identity Center), which means your connector Region must match both your AWS Control Tower home Region *and* your IAM Identity Center Region. If IAM Identity Center is already configured in your organization, AWS Control Tower initialization will fail if the connector targets a different Region. For more information, see [Considerations for IAM Identity Center customers](https://docs.aws.amazon.com/controltower/latest/userguide/getting-started-prereqs.html) in the AWS Control Tower User Guide.
## Foundation setup
The foundation setup phase establishes the core landing zone infrastructure using [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html). When AWS Control Tower sets up a landing zone, it automatically provisions a set of managed resources in your management account that form the governance foundation for your entire AWS Organization:
+ **Root** – The top-level parent that contains all OUs in your landing zone.
+ **Security OU** – Created automatically by Control Tower. Contains two shared accounts: the **Log Archive account** (centralized, immutable logging for all AWS API activity and resource changes across your organization) and the **Audit account** (read-only access to all accounts for security and compliance review). These accounts cannot be renamed or replaced after initial setup.
+ **Mandatory controls (guardrails)** – Control Tower automatically applies preventive and detective controls across your organization to enforce baseline governance policies. These cannot be disabled.
+ **IAM Identity Center directory** – Control Tower creates a cloud-native directory with preconfigured groups and single sign-on access for your landing zone users. For more information, see [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html).
Control Tower uses [CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) to deploy and manage these resources consistently across all accounts and Regions in your organization. You must not modify or delete Control Tower managed resources outside of supported methods, as doing so can cause your landing zone to enter an unknown state.
### Account email convention
AWS requires a unique email address for each account. These emails receive important notifications for the account. AWS Transform uses plus addressing to generate unique account emails from a single mailbox.
Format: `prefix+account-name@domain`
You provide a prefix (for example, `aws-admin`) and a domain (for example, `acme.com`), and AWS Transform derives all account emails automatically. For example:
+ Audit account: `aws-admin+audit@acme.com`
+ Log Archive account: `aws-admin+log-archive@acme.com`
+ Sandbox account: `aws-admin+sandbox@acme.com`
In brownfield scenarios, AWS Transform inspects existing account emails to infer the plus-addressing convention already in use and offers to continue with the same pattern.
### Recommended foundation structure
Based on AWS best practices, AWS Transform recommends the following foundation OU structure. You can customize it before creation.
| OU | Purpose | Accounts |
| --- | --- | --- |
| Security | Centralized audit logging and monitoring. Isolating these services in dedicated accounts is designed to help keep your audit trail separate from workload teams. | Audit, Log Archive |
| Infrastructure | Shared networking (Transit Gateway, VPN), DNS, and common services. Centralizing these is recommended to help reduce duplication and give your network team a single place to manage connectivity. | None (created empty) |
| Sandbox | Developer experimentation with spending limits and restricted access. Recommended to give developers a space to experiment without risking production resources. | Sandbox |
| Workloads | Contains Production, Non-Production, and optionally Regulated sub-OUs. Workload accounts are designed in the next phase based on your migration requirements. | None (created empty) |
**Note**
The Security OU with [Audit and Log Archive accounts](https://docs.aws.amazon.com/controltower/latest/userguide/accounts.html) is created as part of the Control Tower foundation setup. The Infrastructure, Sandbox, and Workloads OUs are created separately after you confirm the structure.
In brownfield scenarios, AWS Transform compares your existing foundation against this recommended structure and reports only the gaps. For example: "Your foundation has Security and Infrastructure OUs but no Sandbox OU."
### Service Control Policies (SCPs)
SCPs are [organization-level permission guardrails](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) that set the maximum permissions for all accounts in your AWS Organization. They don't grant access — instead, they define boundaries that no one in the account can exceed, even account administrators.
As part of the Control Tower deployment, baseline guardrails are applied automatically. AWS Transform also recommends additional SCPs designed to help strengthen your organization's posture. These are based on AWS best practices for a minimum viable landing zone.
SCPs can be applied to the Infrastructure, Sandbox, and Workloads OUs. The Security OU is managed by Control Tower and cannot be targeted by SCPs through this tool.
**Important**
The Security OU is a foundation OU managed by Control Tower. You cannot add accounts, SCPs, or any resources to it through the landing zone agent.
In brownfield scenarios, AWS Transform checks which SCPs are already applied and only recommends ones that would fill gaps.
### Foundation deployment
After the foundation design is complete, you choose how to deploy:
+ **Deploy for me** – AWS Transform deploys the foundation OUs, accounts, and SCPs to your AWS Organization.
+ **I'll deploy on my own** – AWS Transform generates Infrastructure as Code (IaC) artifacts for download in your preferred format (see [IaC formats](#transform-vmware-lz-iac-formats)).
+ **Design workload accounts first** – Skip deployment and continue to the workload account design phase. You can deploy everything together later.
#### Control Tower initialization
If AWS Transform detects that AWS Control Tower is not yet initialized in your organization, it provides the user with a link to the AWS Transform console page. Generating the operation in the link will create a CloudFormation stack to bootstrap Control Tower. The process will create this stack in the CloudFormation console for your target Region. After the stack creation is complete, AWS Transform continues with the deployment.
## Workload account design
In the workload account design phase, AWS Transform designs the OU and account structure for your application workloads based on your migration inventory, business requirements, and environment separation preferences.
### Migration planning context
AWS Transform retrieves data from your migration planning phase, including wave plans, server-to-application mappings, and shared context. If migration planning data is available, AWS Transform displays a summary and asks you to confirm or adjust it. If no migration planning data is available, AWS Transform asks discovery questions directly.
### Discovery
AWS Transform asks questions to understand your workload requirements. You can skip any question. Topics include:
+ Number of business units or teams using AWS
+ Industry and any applicable frameworks (HIPAA, PCI-DSS, SOC2, FedRAMP)
+ Whether workloads handle sensitive data (PII, PHI, financial)
+ Environment separation preferences (dev/test/staging/prod as separate accounts or shared)
+ Workload isolation requirements
+ Business applications and their purposes
+ Server grouping into applications
+ Cost tracking and allocation needs (by business unit, project, environment)
+ Expected growth in the next 12–24 months
+ Account strategy preference (single app per account, grouped, or environment-based)
### Proposed workload structure
Based on your answers and migration planning data, AWS Transform proposes an OU and account structure under the Workloads OU. The proposal includes the reasoning behind each design decision.
AWS Transform follows these design principles:
+ All servers in a migration wave go to the same account — waves cannot be split across accounts. This is a rehost limitation during wave execution.
+ If you request isolated environments, AWS Transform creates Workloads/Production and Workloads/Non-Production sub-OUs.
+ If applicable frameworks are identified, AWS Transform creates Workloads/Regulated and Workloads/Standard sub-OUs.
+ If multiple business units require different governance, AWS Transform creates business-unit-specific OUs under Workloads.
+ Critical or sensitive-data applications get a single app per account. In this case, you might be asked to iterate on your wave plan.
+ Tightly coupled applications with shared dependencies are grouped in one account.
Each proposed account includes: name, purpose, target OU, and business unit. AWS Transform shows the naming convention being used (for example, `--`).
You can review and modify the proposed structure before AWS Transform applies the changes. After applying, you can iterate — making additional changes until you are satisfied.
### Workload SCP configuration
After the workload structure is created, AWS Transform presents available SCPs and asks if you want to apply any to your workload OUs. You select which SCPs to apply and to which OUs. AWS Transform applies the SCPs and shows the updated organization tree with an SCP summary table.
### Workload deployment
After the workload design is complete, you choose how to deploy:
+ **Deploy for me** – AWS Transform deploys the workload OUs, accounts, and SCPs to your AWS Organization.
+ **I'll deploy on my own** – AWS Transform generates IaC artifacts for download in your preferred format (see [IaC formats](#transform-vmware-lz-iac-formats)).
## IaC formats
When you choose self-deployment, AWS Transform generates Infrastructure as Code artifacts in the following formats:
+ **[AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/v2/guide/home.html)** – TypeScript project for programmatic infrastructure deployment.
+ **Landing Zone Accelerator (LZA)** – Configuration YAML files based on LZA Universal Configuration version 1.1.0. These enterprise-ready templates work with the Landing Zone Accelerator on AWS to establish multi-account AWS environments. The generated files include pre-configured settings for governance, organization structure, and networking that align with AWS best practices. To learn more, see [LZA Universal Configuration](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/universal-configuration.html).
**Note**
When deploying via the Landing Zone Accelerator (LZA) pipeline, your AWS Transform account and LZA installation must be in the same AWS Organization. Deployment will fail if there is a mismatch between the Organizations IDs used in AWS Transform and LZA. To learn how to set up your LZA installation using Organizations, see [AWS Organizations based installation](https://docs.aws.amazon.com/solutions/latest/landing-zone-accelerator-on-aws/aws-organizations-based-installation.html).
After you select a format, AWS Transform generates the artifacts and makes them available for download.
To verify the downloaded file hasn't been corrupted or tampered with, generate and download a checksum, then compare it to a locally generated hash using:
```
openssl dgst -sha256 -binary | base64
```
## Deployment approvals process
Landing zone deployment requests require explicit approval before execution. When you submit a deployment request, it automatically routes to authorized approvers through the AWS Transform Approvals tab.
Approvers review CloudFormation templates and landing zone configurations. Only users with the Admin role in AWS Transform can approve deployment requests. Each submission triggers a new review cycle, and deployments proceed only after receiving confirmation.
If an approver denies your request, contact them directly to discuss necessary modifications. The system tracks all approval decisions for audit purposes and maintains deployment history.
## Tag landing zone resources
AWS Transform automatically tags all generated resources with `"CreatedBy": "AWSTransform"` along with definition and execution IDs for tracking purposes.
### Automatic tags
All landing zone resources receive the following tags:
+ `CreatedBy` – AWSTransform
+ `ATWorkspace` – Workspace identifier
**Note**
If your migration is part of the AWS Migration Acceleration Program (MAP 2.0), you can include the required MAP tag: Key: `map-migrated` Value: `migMPE_ID` (where MPE\$1ID is your Migration Portfolio Evaluation identifier). The MAP tag is requested during the connector setup phase. AWS Transform applies these tags during landing zone deployment.
## Reversing changes
Only non-deployed elements can be removed. Once an OU or account is deployed, it cannot be removed through the landing zone agent.
When removing elements, order matters — you must remove children before parents:
1. Remove accounts first (by email).
1. Remove SCPs from OUs.
1. Remove child OUs — an OU cannot be removed if it still has accounts or nested OUs.
## Related resources
+ [Connect target AWS accounts](transform-vmware-connect-target-account.md)
+ [Migrate network](transform-vmware-migrate-network.md)
+ [AWS Control Tower User Guide](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Organizations User Guide](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)
+ [AWS IAM Identity Center User Guide](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)
+ [CloudFormation User Guide](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Landing Zone Accelerator on AWS](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
+ [AWS Prescriptive Guidance: Building Landing Zones](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-landing-zone/welcome.html)
# Migrate network
AWS Transform migrates VMware networks to AWS by translating your source environment configuration into AWS-equivalent network resources. AWS Transform analyzes your source network data and creates VPCs, subnets, security groups, NAT gateways, transit gateways, elastic IPs, routes, and route tables as needed. You can review and modify the generated network configuration before deployment. For deployment, you can either have AWS Transform deploy the configuration for you and analyze deployed network connectivity, or choose self-deployment—in which case AWS Transform generates Infrastructure as Code (IaC) in your preferred format: AWS Cloud Development Kit (AWS CDK) (AWS CDK), Landing Zone Accelerator (LZA), or HashiCorp Terraform.
To migrate your network, follow these steps:
1. Upload your source network file
1. Upload additional configuration files (optional, for RVTools environments)
1. Select a network topology
1. Select security groups mapping strategy
1. Review the generated VPC configurations
1. Generate a network diagram (optional)
1. Configure resource tagging
1. Deploy your network
**Note**
For multi-account deployments, you must configure cross-account IAM roles and trusted access for AWS Organizations before starting the network migration. For more information, see [Step 1: Migration type selection](transform-vmware-connect-target-account.md#transform-vmware-cta-migration-type).
## Step 1: Source network mapping
The network mapping process requires uploading a configuration file from your source environment. The tool you choose depends on your source network type:
+ **Software Defined Networks (SDN):** Import/Export for VMware NSX network virtualization or Cisco ACI config for Cisco Application Centric Infrastructure.
+ **VMware vSphere networks:** [RVTools](https://www.dell.com/en-us/shop/vmware/sl/rvtools). When using RVTools files, AWS Transform generates Amazon VPC configurations only. Security group configurations require additional input from firewall or software-defined network files. See [Additional configuration files](#transform-vmware-firewall-and-sdn-config-files) for more details.
+ **Networks based on firewall configuration data:** Export files from Palo Alto Networks Firewall, Fortinet FortiGate Firewall, or Cisco ACI. For supported versions and extraction instructions, see [Configuration file extraction](#transform-vmware-config-file-extraction).
+ **Hybrid networks running both VMware and non-VMware workloads:** Application mapping tools - modelizeIT.
+ **Other file types:** If your configuration file is not one of the supported formats listed above, AWS Transform will attempt to automatically convert it to a format that can be processed by the service. This conversion can take up to two hours depending on the file size and complexity.
**Warning**
The official RVTools site is [https://www.dell.com/en-us/shop/vmware/sl/rvtools](https://www.dell.com/en-us/shop/vmware/sl/rvtools), which is the site that this guide links to in steps that mention RVTools. Beware of the scam site (rvtools)(dot)(org).
AWS Transform creates VPCs from all source network segments, with each detected segment becoming its own distinct VPC. Network segmentation varies by source type:
+ **vNetwork:** AWS Transform groups VMs by vSwitch and VLAN. VLANs can appear under multiple vSwitches (except VLAN 0).
+ **NSX networks:** AWS Transform segments the network based on Tier-1 routers, grouping the routers and collecting their segments.
## Step 2: Additional configuration files
For RVTools source environments, you can optionally upload additional configuration files to enable security group generation. Without additional configuration, no security groups will be generated for RVTools-based migrations.
AWS Transform supports the following additional configuration file types. Only one configuration file from one platform can be uploaded.
+ Cisco Application Centric Infrastructure (ACI): Network policy configurations
+ Palo Alto Networks: Firewall security policies
+ Fortinet FortiGate: Firewall security policies
When you upload a firewall or Cisco ACI file, AWS Transform generates network infrastructure and security groups. When you upload an RVTools file alone, AWS Transform generates network infrastructure only.
For supported versions and extraction instructions, see [Configuration file extraction](#transform-vmware-config-file-extraction).
## Step 3: Network topologies
During the network definition step, you select a network topology. You can choose the **Isolated VPCs** topology or the **Hub and Spoke** topology.
### Isolated VPCs
These are independent network environments that operate as separate units within AWS. VPCs maintain complete network isolation, with no built-in communication pathways between them. This separation provides the highest level of network boundary protection. You can connect the VPCs through specific networking configurations if needed.
**Important**
No internet connectivity is configured for Isolated VPCs. You must set up internet gateways, NAT gateways, and routing manually.
### Hub and Spoke
In this model, an [AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) acts as the central hub that connects multiple workload VPCs (the spokes). AWS Transform creates a spoke VPC for each detected source network segment and connects them through the Transit Gateway.
**Appliance VPCs**
AWS Transform creates three specialized appliance VPCs to manage traffic flow and security:
+ **Inspection VPC:** Hosts your firewall appliance for traffic inspection. All cross-VPC traffic is routed through this VPC. You must deploy a firewall (such as [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html) or a third-party appliance) in this VPC. The Transit Gateway attachment uses [appliance mode](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-appliance-scenario.html) to ensure symmetric routing.
+ **Inbound VPC:** Handles traffic from the public internet (north-south inbound). Includes an [internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) and public subnets across multiple Availability Zones.
+ **Outbound VPC:** Handles traffic to the public internet (north-south outbound). Includes an internet gateway, [NAT gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) with [elastic IP addresses](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html) in each Availability Zone for high availability, and private subnets for the Transit Gateway attachment.
**Transit Gateway route tables**
AWS Transform creates two Transit Gateway route tables to steer traffic through the Inspection VPC:
+ **Uninspected:** Associated with spoke VPCs, Inbound VPC, and Outbound VPC. Routes all traffic (0.0.0.0/0) to the Inspection VPC attachment. This is the default association route table — new VPC attachments are automatically associated with it.
+ **Inspected:** Associated with the Inspection VPC. Contains propagated routes from all spoke VPCs, so inspected traffic can reach its destination. This is the default propagation route table — spoke VPC routes are automatically propagated to it.
**Traffic flow**
All cross-VPC traffic follows this path:
1. Traffic from a spoke VPC is sent to the Transit Gateway (default route 0.0.0.0/0).
1. The Uninspected route table routes the traffic to the Inspection VPC.
1. Your firewall in the Inspection VPC inspects the traffic and forwards it back to the Transit Gateway.
1. The Inspected route table routes the traffic to the destination spoke VPC using propagated routes.
For outbound internet traffic, the Inspected route table routes traffic to the Outbound VPC, where NAT gateways translate private IP addresses before forwarding to the internet gateway. The Outbound VPC public route table includes specific routes for each spoke VPC CIDR back to the Transit Gateway, enabling return traffic to reach the correct spoke VPC. Inbound internet traffic enters through the Inbound VPC's internet gateway and follows the same inspection path to reach spoke VPCs.
For multi-account deployments, AWS Transform shares the Transit Gateway across accounts using [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html).
**Note**
By default, cross-VPC traffic passes through the Inspection VPC without inspection. To inspect traffic, deploy a firewall appliance (such as [AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/getting-started.html)) in the Inspection VPC.
To deploy a firewall, create additional subnets in the Inspection VPC for the firewall endpoints. AWS Transform creates subnets for the Transit Gateway attachment only. Route traffic from the TGW attachment subnets to the firewall endpoints, and from the firewall subnets back to the Transit Gateway. For more information, see [Creating a firewall with a Transit Gateway](https://docs.aws.amazon.com/network-firewall/latest/developerguide/create-tgw-firewall.html).
If you want fine-grained control over the communication between the VPCs, choose the **Isolated VPCs** option and modify the generated network to create the specific communication paths you require.
## Step 4: Security group mapping
AWS Transform creates security groups based on your source environment configurations. AWS Transform converts security policies, security policy rules, gateway policies, and gateway policy rules to security groups.
**Important**
AWS Transform makes a best effort to create security groups that match your source environment. Review and modify the generated security groups to ensure that they meet your company's needs and security policies.
Choose one of the following security group mapping strategies:
+ **MAP:** Translate rules from your source environment. Only static IP assignment is supported with this strategy (see IP migration approaches below).
+ **SKIP:** Do not translate rules from your source environment. No security groups are generated. Both static and dynamic (DHCP) IP assignment are available. For RVTools source environments without additional configuration files, AWS Transform automatically uses SKIP.
**IP migration approaches**
The system offers two key network configuration choices for your migration:
**Network range selection:**
+ **Keep Existing Ranges (IP Address Ranges Retention):** Keep original IP address ranges during migration. Ideal for lift-and-shift scenarios with legacy applications that have hard-coded IP dependencies or existing firewall rules.
+ **Update to new IP ranges (CIDR update):** You can modify each VPC CIDR range during migration, and AWS Transform automatically propagates changes to subnets, route tables, and security groups.
**IP addresses assignment:**
+ **Fixed IP addresses (Static):** The system assigns static IPs based on the CIDR. This is best for applications requiring predictable network behavior, DNS management, or IP-based access control. IPs persist across instance restarts using Elastic Network Interfaces (ENIs).
+ **Dynamic IP assignment (AWS DHCP):** Automatically assign IPs from subnet pools at instance launch. Optimal for cloud-native applications and auto-scaling workloads. Reduces operational overhead but requires applications to use DNS or service discovery.
You can combine either range selection with either IP assignment method.
**Note**
IP addresses assignment strategy is set at the wave level. You can assign different strategies to specific servers by customizing the wave file. For example, if you chose a static IP address approach for the wave but want to assign a dynamic approach to a specific server, you would use `[RESET_VALUE]` as described in [Editing your configuration](https://docs.aws.amazon.com/mgn/latest/ug/configuration-editing.html) in the *Application Migration Service user guide*.
## Step 5: Review VPC configurations
After AWS Transform generates Amazon VPC configurations, it displays the generated VPC networks. You can either use the current configuration or modify VPC CIDRs.
For single-account deployments, you can edit VPC CIDRs only. For multi-account deployments, you can also edit the target accounts for each VPC network.
**Note**
You cannot modify the prefix length (the value after the "/").
To modify VPC CIDRs:
1. In the Generated VPCs list, provide your modified CIDRs.
1. Choose **Submit** to apply the changes and rerun the mapping process.
1. Review the results, then either continue or repeat the modification steps.
## Step 6: Network diagram
After reviewing the generated VPC configurations, you can optionally generate a network diagram to visualize your network topology. AWS Transform supports the following diagram formats:
+ **Mermaid code (.mmd):** A text-based diagram definition file that can be rendered using Mermaid-compatible tools.
+ **Image (.png):** A rendered image of your network topology.
## Step 7: Configure resource tagging
AWS Transform tags your network resources for launch and replication, and supports custom tags and AWS Migration Acceleration Program (MAP) tags.
### Automatic tags for launch and replication
AWS Transform automatically tags migrated network resources (VPCs, subnets, security groups, and route tables) with the following tags:
+ **Key:** `CreatedBy` **Value:** `AWSApplicationMigrationService`
+ **Key:** `ATWorkspace` **Value:** `workspace-id`
These tags allow using the VPC and subnet for launching test and cutover instances in AWS.
**Note**
Network migration generates network segments without internet connectivity, so migrated VPCs and subnets are not suitable as staging areas for replication by default.
To also use the VPC and subnet as a staging area (replication), manually add the following tags:
+ **Key:** `CreatedFor` **Value:** `AWSTransform`
+ **Key:** `ATWorkspace` **Value:** `workspace-id`
You can also apply these tags to any existing AWS network resource to make it available for replication.
Find your workspace ID in the AWS Transform web app URL: https://... /workspace/*workspace-id*/job/job-id
### Custom tags
In addition to the tags applied automatically by AWS Transform, you can add custom tags to organize, track costs, and manage compliance for your migrated network resources. You can apply custom tags at two levels:
+ **Job-level tags:** Apply to all resources created by this job, including all VPCs, subnets, security groups, and route tables.
+ **VPC-level tags:** Apply to a specific VPC and automatically cascade to all its associated resources (subnets, security groups, route tables).
**Note**
Maximum 40 tags per request. Each tag requires a key and value. AWS tagging conventions apply.
AWS Transform applies these tags when generating the Infrastructure as Code templates.
### AWS Migration Acceleration Program
If your migration is part of the **AWS Migration Acceleration Program (MAP 2.0)**, AWS Transform applies a MAP tag to your resources. If you provided your MPE ID earlier in the migration process, the tag is applied automatically. Otherwise, after you finish reviewing the generated VPC configurations, AWS Transform asks whether you have a MAP agreement and prompts you to provide your MPE ID — a 10-character code using uppercase letters and digits (for example, ABCDE12345). The applied tag uses the format:
+ **Key:** `map-migrated` **Value:** `migMPE_ID`
## Step 8: Deploy network
After tagging, select your deployment strategy:
+ **AWS Transform-managed deployment:** AWS Transform uses CloudFormation templates to deploy your network and runs Reachability Analyzer to check connectivity between subnets across multiple VPCs and within the same VPC.
**Note**
Network deployment requests require explicit approval before execution. See the deployment approvals process below.
+ **Self-deployment:** AWS Transform generates Infrastructure as Code (IaC) templates. CloudFormation templates are generated by default. You can also select additional output formats:
+ AWS CDK: TypeScript project for programmatic infrastructure deployment
+ HashiCorp Terraform: HCL templates for managing network resources
+ Landing Zone Accelerator (LZA): A network-config.yaml file for LZA network configuration
**Note**
When deploying via the Landing Zone Accelerator (LZA) pipeline, ensure that your AWS Transform account and LZA installation are in the same AWS Organization. Deployment will fail if there is a mismatch between the Organizations IDs.
For self-deployment, use the link provided to download a zip file containing the generated templates. The zip folder includes a README.md file that explains how to use the generated templates.
To verify the downloaded file hasn't been corrupted or tampered with, generate and download a checksum, then compare it to a locally generated hash using `openssl dgst -sha256 -binary | base64` command.
**Deployment approvals process**
Network deployment requests require explicit approval before execution. When you submit a deployment request, it automatically routes to authorized approvers through the AWS Transform Approvals tab. Approvers validate both CloudFormation templates and network configurations to ensure compliance with security standards and architectural requirements. Each submission triggers a new review cycle, and deployments proceed only after receiving confirmation. If an approver denies your request, contact them directly to discuss necessary modifications. The system tracks all approval decisions for audit purposes and maintains deployment history.
## Network deletion
After deployment, you can delete the deployed network resources. Deletion is available immediately after deployment completes. If you modify the deployed network resources after deployment, AWS Transform cannot delete them.
+ **AWS Transform-managed deployments:** AWS Transform removes all CloudFormation stacks that were created during deployment. This action requires approval through the AWS Transform Approvals tab.
+ **Self-deployments:** You must manually delete the deployed resources through the AWS Management Console or AWS CLI.
## Configuration file extraction
You can use Cisco ACI, Palo Alto Networks, and Fortinet FortiGate configuration files as standalone source files to generate network infrastructure and security groups, or as complementary files alongside an RVTools upload to add security group generation. The extraction process is the same in both cases.
To extract configuration files from your firewall and network environments, follow these procedures. Consult vendor documentation for the latest information.
### Fortinet FortiGate
+ Firmware: v7.0 and up
+ Requirements: `super_admin` or `super_admin_readonly` privileges on global level
+ Steps:
1. Connect to the firewall via SSH or built-in CLI client
1. Run: `show | grep ""` (`| grep ""` disables pagination)
1. Save all output to a file starting from the `show` command
### Palo Alto Networks
+ Firmware: 10.1 and up
+ Requirements: superadmin role
+ Steps: Connect via SSH, run the commands below, and save the outputs:
```
set cli pager off
set cli config-output-format set
configure
show # Save as palo-conf.txt
show predefined # Save as palo-default.txt
```
### Cisco ACI
+ Firmware: 6.0 and up
+ Requirements: Admin role with all privileges; SCP/SFTP/FTP destination configured
+ Steps:
1. Connect to APIC controller via browser
1. Go to Admin >> Config Rollbacks
1. In "Take a snapshot" select remote location and choose "Create a snapshot now"
1. After receiving "Transfer successful" message, connect to the remote location server and retrieve the latest snapshot file (.gz file)
# Migrate servers
AWS Transform uses AWS Application Migration Service (Application Migration Service) to rehost your VMware servers to Amazon EC2. The migrate servers workflow guides you through setting up each migration wave, validating your server inventory, deploying replication agents, monitoring data replication, testing migrated instances, and performing final cutover. To read more about it, see [What is AWS Application Migration Service?](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) in the *Application Migration Service User Guide*.
Server migration is organized by waves. Each wave represents a group of servers that are migrated together. For each wave, you complete the following phases:
1. Prerequisites and migration execution defaults
1. Step 1: Set up migration wave
1. Step 2: Validate and confirm inventory
1. Step 3: Deploy replication agents
1. Step 4: Data replication
1. Step 5: Testing
1. Step 6: Cutover
## Prerequisites
Before starting rehost migration, ensure you have the following in place:
+ **Target accounts for migration** – The AWS account IDs where you need your servers to be migrated. You can use AWS Transform landing zone or any other tools to set up your infrastructure.
+ **Network infrastructure in place** – VPCs, subnets, and security groups deployed and configured. You can use AWS Transform network migration or any other tools to set up your network infrastructure.
+ **Inventory file** – Prepared with server details, wave assignments, target account information, and Amazon EC2 instance type preferences. You can use AWS Transform migration planning to generate this file.
**Important**
Before starting rehost migration, verify that you have the networking resources and infrastructure in place to host your servers. You can use AWS Transform landing zone and network migration capabilities or any other tools for that.
## Step 0: Migration execution defaults
Before starting wave execution, you configure default settings that apply to all your target accounts. These defaults define how your Amazon EC2 instances are launched and how the general migration is configured. You can override these defaults at the wave level during wave setup.
### Amazon EC2 recommendation preferences
AWS Transform provides Amazon EC2 instance type recommendations based on the utilization specification of your source VMs. You can configure your Amazon EC2 recommendation preferences to control how instance types are selected for your migrated servers.
For more information about generating Amazon EC2 recommendations, see [Generating Amazon EC2 recommendations in AWS Migration Hub](https://docs.aws.amazon.com/migrationhub/latest/ug/generating-ec2-recommendations.html).
**Note**
You can modify the suggested Amazon EC2 instance types to include recommendations from the [Migration Evaluator](https://aws.amazon.com/migration-evaluator/), [AWS Optimization and Licensing Assessment (OLA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/aws-ola.html), or an AWS Transform assessment job.
### Default launch settings
To change default launch settings, go to the Application Migration Service console and apply the changes you want. For more information, see [Launch settings](https://docs.aws.amazon.com/mgn/latest/ug/launch-settings.html) in the *Application Migration Service User Guide*.
## Step 1: Set up migration wave
In this phase, AWS Transform prepares the migration wave by configuring the target account, verifying service permissions, setting up resource tags, adding networking data to your inventory, and configuring replication and launch settings.
### Migration mode and account configuration
AWS Transform supports two migration modes:
+ **Single-account migration** – All servers in the wave migrate to the same target account configured in your connector.
+ **Multi-account migration** – Servers migrate to different target accounts specified in your inventory file. For multi-account migrations, your inventory file must include an `mgn:account-id` column with the target account ID for each server.
AWS Transform confirms the target account configuration and verifies that Application Migration Service is initialized in each target account. If Application Migration Service is not yet initialized, AWS Transform provides instructions to complete the initialization. During initialization, Application Migration Service creates the required IAM service roles for replication and launch operations, including cross-account roles for multi-account migrations. To learn more about this requirement, see [Initializing Application Migration Service with the console](https://docs.aws.amazon.com/mgn/latest/ug/mgn-initialize-console.html) or [Initializing Application Migration Service with the API](https://docs.aws.amazon.com/mgn/latest/ug/mgn-initialize-api.html) in the *Application Migration Service User Guide*.
### Resource tagging verification
After service permissions are confirmed, AWS Transform verifies that all required resources are properly tagged. The following tags are required:
+ Source servers must have tags `CreatedBy: AWSTransform` and `ATWorkspace: `.
+ VPCs and subnets must have tags `CreatedFor: AWSTransform` and `ATWorkspace: `. VPCs and subnets created by the AWS Transform network migration agent are automatically tagged with these tags.
If any resources are missing required tags, AWS Transform provides a link to the tagging page where you can apply the missing tags before continuing.
**Note**
VPCs and subnets created by the AWS Transform network migration agent are automatically tagged. If you set up your own VPCs and subnets, you must manually apply the following tags so that they appear in AWS Transform's list of available subnets:
Key: `CreatedFor` Value: `AWSTransform`
Key: `ATWorkspace` Value: *workspace-id* (find your workspace ID in the AWS Transform web app URL: `https://.../workspace/workspace-id/job/job-id`)
### Add networking data to inventory
AWS Transform adds networking information from your network migration to the inventory file. This step maps your servers to the appropriate target subnets and security groups based on the network configuration generated during the migrate network phase.
### Replication and launch settings
To change replication and launch settings, go to the Application Migration Service console and apply the changes you want. For more information, see [Replication settings](https://docs.aws.amazon.com/mgn/latest/ug/replication-settings.html) and [Launch settings](https://docs.aws.amazon.com/mgn/latest/ug/launch-settings.html) in the *Application Migration Service User Guide*.
### IP assignment strategy
You choose how IP addresses are assigned to your migrated servers:
+ **Static IP** – The source server's IP address is maintained. If CIDR transformation is required, AWS Transform automatically converts the IP address to match the new CIDR.
+ **Dynamic IP (DHCP)** – Each server is assigned a new IP address from the subnet's IP pool.
**Important**
When security groups are created by AWS Transform, you cannot use DHCP for server migrations. Security groups use CIDR configurations, and enabling DHCP could compromise your network's security posture.
## Step 2: Validate and confirm inventory
Before loading your server data into Application Migration Service, AWS Transform prepares the inventory file for your review. You can download the file in CSV or XLSX format, review the server configurations, and make changes if needed.
The inventory file includes details such as server names, operating systems, Amazon EC2 instance type recommendations, target subnets, security groups, IP assignments, and licensing options. Required fields include:
+ **Server information** – Server name, VMID, and source specifications.
+ **Wave assignment** – Migration wave grouping.
+ **Application grouping** – Logical application associations.
+ **Target configuration** – Target account, Region, and Amazon EC2 instance type.
+ **Network configuration** – Target subnet and security groups.
You can modify the file to adjust Amazon EC2 configurations, change operating system licensing options (BYOL or License Included), and update tenancy settings.
After you review the inventory, you can either accept it as shown or upload a modified version. AWS Transform then loads the data into Application Migration Service, which creates source server records for each server in the wave.
**Note**
Do not remove columns or change column headers in the inventory file. AWS Transform requires the original file structure to process the data correctly.
**Note**
AWS Transform allows one import to a given target AWS account and target AWS Region at a time. If you work on more than one wave simultaneously, or if there is more than one migration job running with the same target account, you must wait for an import to finish before you can perform another import in a different wave or job.
You can control the operating system licensing options (BYOL or License Included) and tenancy by specifying the configuration in the inventory file columns `mgn:launch:placement:operating-system-licensing` and `mgn:launch:placement:tenancy`. For more information, see [Import parameters](https://docs.aws.amazon.com/mgn/latest/ug/import-main.html#import-parameters) in the *Application Migration Service User Guide*.
## Step 3: Deploy replication agents
To begin replicating data from your source servers to AWS, you install the AWS Replication Agent on each source server. AWS Transform offers three installation methods:
+ **Organization tools** – Use your organization's existing deployment tools (such as SCCM, Ansible, or Chef) to install agents across your servers. AWS Transform provides the installation commands with additional parameters for silent installation, including `--no-prompt`, `--aws-access-key-id`, `--aws-secret-access-key`, and `--aws-session-token`.
+ **MGN connector** – Use an Application Migration Service connector to automate agent installation. The connector connects to source machines over SSH (Linux) or WinRM (Windows) and installs the replication agent automatically. Once configured, a connector can be reused across multiple waves and different target AWS accounts. For more information about the Application Migration Service connector, see [Set up the MGN Connector](https://docs.aws.amazon.com/mgn/latest/ug/mgn-connector-setup-instructions.html) in the *Application Migration Service User Guide*.
**Note**
Before using the MGN connector with AWS Transform, you must tag the connector's managed instance in AWS Systems Manager Fleet Manager with the following tags:
Key: `CreatedFor` Value: `AWSTransform`
Key: `ATWorkspace` Value: *workspace-id*
To tag the managed instance, open the AWS Systems Manager console, navigate to **Fleet Manager** under **Node Tools**, choose the managed instance of your MGN connector, and apply the tags above. Find your workspace ID in the AWS Transform web app URL: `https://.../workspace/workspace-id/job/job-id`.
+ **Manual installation** – Install the agent directly on each source server. This method requires direct access to each server but gives you full control over the installation process.
### AWS Transform MGN connector setup
The AWS Transform MGN connector automates the deployment of replication agents to your source servers. The connector is a lightweight client deployed on a dedicated Linux machine in your on-premises environment. It connects to source servers over SSH (Linux) or WinRM (Windows) to install and configure replication agents, eliminating the need to manually coordinate across multiple AWS services.
#### How the connector works
The connector operates through the following components:
+ **Connector client** – Deployed on a dedicated Linux machine in your environment.
+ **SSM Agent** – Installed on the same machine to enable secure communication with AWS.
+ **SSM Hybrid Activation** – Links the connector machine to AWS Systems Manager for secure command execution.
+ **Credentials management** – Retrieves source server credentials from AWS Secrets Manager.
When you deploy agents, AWS Transform sends an SSM document to the connector machine. The connector then retrieves source server credentials from AWS Secrets Manager, establishes a connection to each source server, validates that the source server meets prerequisites, installs and configures the replication agent, and verifies successful installation.
#### Connector machine requirements
| Requirement | Details |
| --- | --- |
| Operating system | Supported Linux operating system. For the full list, see [MGN connector prerequisites](https://docs.aws.amazon.com/mgn/latest/ug/mgn-connector-prerequisites.html) in the Application Migration Service User Guide. |
| Network access | Must reach all source servers (Linux over SSH, Windows over WinRM) |
| Internet connectivity | Outbound HTTPS (443) to AWS endpoints (Systems Manager, Secrets Manager, Application Migration Service) |
| Disk space | Minimum 200 MB free |
| Permissions | Root or sudo access |
**Note**
The connector must be installed on a Linux machine, but it can deploy agents to both Linux and Windows source servers.
#### Setup process
For information about how to set up the Application Migration Service connector, see [Set up the MGN Connector](https://docs.aws.amazon.com/mgn/latest/ug/mgn-connector-setup-instructions.html) in the *Application Migration Service User Guide*.
#### Agent deployment
Once credentials are configured and verified, AWS Transform deploys replication agents to your source servers. You can deploy to all servers in the current wave or select specific servers.
The deployment process for each server:
1. AWS Transform sends deployment commands to the connector via SSM.
1. The connector retrieves credentials from AWS Secrets Manager.
1. The connector connects to the source server using the configured credentials.
1. The connector validates that the source server meets all prerequisites required to run the replication agent.
1. The connector installs and configures the replication agent.
1. The connector verifies successful installation and connectivity.
You can monitor deployment progress in real-time with per-server status tracking, including the current installation step, elapsed time, and estimated time remaining. If any servers fail, AWS Transform displays the failure reason and offers retry options per server. Successfully deployed servers can proceed independently while failed servers are retried.
#### Connector reuse and lifecycle
When deploying agents for subsequent waves, you can reuse an existing connector or create a new one. AWS Transform lists all connectors configured in your account, showing the connector name, status (Active or Expired), attached server count, and Hybrid Activation expiry date.
+ **Active connector** – The Hybrid Activation is still valid. AWS Transform verifies IAM roles for the new wave and proceeds to credential configuration. No new Hybrid Activation is needed.
+ **Expired connector** – The SSM Hybrid Activation has expired. Expired activations cannot be renewed. You must select a different connector or create a new one.
SSM Hybrid Activations expire after 30 days. The activation is required only for installing the connector on the Linux machine. Once the connector is installed, you can continue to use it to install replication agents on source servers even after the activation expires. If you need to install the connector on a new machine after the activation has expired, you need to create a new connector through the setup process.
### Manual agent installation
For manual installation, you first generate AWS credentials (temporary or permanent) and then install the agent on each source server.
**Credential options:**
+ **Temporary credentials (recommended)** – Create an IAM role with the `AWSApplicationMigrationAgentInstallationPolicy` managed policy, then use `aws sts assume-role` to generate temporary credentials. To read more about it, see [Agent installation permissions](https://docs.aws.amazon.com/mgn/latest/ug/agent-installation-permissions.html) in the *Application Migration Service User Guide*.
+ **Permanent credentials** – Create an IAM user with the `AWSApplicationMigrationAgentInstallationPolicy` managed policy and generate an access key.
**Installation steps:**
For Linux servers, download and run the installer:
```
wget -O ./aws-replication-installer-init \
https://aws-application-migration-service-region.s3.region.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init --region region --user-provided-id server-identifier
```
For Windows servers, download and run the appropriate installer using PowerShell as Administrator:
```
Invoke-WebRequest -Uri "https://aws-application-migration-service-region.s3.region.amazonaws.com/latest/windows/AwsReplicationWindowsInstaller.exe" `
-OutFile "C:\AwsReplicationWindowsInstaller.exe"
C:\AwsReplicationWindowsInstaller.exe --region region --user-provided-id server-identifier
```
**Important**
The `--user-provided-id` parameter is required. Replace *server-identifier* with the exact value from the `mgn:server:user-provided-id` column in your inventory file. This identifier links the physical server to its Application Migration Service source server record.
For more information about agent installation, see [Linux agent](https://docs.aws.amazon.com/mgn/latest/ug/linux-agent.html) and [Windows agent](https://docs.aws.amazon.com/mgn/latest/ug/windows-agent.html) in the *Application Migration Service User Guide*.
After installation, AWS Transform verifies that all agents are successfully connected by checking that servers show a replication state of `INITIATING` or `INITIAL_SYNC`.
**Note**
AWS Transform does not support Application Migration Service agentless replication. For information about agentless replication, see [Agentless replication overview](https://docs.aws.amazon.com/mgn/latest/ug/installing-vcenter-overview-mgn.html) in the *Application Migration Service User Guide*.
**Note**
You must install the replication agent on all servers in a wave. Disconnect and archive servers on which you don't install the replication agent. You can use the `disconnect-from-service` command to disconnect servers, and the `mark-as-archived` command to archive disconnected servers. The archiving command only works for source servers whose lifecycle state is `DISCONNECTED`.
For quotas related to replication, see [Application Migration Service service quota limits](https://docs.aws.amazon.com/mgn/latest/ug/MGN-service-limits.html) in the *Application Migration Service User Guide*.
## Step 4: Data replication
After the replication agents are installed, data replication begins automatically. AWS Transform uses continuous block-level replication to synchronize data from source servers to AWS.
The replication process consists of two phases:
+ **Initial sync** – A complete copy of the source server data to AWS. Data is stored as EBS snapshots in the target account. Duration depends on data volume and network bandwidth.
+ **Continuous replication** – Ongoing synchronization of changed blocks with minimal impact on source server performance. Maintains an up-to-date copy in AWS.
Replication servers are temporary Amazon EC2 instances deployed in the staging area subnet. They receive replicated data from source servers and are automatically managed by Application Migration Service. To read more about it, see [Replication server settings](https://docs.aws.amazon.com/mgn/latest/ug/replication-server-settings.html) in the *Application Migration Service User Guide*.
AWS Transform monitors the replication progress and provides status updates, including replication status, replication lag (the time difference between source and replicated data), and bandwidth usage.
During replication, each server progresses through the following states:
+ **Not ready** – The server is undergoing the initial sync process and is not yet ready for testing.
+ **Ready for testing** – The server has been successfully added and data replication has started. Test or cutover instances can now be launched.
Once all servers in the wave have progressed beyond the `NOT_READY` state, the data replication phase is complete and you can proceed to testing.
You can control replication for individual servers or the entire wave at any time:
+ **Pause replication** – Temporarily pause replication for specific servers or the entire wave.
+ **Resume replication** – Resume previously paused replication.
+ **Stop replication** – Permanently stop replication. Stopped replication can be restarted, but it begins from the initial sync.
## Step 5: Testing
After data replication is complete, you can launch test instances to validate your migrated servers before performing the final cutover. To read more about it, see [Launch test instances](https://docs.aws.amazon.com/mgn/latest/ug/launch-test-instances.html) in the *Application Migration Service User Guide*. AWS Transform supports two testing options:
+ **Full wave testing** – Launch test instances for all servers in the wave.
+ **Selective testing** – Launch test instances for specific servers that you select by providing their user-provided IDs from the inventory file.
AWS Transform launches Amazon EC2 instances from the replicated data and provides the instance IDs so you can connect to and validate the test instances. After testing, you can:
+ Proceed to cutover if testing is successful.
+ Launch new test instances to retest.
+ Terminate test instances and address any issues before retesting.
## Step 5b: Mark applications as ready for cutover
After testing is complete and you are satisfied with the results, mark your applications as ready for cutover. AWS Transform reviews the replication status of each application and resolves any replication alerts before allowing you to proceed. Only applications with a clean replication status can be marked for cutover.
## Step 6: Cutover
Cutover is the final migration step where your production workloads are moved to AWS. To read more about it, see [Launch cutover instances](https://docs.aws.amazon.com/mgn/latest/ug/launch-cutover-instances.html) in the *Application Migration Service User Guide*. Similar to testing, AWS Transform supports full wave cutover or selective cutover for specific servers.
During cutover, AWS Transform launches Amazon EC2 instances from the latest replicated data and provides the instance IDs for each server. After verifying the cutover instances, you finalize the cutover, which stops the ongoing source machine replication.
The cutover process includes the following steps:
1. **Launch cutover instances** – AWS Transform launches Amazon EC2 instances for the selected servers. You can choose full wave cutover or selective cutover.
1. **Verify cutover instances** – Connect to the launched instances and verify they are functioning correctly.
1. **Finalize cutover** – Confirm the cutover to stop source machine replication. You can finalize all servers in the wave or select specific servers. Finalization stops replication agents from sending data, removes replication agents from source servers, and locks the server lifecycle state. This action cannot be easily undone. To read more about it, see [Finalize cutover](https://docs.aws.amazon.com/mgn/latest/ug/finalize-cutover.html) in the *Application Migration Service User Guide*.
1. **Archive source servers (optional)** – After finalization, you can mark source servers as archived to free up source server quota in your account.
**Important**
Finalizing cutover stops the ongoing source machine replication. Make sure you have verified your cutover instances before finalizing.
**Note**
Downtime occurs between source shutdown and cutover instance availability. Plan your cutover window accordingly.
## Server lifecycle states
During migration, each server progresses through the following lifecycle states. To read more about it, see [Source server lifecycle](https://docs.aws.amazon.com/mgn/latest/ug/source-server-lifecycle.html) in the *Application Migration Service User Guide*.
+ **Not ready** – The server is undergoing the initial sync process and is not yet ready for testing.
+ **Ready for testing** – Data replication has started and test or cutover instances can be launched.
+ **Test in progress** – A test instance is currently being launched.
+ **Ready for cutover** – The server has been tested and is ready for cutover.
+ **Cutover in progress** – A cutover instance is currently being launched.
+ **Cutover complete** – The server has been cutover. All data has been migrated to the AWS cutover instance.
+ **Disconnected** – The server has been disconnected from Application Migration Service.
You can ask AWS Transform about the status of your servers at any time during the migration. AWS Transform provides an interactive wave status table that displays all relevant server information including migration lifecycle, replication status, and recommended next steps. You can also ask in natural language, for example:
+ What is the status of my servers?
+ What's the status of my wave?
+ What's the status of the step that I'm currently in?
During wave migration, you can ask AWS Transform to update or change the status of individual servers. For example, if 9 out of 10 servers in your wave passed the test phase but one failed, you can allow AWS Transform to continue moving the 9 servers into the next phase while re-running the test on the failed server.
## Deployment approvals
Some migration operations require explicit approval before execution. When an operation requires approval, AWS Transform routes the request to authorized approvers through the Approvals tab. Only users with the Admin role in AWS Transform can approve deployment requests. Deployments proceed only after receiving confirmation.