# Migrating IIS applications to Elastic Beanstalk
Migrating IIS applications

AWS Elastic Beanstalk provides a streamlined migration path for your Windows applications running on Internet Information Services (IIS). The migration capability described in this chapter significantly reduces the time and complexity that’s typically associated with cloud migrations, helping you to maintain application functionality and configuration integrity during the transition to AWS.

**The **eb migrate** operation**  
Use the **eb migrate** command in the Elastic Beanstalk Command Line Interface (EB CLI), to automatically discover, package, and deploy your IIS applications to the AWS Cloud. The process maintains application functionality and preserves your configurations, including bindings, application pools, and authentication settings.

The following steps summarize the process that the `eb migrate` operation performs to transition your application to the AWS Cloud:

1. Discover IIS sites and their configurations.

1. Package application content and configuration.

1. Create Elastic Beanstalk environment and application.

1. Deploy the application with preserved settings.

**Workflow and location execution options**  
The **eb migrate** command provides options for flexible migration workflows and execution locations. By default, run the command on the target server that contains the application you want to migrate to Elastic Beanstalk. If you can't run commands directly on the application server, use the `remote` option to run the command from a bastion host that connects to the target server containing your application and configurations. To complete the migration in two steps, you can also generate the migration package without deploying it using the `archive-only` option and then deploy it later at your convenience using the `archive` option.

For reference information about the **eb migrate** command, see [**eb migrate**](eb3-migrate.md).

**Topics**  
The following topics provide detailed information about migrating IIS applications to Elastic Beanstalk:
+ [Prerequisites](dotnet-migrating-applications-prerequisites.md) - Understand the required software, access, and permissions to migrate your Windows applications to AWS Elastic Beanstalk environments.
+ [Migration glossary](dotnet-migrating-applications-glossary.md) - Understand how IIS components map to Elastic Beanstalk resources
+ [Understanding IIS to Elastic Beanstalk migration mapping](dotnet-migrating-applications-mapping.md) - Understand how IIS components map to Elastic Beanstalk resources
+ [Performing basic IIS migrations](dotnet-migrating-applications-basic-migration.md) - Learn how to perform basic migrations
+ [Advanced migration scenarios](dotnet-migrating-applications-advanced-scenarios.md) - Handle complex migration scenarios
+ [Security configurations and IAM roles](dotnet-migrating-applications-security.md) - Configure security settings during migration
+ [Network configuration and port settings](dotnet-migrating-applications-network.md) - Manage network and port configurations
+ [Troubleshooting and diagnostics](dotnet-migrating-applications-troubleshooting.md) - Troubleshoot common migration issues
+ [Comparing migration options: EB CLI vs. AWS Application Migration Service](dotnet-migrating-applications-comparison.md) - Compare two primary migration options.

# Prerequisites


Before using the **eb migrate** command, ensure your environment meets these requirements:

**IIS installation and version**  
The server that you're migrating from must run Internet Information Services (IIS) version 7.0 or later. IIS 10.0 on Windows Server 2016 or later provides the most compatible environment for migration.  
To verify your IIS version run the following command:  

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\"
...
SetupString             : IIS 10.0
VersionString           : Version 10.0
...
```

**Windows Server requirements**  
Your source environment should run Windows Server 2016 or later for optimal compatibility. Elastic Beanstalk supports these Windows Server versions as target platforms:  
+ Windows Server 2025
+ Windows Server 2022
+ Windows Server 2019
+ Windows Server 2016

**EB CLI installation**  
+ *Default workflow (without the `--remote` option)*:
  + Python and the Elastic Beanstalk Command Line Interface (EB CLI) must be installed on the server that contains the application that you want to migrate to Elastic Beanstalk. While it is not required, we recommend installing the EB CLI inside a `virtualenv` sandbox as described in [Install the EB CLI in a virtual environment](eb-cli3.md#eb-cli3-install-virtualenv).
+ *Using the `--remote` option*:
  + Python and the Elastic Beanstalk Command Line Interface (EB CLI) must be installed on your bastion host. While it is not required, we recommend installing the EB CLI inside a `virtualenv` sandbox as described in [Install the EB CLI in a virtual environment](eb-cli3.md#eb-cli3-install-virtualenv).

**Required permissions**  
You need the following credentials and permissions:  
+ Administrator privileges on the source IIS server or on the bastion host (if using the `--remote` option).
+ AWS credentials with permissions to create and manage Elastic Beanstalk resources

**Web Deploy 3.6**  
Microsoft Web Deploy tool (version 3.6 or later) must be installed on your source server or on the bastion host (if using the `--remote` option). This tool is used by **eb migrate** to package your applications.  
To verify the installation run the following command:  
:  

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath

InstallPath  : C:\Program Files\IIS\Microsoft Web Deploy V3\
...
```
For installation instructions, see [Installing and Configuring Web Deploy on IIS 8.0 or Later](https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy-on-iis-80-or-later) on the Microsoft Windows product documentation website.

**Network requirements**  
+ *Default workflow (without the `--remote` option)*:
  + Your source server must have outbound internet access to AWS services.
+ *Using the `--remote` option*:
  + Your source server must have outbound internet access to AWS services.
  + Configure the proper security group ingress rules that allow for an outgoing network connection from your bastion host and an incoming connection into the remote machine. Ensure the IP of the bastion host is allow-listed via TCP on port 22 to access the remote machine.
  + Ensure your SSH client is installed and running on your remote machine as well as your bastion host.
  + Ensure that your firewall configuration contains the appropriate rules that open up port 22 or allow connection to the client.
  + Test your connection by manually SSH-ing into the remote host from the bastion host before attempting migration.

# Migration glossary


This glossary provides definitions for key terms and concepts related to IIS, Elastic Beanstalk, and the migration of IIS applications to Elastic Beanstalk.

## Windows, IIS, and .NET terms


****IIS****  
Internet Information Services, a web server software developed by Microsoft for use with Windows Server. IIS hosts websites, web applications, and web services, providing a platform for running ASP.NET and other web technologies. During migration to Elastic Beanstalk, IIS sites and their configurations are packaged and deployed to Windows Server instances in the AWS Cloud.  
IIS versions 7.0 and later are supported for migration, with IIS 10.0 on Windows Server 2016 or later providing the most compatible environment.

****.NET Framework****  
A software development platform developed by Microsoft for building and running Windows applications. It provides a large class library called Framework Class Library (FCL) and supports language interoperability across several programming languages.  
When migrating to Elastic Beanstalk, applications built on the .NET Framework continue to run on the same version of the framework in the cloud environment. Elastic Beanstalk supports multiple .NET Framework versions (4.x) on its Windows Server platforms.

****.NET Core****  
A cross-platform, open-source successor to the .NET Framework, designed to be more modular and lightweight. .NET Core (now simply called .NET 5 and later) enables developers to build applications that run on Windows, Linux, and macOS.  
When migrating applications built on .NET Core to Elastic Beanstalk, you can choose between Windows Server platforms or Linux-based platforms, depending on your application's requirements and dependencies.

****Common Language Runtime (CLR)****  
The virtual machine component of the .NET Framework that manages the execution of .NET programs. The CLR provides services such as memory management, type safety, exception handling, garbage collection, and thread management.  
When migrating to Elastic Beanstalk, the appropriate CLR version is automatically available on the Windows Server platform you select, ensuring compatibility with your application's requirements.

****Site****  
A logical container in IIS that represents a web application or service, identified by a unique binding of IP address, port, and host header. Each IIS site has its own application pool, bindings, and configuration settings, and can contain one or more applications.

****Application****  
A grouping of content and code files within an IIS site that handles requests for a specific URL space. Applications in IIS can have their own configuration settings, which are typically stored in `web.config` files.  
When migrating to Elastic Beanstalk, applications are preserved with their path structure and configuration settings. The migration process ensures that nested applications maintain their hierarchy and URL paths in the cloud environment.

****ApplicationPool****  
An IIS feature that isolates web applications for better security, reliability, and performance management. Application pools define the runtime environment for applications, including the .NET Framework version, pipeline mode, and identity settings.

****VirtualDirectory****  
A directory mapping in IIS that allows content to be served from a location outside the site's root directory. Virtual directories enable you to organize content across different physical locations while presenting a unified URL structure to users.  
When migrating to Elastic Beanstalk, virtual directories are preserved with their path mappings. The **eb migrate** command creates the necessary directory structure and configurations in the cloud environment to maintain the same URL paths.

****ARR****  
Application Request Routing, an IIS extension that provides load balancing and proxying capabilities for web servers. ARR enables URL-based routing, HTTP request forwarding, and load distribution across multiple servers.  
During migration to Elastic Beanstalk, ARR configurations are preserved through the installation of ARR features on EC2 instances and the configuration of appropriate routing rules. For complex routing scenarios, the migration process may also leverage Application Load Balancer rules to implement similar functionality.

****URL Rewrite****  
An IIS module that modifies requested URLs based on defined rules before they reach the web application. URL Rewrite enables URL manipulation, redirection, and content delivery based on patterns and conditions.  
When migrating to Elastic Beanstalk, URL rewrite rules from your `web.config` files are translated into ALB routing rules where possible, or preserved in the IIS configuration on the EC2 instances. This ensures that URL patterns and redirects continue to function as expected in the cloud environment.

****msdeploy.exe****  
A command-line tool used for deploying web applications and websites to IIS servers. Also known as Web Deploy, it provides a way to package, synchronize, and deploy web applications, websites, and server configurations.  
The **eb migrate** command uses Web Deploy (version 3.6 or later) to package your applications during migration to Elastic Beanstalk. This tool must be installed on your source server for the migration process to work correctly.

****Physical Path****  
The actual file system location where an IIS site or application's content files are stored. Physical paths can point to local directories, network shares, or other storage locations accessible to the IIS server.  
During migration to Elastic Beanstalk, physical paths are mapped to appropriate locations on the EC2 instances in your environment. The migration process preserves the content structure while ensuring that all files are properly deployed to the cloud environment.

****applicationHost.config****  
The root configuration file for IIS that defines server-wide settings and contains configuration for all sites, applications, and virtual directories. This file is located in the `%windir%\System32\inetsrv\config` directory and controls the overall behavior of the IIS server.  
When migrating to Elastic Beanstalk, relevant settings from `applicationHost.config` are extracted and applied to the IIS configuration on the EC2 instances in your environment. This ensures that server-wide settings are preserved during migration.

****web.config****  
An XML-based configuration file used in ASP.NET applications to control application settings, security, and behavior at the application or directory level. `web.config` files can contain settings for authentication, authorization, session state, compilation, and custom application parameters.  
During migration to Elastic Beanstalk, `web.config` files are preserved and deployed with your application. The migration process ensures that application-specific configurations continue to function as expected in the cloud environment.

****DefaultDocument****  
An IIS feature that specifies the default file to serve when a user requests a directory without specifying a file name. Default documents are enabled by default, and IIS 7 defines the following default document files in the `applicationHost.config` file as server-wide defaults: Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm.  
When migrating to Elastic Beanstalk, default document settings are preserved in the IIS configuration on the EC2 instances, ensuring that directory requests are handled consistently in the cloud environment.

****system.webServer****  
A configuration section in `web.config` or `applicationHost.config` that contains IIS-specific settings for modules, handlers, and other server behaviors. This section controls how IIS processes requests, manages modules, and configures server features.  
During migration to Elastic Beanstalk, system.webServer configurations are preserved in your application's `web.config` files and applied to the IIS installation on the EC2 instances in your environment. This ensures that IIS-specific behaviors are maintained in the cloud environment.

## Elastic Beanstalk terms


****Platform****  
A combination of operating system, programming language runtime, web server, application server, and Elastic Beanstalk components that define the software stack for running applications.  
For Windows migrations, Elastic Beanstalk provides platforms based on Windows Server 2016, 2019, and 2022 with IIS and various .NET Framework versions to ensure compatibility with your source environment.

****SolutionStack****  
A predefined platform configuration in Elastic Beanstalk that specifies the operating system, runtime, and other components needed to run an application. Conceptually identical to a platform and used interchangeably to operate environments.  
During migration, the **eb migrate** command selects an appropriate solution stack based on your source environment's configuration, ensuring compatibility with your IIS applications.

****CreateEnvironment****  
An Elastic Beanstalk API action that creates a new environment to host an application version. This API is used by the **eb migrate** command to provision the necessary AWS resources for your migrated application.  
The migration process configures appropriate environment parameters based on your source IIS environment, including instance type, environment variables, and option settings.

****CreateApplicationVersion****  
An Elastic Beanstalk API action that creates a new application version from a source bundle stored in Amazon S3. The **eb migrate** command uses this API to register your packaged IIS application as a version in Elastic Beanstalk.  
During migration, your application files and configuration are packaged, uploaded to Amazon S3, and registered as an application version before deployment.

****DescribeEvents****  
An Elastic Beanstalk API action that retrieves a list of events for an environment, including deployments, configuration changes, and operational issues. The **eb migrate** command uses this API to monitor the progress of your migration.  
You can also use the **eb events** command after migration to view the history of events for your environment.

****DescribeEnvironmentHealth****  
An Elastic Beanstalk API action that provides detailed health information about the instances and other components of an environment. This API is used to verify the health of your migrated application after deployment.  
After migration, you can use the **eb health** command to check the status of your environment and identify any issues that need attention.

****HealthD****  
A monitoring agent in Elastic Beanstalk that collects metrics, monitors logs, and reports health status for EC2 instances in an environment. HealthD provides enhanced health reporting for your migrated applications.  
After migration, HealthD monitors your application's performance, resource utilization, and request success rates, providing a comprehensive view of your environment's health.

****Bundle Logs****  
A feature in Elastic Beanstalk that compresses and uploads logs from EC2 instances to Amazon S3 for centralized storage and analysis. This feature helps you troubleshoot issues with your migrated applications.  
After migration, you can use the **eb logs** command to retrieve and view logs from your environment.

****aws-windows-deployment-manifest.json****  
A file that describes the contents, dependencies, and configuration of a software package or application. This manifest is generated during the migration process to define how your IIS applications should be deployed on Elastic Beanstalk.

****custom manifest section****  
A section within `aws-windows-deployment-manifest.json` that provides custom control over application deployment. This section contains PowerShell scripts and commands that are executed during the deployment process.  
During migration, custom manifest sections are generated to handle specific aspects of your IIS configuration, such as virtual directory setup, permission management, and application pool configuration.

****EB CLI****  
A command-line tool that provides commands for creating, configuring, and managing Elastic Beanstalk applications and environments. The EB CLI includes the **eb migrate** command specifically for migrating IIS applications to Elastic Beanstalk.  
After migration, you can continue to use the EB CLI to manage your environment, deploy updates, monitor health, and perform other administrative tasks.

****Option settings****  
Configuration values that define how Elastic Beanstalk provisions and configures AWS resources in your environment. Option settings are organized into namespaces that represent different components of your environment, such as load balancers, instances, and environment processes.  
During migration, the **eb migrate** command generates appropriate option settings based on your IIS configuration to ensure that your cloud environment matches your source environment's capabilities. For more information, see [Configuration options](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options-general.html) in the Elastic Beanstalk Developer Guide.

****aws:elbv2:listener:default****  
An Elastic Beanstalk configuration namespace for the default listener on an Application Load Balancer. During migration, this namespace is configured based on your IIS site bindings to ensure proper traffic routing.  
The default listener typically handles HTTP traffic on port 80, which is then forwarded to your application instances according to the routing rules.

****aws:elbv2:listener:listener\$1port****  
An Elastic Beanstalk configuration namespace for a specific listener port on an Application Load Balancer. This namespace is used to configure additional listeners for your migrated applications, such as HTTPS on port 443.  
During migration, listeners are created based on the port bindings of your IIS sites, ensuring that your applications remain accessible on the same ports as in your source environment.

****aws:elbv2:listenerrule:rule\$1name****  
An Elastic Beanstalk configuration namespace for defining routing rules for an Application Load Balancer listener. These rules determine how incoming requests are routed to different target groups based on path patterns or host headers.  
During migration, listener rules are created to match the URL structure of your IIS applications, ensuring that requests are routed to the correct application paths.

****aws:elasticbeanstalk:environment:process:default****  
An Elastic Beanstalk configuration namespace for the default process in an environment. This namespace defines how the default web application process is configured, including health check settings, port mappings, and proxy settings.  
During migration, the default process is configured based on your primary IIS site's settings, ensuring proper health monitoring and request handling.

****aws:elasticbeanstalk:environment:process:process\$1name****  
An Elastic Beanstalk configuration namespace for a specific named process in an environment. This namespace allows you to define multiple processes with different configurations, similar to having multiple application pools in IIS.  
During migration, additional processes may be created to represent different site bindings from your source environment.

**Note**  
For more information about some of the terms described in this topic see the following resources:  
Elastic Beanstalk API actions - [AWS Elastic Beanstalk API Reference](https://docs.aws.amazon.com/elasticbeanstalk/latest/api/)
Elastic Beanstalk platforms, including supported platform versions - [Supported Platforms](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html) in the *AWS Elastic Beanstalk Platforms guide*
Elastic Beanstalk configuration namespaces - [General options for all environments](command-options-general.md) in this guide
The EB CLI or specific EB CLI commands - [Setting up the EB command line interface (EB CLI) to manage Elastic Beanstalk](eb-cli3.md) in this guide

## Python terms


****pip****  
The package installer for Python, used to install and manage software packages written in Python. The EB CLI is installed and updated using pip.  
During the migration process, pip is used to install the EB CLI package and its dependencies on your source server, providing the tools needed for migration.

****PyPI****  
Python Package Index, the official repository for third-party Python software packages, from which pip retrieves and installs packages. The EB CLI and its dependencies are hosted on PyPI.  
When installing the EB CLI for migration, pip connects to PyPI to download and install the necessary packages.

****virtualenv****  
A tool to create isolated Python environments, allowing different projects to have their own dependencies and packages without conflicts. Using virtualenv is recommended when installing the EB CLI to avoid conflicts with other Python applications.  
Creating a virtual environment before installing the EB CLI ensures that the migration tools have a clean, isolated environment with the correct dependencies.

****pywin32****  
A set of Python extensions that provide access to many of the Windows APIs, enabling interaction with the Windows operating system and its components. The EB CLI uses pywin32 to interact with Windows-specific features during migration.  
During the migration process, pywin32 is used to access IIS configuration, Windows registry settings, and other system information needed to properly package and migrate your applications.

****pythonnet****  
A package that enables Python code to interact with .NET Framework and .NET Core applications. This integration allows the EB CLI to work with .NET components during the migration process.  
The migration process may use pythonnet to interact with .NET assemblies and components when analyzing and packaging your applications for deployment to Elastic Beanstalk.

# Performing basic IIS migrations
Basic IIS migrations

This section guides you through the process of migrating your IIS applications to Elastic Beanstalk using the **eb migrate** command.

## Exploring your IIS environment


Before making any changes, you'll want to understand what resources exist on your server. Start by exploring your IIS sites by running **eb migrate explore**, as shown in the following example:

```
PS C:\migrations_workspace> eb migrate explore
```

This command reveals your IIS sites. Refer to the following listing:

```
Default Web Site
Intranet
API.Internal
Reports
```

For a detailed view of each site's configuration, including bindings, applications, and virtual directories, add the `--verbose` option, as shown in this example:

```
PS C:\migrations_workspace> eb migrate explore --verbose
```

The following listing shows the comprehensive information about your environment the command provides:

```
1: Default Web Site:
  - Bindings:
    - *:80:www.example.com
    - *:443:www.example.com
  - Application '/':
    - Application Pool: DefaultAppPool
    - Enabled Protocols: http
    - Virtual Directories:
      - /:
        - Physical Path: C:\inetpub\wwwroot
        - Logon Method: ClearText
  - Application '/api':
    - Application Pool: ApiPool
    - Enabled Protocols: http
    - Virtual Directories:
      - /:
        - Physical Path: C:\websites\api
        - Logon Method: ClearText
2: Intranet:
...
3. API.Internal:
...
4. Reports:
...
```

### Understanding the discovery output


The verbose output provides the following critical information for migration planning:

Sites  
The discovery output lists all IIS sites on your server. Each site is identified by its name (e.g., "Default Web Site", "Intranet", "API.Internal") and numbered sequentially. When multiple sites exist on a server, the `eb migrate` command can package and deploy each one separately or together, depending on your migration strategy.

Bindings  
Protocol bindings reveal which protocols (HTTP/HTTPS) your sites use and on which ports they operate. The binding information includes host header requirements that define domain-based routing configurations.

Applications  
Application paths show both root and nested application structures within your IIS configuration. Application pool assignments indicate how your applications are isolated from each other for security and resource management.

Virtual directories  
Physical path mappings indicate where your content resides on the file system. Authentication settings show special access requirements that need to be maintained after migration.

## Preparing for migration


With an understanding of your environment, ensure that your server meets the prerequisites. First, verify your IIS version with the following PowerShell command:

```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\InetStp\" -Name MajorVersion
```

You need IIS 7.0 or later. The migration tool uses Web Deploy 3.6 for packaging your applications. Verify its installation with the following command:



```
PS C:\migrations_workspace> Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\IIS Extensions\MSDeploy\3" -Name InstallPath
```

If Web Deploy isn't installed on your server, you can download it from the [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy) download page.

## Your first migration


Let's start with a basic migration of the Default Web Site. The following example shows the simplest command, **eb migrate**.

```
PS C:\migrations_workspace> eb migrate
```

This command initiates a series of automated steps, shown in the following example output:

```
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0)
  id: vpc-1234567890abcdef0
  publicip: true
  elbscheme: public
  ec2subnets: subnet-123,subnet-456,subnet-789
  securitygroups: sg-123,sg-456
  elbsubnets: subnet-123,subnet-456,subnet-789

Using .\migrations\latest to contain artifacts for this migration run.
Generating source bundle for sites, applications, and virtual directories...
  Default Web Site/ -> .\migrations\latest\upload_target\DefaultWebSite.zip
```

The migration tool creates a structured directory containing your deployment artifacts. The following listing shows the directory structure:

```
C:\migration_workspace\
└── .\migrations\latest\
    └── upload_target\
        ├── DefaultWebSite.zip
        ├── aws-windows-deployment-manifest.json
        └── ebmigrateScripts\
            ├── site_installer.ps1
            ├── permission_handler.ps1
            └── >other helper scripts<
```

## Controlling the migration


For more control over the migration process, you can specify exactly which sites to migrate with the following command:

```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,Intranet"
```

You can also customize the environment name and application name, as shown in the following example command:

```
PS C:\migrations_workspace> eb migrate `
    --sites "Default Web Site" `
    --application-name "CorporateApp" `
    --environment-name "Production"
```

For a complete list of options, see [**eb migrate**](eb3-migrate.md).

## Monitoring progress


During migration, **eb migrate** provides real-time status updates. Refer to the following output example:

```
...
Creating application version
Creating environment... This may take a few minutes

2024-03-18 18:12:15    INFO    Environment details for: Production
  Application name: CorporateApp
  Region: us-west-2
  Deployed Version: app-230320_153045
  Environment ID: e-abcdef1234
  Platform: 64bit Windows Server 2019 v2.7.0 running IIS 10.0
  Tier: WebServer-Standard-1.0
  CNAME: production.us-west-2.elasticbeanstalk.com
  Updated: 2024-03-20 15:30:45
2025-03-18 18:12:17    INFO    createEnvironment is starting.
2025-03-18 18:12:19    INFO    Using elasticbeanstalk-us-east-1-180301529717 as Amazon S3 storage bucket for environment data.
2025-03-18 18:12:40    INFO    Created security group named: sg-0fdd4d696a26b086a
2025-03-18 18:12:48    INFO    Environment health has transitioned to Pending. Initialization in progress (running for 7 seconds). There are no instances.
...
2025-03-18 18:23:59    INFO    Application available at EBMigratedEnv-arrreal3.us-east-1.elasticbeanstalk.com.
2025-03-18 18:24:00    INFO    Successfully launched environment: EBMigratedEnv-arrreal3
```

## Verifying the migration


Once the environment is ready, Elastic Beanstalk provides several ways to verify your deployment.

Access your application  
Open your application URL (CNAME) in a web browser to verify it's working correctly.

Check environment health  
Use the **eb health** command to view the health of your environment.  

```
PS C:\migrations_workspace> eb health
```
The following screen image shows instance health, application response metrics, and system resource utilization.  

![\[Output from eb health command shows instance health, application response metrics, and system resource utilization.\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/eb-health-after-migration.png)


Use the **eb logs** command to access logs to troubleshoot any issues:  

```
PS C:\migrations_workspace> eb logs --zip
```
The **eb logs** command downloads logs to the `.elasticbeanstalk/logs` directory. For more information, see [Using Elastic Beanstalk with Amazon CloudWatch Logs](AWSHowTo.cloudwatchlogs.md).

Connect to instances  
If you specified a key pair during migration, you can connect to your instances using RDP for direct troubleshooting.

Access the Elastic Beanstalk console  
You can view the environment's health, logs, and configuration properties through the [environment management console](environments-console.md) for that environment. 

## Managing migration artifacts


The **eb migrate** command creates local artifacts during the migration process. These artifacts contain sensitive information and can consume significant disk space over time. Use the **cleanup** subcommand to manage these artifacts, as shown in the following example:

```
PS C:\migrations_workspace> eb migrate cleanup
Are you sure you would like to cleanup older artifacts within ./migrations/? (Y/N):
```

To force cleanup without confirmation use the **--force** option:

```
PS C:\migrations_workspace> eb migrate cleanup --force
```

The cleanup process preserves the most recent successful migration in the `./migrations/latest` directory and removes older migration directories

# Network configuration and port settings
Network configuration

This section covers network configuration options for IIS migrations, including VPC settings, port configurations, and multi-site deployments.

## VPC configuration


The **eb migrate** command provides flexible VPC configuration options for your Elastic Beanstalk environment. The tool can either detect VPC settings from a source EC2 instance or accept custom VPC configurations through command-line parameters. Review [Using Elastic Beanstalk with Amazon VPC](vpc.md) to understand how to configure Elastic Beanstalk with VPC.

### Automatic VPC detection


When **eb migrate** runs on an EC2 instance, it automatically discovers and uses the VPC configuration from the source environment's EC2 instances. The following example output illustrates the configuration information that it detects:

```
PS C:\migrations_workspace > eb migrate
Identifying VPC configuration of this EC2 instance (i-0123456789abcdef0):
  id: vpc-1234567890abcdef0
  publicip: true
  elbscheme: public
  ec2subnets: subnet-123,subnet-456,subnet-789
  securitygroups: sg-123,sg-456
  elbsubnets: subnet-123,subnet-456,subnet-789
...
```

The detected configuration includes:
+ VPC identifier
+ Public IP assignment settings
+ Load balancer scheme (public/private)
+ EC2 instance subnet assignments
+ Security group associations
+ Load balancer subnet assignments

### On-premises or non-AWS cloud hosts


When **eb migrate** runs from an on-premises server or a non-AWS cloud host, the Elastic Beanstalk service will use the default VPC in your AWS account. The following listing shows an example command and output:

```
PS C:\migrations_worspace> eb migrate `
      -k windows-test-pem `
      --region us-east-1 `
      -a EBMigratedEnv `
      -e EBMigratedEnv-test2 `
      --copy-firewall-config
Determining EB platform based on host machine properties
Using .\migrations\latest to contain artifacts for this migration run.
...
```

Review [Using Elastic Beanstalk with Amazon VPC](vpc.md) to understand how Elastic Beanstalk configures the default VPC for your environment.

### Custom VPC configuration


For any source environment (EC2, on-premises, or non-AWS cloud) where you need specific VPC settings, provide a VPC configuration file like the one in the following example:

```
{
    "id": "vpc-12345678",
    "publicip": "true",
    "elbscheme": "public",
    "ec2subnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"],
    "securitygroups": "sg-123456,sg-789012",
    "elbsubnets": ["subnet-a1b2c3d4", "subnet-e5f6g7h8"]
}
```

Apply this configuration using the following command:

```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```

**Note**  
The VPC configuration file requires the `id` field that specifies the VPC ID. All other fields are optional, and Elastic Beanstalk will use default values for any fields that you don't specify.

**Important**  
*The migration will ignore any existing VPC settings from the source environment when you specify the *`--vpc-config` *parameter*. When you use this parameter, the migration will only use the VPC settings specified in the configuration file that you're passing in. Using this parameter overrides the default behavior of discovering the source instance's VPC configuration or using the default VPC.

Use the `--vpc-config` parameter in these scenarios:
+ When you migrate non-EC2 environments that don't have discoverable VPC settings
+ When you migrate to a different VPC from the one used by the source environment
+ When you need to customize subnet selections or security group configurations
+ When the automatic discovery doesn't correctly identify the desired VPC settings
+ When you migrate from on-premises, and you don't want to use the default VPC

### Network security configuration


By default, **eb migrate** opens port 80 on target instances but does not copy other Windows Firewall rules from the source machine. To include all firewall configurations use the following command:

```
PS C:\migrations_workspace> eb migrate --copy-firewall-config
```

This command does the following actions:
+ Identifies ports used by IIS site bindings
+ Retrieves corresponding firewall rules
+ Generates PowerShell scripts to recreate rules on target instances
+ Preserves any DENY rules for port 80 from the source machine (otherwise port 80 is allowed by default)

Consider a use case, where your source machine has the firewall rules specified in the following example:

```
# Source machine firewall configuration
Get-NetFirewallRule | Where-Object {$_.Enabled -eq 'True'} | Get-NetFirewallPortFilter | Where-Object {$_.LocalPort -eq 80 -or $_.LocalPort -eq 443 -or $_.LocalPort -eq 8081}
# Output shows rules for ports 80, 443, and 8081
```

The migration creates a script (`modify_firewall_config.ps1`) that contains the following configuration:

```
New-NetFirewallRule -DisplayName "Allow Web Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 80,443
New-NetFirewallRule -DisplayName "Allow API Traffic" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8081
```

The migration tool automatically does the following actions:
+ Extracts HTTP/HTTPS ports from all IIS site bindings
+ Uses the Windows Firewall [INetFwPolicy2](https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwpolicy2) interface to enumerate firewall rules
+ Filters rules to only include those that explicitly reference the specified ports
+ Only processes HTTP and HTTPS site bindings and their associated firewall rules
+ Preserves rule properties including display name, action, protocol, and enabled state
+ Handles both individual ports and port ranges in firewall rules
+ Adds the firewall configuration script to the deployment manifest

### Load balancer configuration


You can specify Load Balancer configuration through the `--vpc-config` argument. The examples that follow demonstrate the parameters.

Scheme selection  
Choose between public and private load balancer schemes:  

```
{
    "id": "vpc-12345678",
    "elbscheme": "private",
    "elbsubnets": ["subnet-private1", "subnet-private2"]
}
```

Subnet distribution  
For high availability, distribute load balancer subnets across Availability Zones:  

```
{
    "elbsubnets": [
        "subnet-az1", // Availability Zone 1
        "subnet-az2", // Availability Zone 2
        "subnet-az3"  // Availability Zone 3
    ]
}
```

**Note**  
While Elastic Beanstalk supports environment creation with Application Load Balancers, Network Load Balancers, and Classic Load Balancers, the **eb migrate** command only supports Application Load Balancers. For more information about load balancer types, see [Load balancer for your Elastic Beanstalk environment](using-features.managing.elb.md).

## Multi-site deployments with port configurations


The **eb migrate** command handles complex multi-site IIS deployments where applications might share dependencies or use non-standard ports. Consider the following example of a typical enterprise setup with multiple sites:

```
<!-- IIS Configuration -->
<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:80:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:reports.internal" />
        </bindings>
    </site>
</sites>
```

To migrate this configuration, use the following example command and parameters:

```
PS C:\migrations_workspace> eb migrate `
    --sites "Default Web Site,InternalAPI,ReportingPortal" `
    --copy-firewall-config `
    --instance-type "c5.large"
```

The **eb migrate** command creates a deployment package that preserves each site's identity and configuration. The command generates an `aws-windows-deployment-manifest.json` that defines how these sites should be deployed. The following example demonstrates a generated json file:

```
{
    "manifestVersion": 1,
    "deployments": {
        "msDeploy": [
            {
                "name": "DefaultWebSite",
                "parameters": {
                    "appBundle": "DefaultWebSite.zip",
                    "iisPath": "/",
                    "iisWebSite": "Default Web Site"
                }
            }
        ],
        "custom": [
            {
                "name": "InternalAPI",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_InternalAPI.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_InternalAPI.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_InternalAPI.ps1"
                    }
                }
            },
            {
                "name": "ReportingPortal",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\install_site_ReportingPortal.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\restart_site_ReportingPortal.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\uninstall_site_ReportingPortal.ps1"
                    }
                }
            }
        ]
    }
}
```

The migration process creates the following Application Load Balancer listener rules that maintain your original routing logic:
+ Port 80 traffic routes to Default Web Site
+ Port 8081 traffic routes to InternalAPI
+ Port 8082 traffic routes to ReportingPortal

## Shared configuration and dependencies


When sites share configurations or dependencies, **eb migrate** handles these relationships appropriately. Reference the following example where multiple sites share a common configuration:

```
<!-- Shared configuration in applicationHost.config -->
<location path="Default Web Site">
    <system.webServer>
        <asp enableSessionState="true" />
        <caching enabled="true" enableKernelCache="true" />
    </system.webServer>
</location>
```

The migration process completes the following tasks:

1. Identifies shared configurations across sites

1. Generates appropriate PowerShell scripts to apply these settings

1. Maintains configuration hierarchy and inheritance

## Best practices


We recommend that you follow best practices for the network configuration of your migrated application. The following groupings provide summary guidelines.

VPC design  
+ Follow AWS VPC Design Best Practices
+ Use separate subnets for load balancers and EC2 instances
+ Implement proper route tables and NACLs
+ Consider VPC endpoints for AWS services

High availability  
+ Deploy across multiple Availability Zones
+ Use at least two subnets for load balancers
+ Configure auto-scaling across AZs
+ Implement proper health checks

Security  
+ Follow Security Best Practices
+ Use security groups as primary access control
+ Implement network Access Control Lists (ACLs) for additional security
+ Monitor VPC Flow Logs

## Troubleshooting


Common network configuration issues include the following areas. Following each subject are example commands to obtain more information about the network configuration and health of your environment.

Subnet configuration  

```
# Verify subnet availability
PS C:\migrations_workspace> aws ec2 describe-subnets --subnet-ids subnet-id

# Check available IP addresses
PS C:\migrations_workspace>aws ec2 describe-subnets --subnet-ids subnet-id --query 'Subnets[].AvailableIpAddressCount'
```

Security group access  

```
# Verify security group rules
PS C:\migrations_workspace> aws ec2 describe-security-groups --group-ids sg-id

# Test network connectivity
PS C:\migrations_workspace> aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-id
```

Load balancer health  

```
# Check load balancer health
PS C:\migrations_workspace> aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account-id:targetgroup/group-name/group-id
```

# Security configurations and IAM roles
Security configuration

The **eb migrate** command manages AWS security configurations through IAM roles, instance profiles, and service roles. Understanding these components ensures proper access control and security compliance during migration.

## Instance profile configuration


An instance profile serves as a container for an IAM role that Elastic Beanstalk attaches to EC2 instances in your environment. When executing **eb migrate**, you can specify a custom instance profile:

```
PS C:\migrations_workspace> eb migrate --instance-profile "CustomInstanceProfile"
```

If you don't specify an instance profile, **eb migrate** creates a default profile with these permissions:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::elasticbeanstalk-*",
                "arn:aws:s3:::elasticbeanstalk-*/*"
            ]
        }
    ]
}
```

------

## Service role management


A service role allows Elastic Beanstalk to manage AWS resources on your behalf. Specify a custom service role during migration with the following command:

```
PS C:\migrations_workspace> eb migrate --service-role "CustomServiceRole"
```

If not specified, **eb migrate** creates a default service role named `aws-elasticbeanstalk-service-role` with a trust policy that allows Elastic Beanstalk to assume the role. This service role is essential for Elastic Beanstalk to monitor your environment's health and perform managed platform updates. The service role requires two managed policies:
+ `AWSElasticBeanstalkEnhancedHealth` - Allows Elastic Beanstalk to monitor instance and environment health using the enhanced health reporting system
+ `AWSElasticBeanstalkManagedUpdates` - Allows Elastic Beanstalk to perform managed platform updates, including updating environment resources when a new platform version is available

With these policies, the service role has permissions to:
+ Create and manage Auto Scaling groups
+ Create and manage Application Load Balancers
+ Upload logs to Amazon CloudWatch
+ Manage EC2 instances

For more information about service roles, see [Elastic Beanstalk service role](concepts-roles-service.md) in the Elastic Beanstalk Developer Guide.

## Security group configuration


The **eb migrate** command automatically configures security groups based on your IIS site bindings. For example, if your source environment has sites using ports 80, 443, and 8081 the following configuration results:

```
<site name="Default Web Site">
    <bindings>
        <binding protocol="http" bindingInformation="*:80:" />
        <binding protocol="https" bindingInformation="*:443:" />
    </bindings>
</site>
<site name="InternalAPI">
    <bindings>
        <binding protocol="http" bindingInformation="*:8081:" />
    </bindings>
</site>
```

The migration process completes the following actions:
+ Creates a load balancer security group allowing inbound traffic on ports 80 and 443 from the internet (0.0.0.0/0)
+ Creates an EC2 security group allowing traffic from the load balancer
+ Configures additional ports (like 8081) if `--copy-firewall-config` is specified

By default, the Application Load Balancer is configured with public access from the internet. If you need to customize this behavior, such as restricting access to specific IP ranges or using a private load balancer, you can override the default VPC and security group configuration using the `--vpc-config` parameter:

```
PS C:\migrations_workspace> eb migrate --vpc-config vpc-config.json
```

For example, the following `vpc-config.json` configuration creates a private load balancer in a private subnet:

```
{
    "id": "vpc-12345678",
    "publicip": "false",
    "elbscheme": "internal",
    "ec2subnets": ["subnet-private1", "subnet-private2"],
    "elbsubnets": ["subnet-private1", "subnet-private2"]
}
```

For more information about VPC configuration options, see [VPC configuration](dotnet-migrating-applications-network.md#dotnet-migrating-applications-network-vpc).

## SSL certificate integration


When migrating sites with HTTPS bindings, integrate SSL certificates through AWS Certificate Manager (ACM):

```
PS C:\migrations_workspace> eb migrate --ssl-certificates "arn:aws:acm:region:account:certificate/certificate-id"
```

This configuration completes the following actions:
+ Associates the certificate with the Application Load Balancer
+ Maintains HTTPS termination at the load balancer
+ Preserves internal HTTP communication between the load balancer and EC2 instances

## Windows authentication


For applications using Windows Authentication, **eb migrate** preserves the authentication settings in the application's `web.config` as follows:

```
<configuration>
    <system.webServer>
        <security>
            <authentication>
                <windowsAuthentication enabled="true">
                    <providers>
                        <add value="Negotiate" />
                        <add value="NTLM" />
                    </providers>
                </windowsAuthentication>
            </authentication>
        </security>
    </system.webServer>
</configuration>
```

**Important**  
The **eb migrate** command does not copy over user profiles or accounts from your source environment to the target Elastic Beanstalk instances. Any custom user accounts or groups that you've created on your source server will need to be recreated on the target environment after migration.

Built-in Windows accounts like `IUSR` and groups like `IIS_IUSRS`, as well as all other built-in accounts and groups, are included by default on the target Windows Server instances. For more information about built-in IIS accounts and groups, see [Understanding Built-In User and Group Accounts in IIS](https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis) in the Microsoft documentation.

If your application relies on custom Windows user accounts or Active Directory integration, you will need to configure these aspects separately after the migration is complete.

## Best practices and troubleshooting


### Role management


Implement AWS IAM best practices when managing roles for your Elastic Beanstalk environments:

Role creation and management  
+ Create roles using AWS managed policies where possible
+ Follow the [IAM Security Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
+ Use the [AWS Policy Generator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) for custom policies
+ Implement [permission boundaries](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) for additional security

Monitoring and auditing  
Enable AWS CloudTrail to monitor role usage:  
+ Follow the [AWS CloudTrail User Guide](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ Configure CloudWatch Logs integration for real-time monitoring
+ Set up alerts for unauthorized API calls

Regular review process  
Establish a quarterly review cycle to do the following tasks:  
+ Audit unused permissions using [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)
+ Remove outdated permissions
+ Update roles based on least-privilege principles

### Certificate management


Implement these practices for SSL/TLS certificates in your Elastic Beanstalk environments:

Certificate lifecycle  
+ Use [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html) for certificate management
+ Enable [automatic renewal](https://docs.aws.amazon.com/acm/latest/userguide/check-certificate-renewal-status.html) for ACM-issued certificates
+ Set up [expiration notifications](https://docs.aws.amazon.com/acm/latest/userguide/notifications-for-ACM.html)

Security standards  
+ Use TLS 1.2 or later
+ Follow [AWS security policies](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies) for HTTPS listeners
+ Implement HTTP Strict Transport Security (HSTS) if required

### Security group management


Implement these security group best practices:

Rule management  
+ Document all custom port requirements
+ Use [VPC Flow Logs](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) to monitor traffic
+ Use [Security Group reference rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) instead of IP ranges where possible

Regular auditing  
Establish monthly reviews to do the following tasks:  
+ Identify and remove unused rules
+ Validate source/destination requirements
+ Check for overlapping rules

### Logging and monitoring


For effective security monitoring, configure the following logs:

Windows event logs on EC2 instances  

```
# Review Security event log
PS C:\migrations_workspace> Get-EventLog -LogName Security -Newest 50

# Check Application event log
PS C:\migrations_workspace> Get-EventLog -LogName Application -Source "IIS*"
```

CloudWatch Logs integration  
Configure CloudWatch Logs agent to stream Windows event logs to CloudWatch for centralized monitoring and alerting.

For persistent issues, gather these logs and contact AWS Support with the following information:
+ Environment ID
+ Deployment ID (if applicable)
+ Relevant error messages
+ Timeline of security changes

# Understanding IIS to Elastic Beanstalk migration mapping
IIS to Elastic Beanstalk migration mapping

The migration from IIS to Elastic Beanstalk involves mapping your on-premises Windows server configuration to AWS cloud resources. Understanding this mapping is crucial for successful migrations and post-migration management.

## IIS sites and applications in Elastic Beanstalk


In IIS, a website represents a collection of web applications and virtual directories, each with its own configuration and content. When migrating to Elastic Beanstalk, these components are transformed as follows:

**IIS websites**  
Your IIS websites become applications within Elastic Beanstalk. Each website's configuration, including its bindings, application pools, and authentication settings, is preserved through Elastic Beanstalk's deployment manifest (`aws-windows-deployment-manifest.json`).  
For example, if you have multiple sites like *Default Web Site* and *IntranetSite*, **eb migrate** packages each site's content and configuration while maintaining their isolation.  
The command creates appropriate Application Load Balancer (ALB) listener rules to handle routing requests to your applications. It also configures security groups to ensure proper port access based on your original IIS bindings.

**Application pools**  
IIS application pools provide worker process isolation, runtime management, and recycling capabilities for your applications. In Elastic Beanstalk, these are mapped to environment processes defined through the `aws:elasticbeanstalk:environment:process` namespace and configured via IIS on the EC2 instances.  
The migration preserves critical application pool settings including the following:  
+ Process model configurations - Identity (ApplicationPoolIdentity, NetworkService, or custom accounts), idle timeout settings, and process recycling intervals
+ .NET CLR version settings - Maintains your specified .NET Framework version (v2.0, v4.0, or No Managed Code) to ensure application compatibility
+ Managed pipeline mode - Preserves Integrated or Classic pipeline mode settings to maintain your HTTP request processing architecture
+ Advanced settings - Queue length, CPU limits, rapid-fail protection thresholds, and startup time limits
The **eb migrate** command preserves mappings between sites and application pools during the migration to your Elastic Beanstalk environment.  
If your application pools use custom recycling schedules (specific times or memory thresholds), these are implemented through PowerShell scripts in the deployment package that configure the appropriate IIS settings on the EC2 instances.

**Website bindings**  
IIS website bindings, which define how clients access your applications, are transformed into the following Application Load Balancer (ALB) configurations:  
+ Port bindings are mapped to corresponding ALB listener rules
+ Host header configurations are translated into ALB routing rules
+ SSL-enabled sites use AWS Certificate Manager (ACM) for certificate management

## Virtual directory and application path management


IIS virtual directories and applications provide URL path mapping to physical directories. Elastic Beanstalk maintains these relationships through the following constructs:

**Virtual directories**  
The migration process preserves the physical paths of your virtual directories in the deployment package.  
Path mappings are configured in the IIS configuration on the EC2 instances, ensuring that your URL structure remains intact after migration.

**Non-system drive physical paths**  
By default, Elastic Beanstalk Windows environments only provision the C:\$1 drive (root volume). In the current version, applications with content on non-system drives (D:\$1, E:\$1, etc.) are not supported for migration.
The **eb migrate** command automatically detects physical paths located on non-system drives and warns you about potential issue like the following example:  

```
ERROR: Detected physical paths on drive D:\ which are not supported in the current version:
  - D:\websites\intranet
  - D:\shared\images

Migration of content from non-system drives is not supported. Please relocate this content to the C:\ drive before migration. Otherwise, select only those sites that are on C:\.
```
If your application has dependencies on non-system drives, you will need to modify your application to store all content on the C:\$1 drive before migration.

**Nested applications**  
Applications nested under websites are deployed with their correct path configurations and appropriate application pool assignments. The migration process preserves all` web.config` settings, ensuring that application-specific configurations continue to function as expected in the cloud environment.

## URL rewrite and application request routing (ARR)


If your IIS deployment uses URL Rewrite or Application Request Routing (ARR), **eb migrate** handles these configurations through the following rules and configuration:

**URL rewrite rules**  
URL rewrite rules from your `web.config` files are translated into ALB routing rules where possible. For example, the following entry becomes an ALB listener rule directing traffic based on host headers and path patterns.:  

```
<!-- Original IIS URL Rewrite Rule -->
<rule name="Redirect to WWW" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTP_HOST}" pattern="^example.com$" />
    </conditions>
    <action type="Redirect" url="http://www.example.com/{R:1}" />
</rule>
```


**Application request routing**  
ARR configurations are preserved through the installation of ARR features on EC2 instances. The migration process completes the following tasks:  
+ Configures proxy settings to match your source environment
+ Maintains URL rewrite rules associated with ARR

## Migration artifact structure


When you run **eb migrate**, it creates a structured directory containing all necessary deployment components. The following listing describes the directory structure:

```
C:\migration_workspace\
└── .\migrations\latest\
    └── upload_target\
        ├── [SiteName].zip                 # One ZIP per IIS site
        ├── aws-windows-deployment-manifest.json
        └── ebmigrateScripts\
            ├── site_installer.ps1         # Site installation scripts
            ├── arr_configuration.ps1      # ARR configuration scripts
            ├── permission_handler.ps1     # Permission management
            └── firewall_config.ps1        # Windows Firewall rules
```

The `aws-windows-deployment-manifest.json` file is the core configuration file that instructs Elastic Beanstalk how to deploy your applications. Refer to the following example structure:

```
{
    "manifestVersion": 1,
    "deployments": {
        "msDeploy": [
            {
                "name": "Primary Site",
                "parameters": {
                    "appBundle": "DefaultWebSite.zip",
                    "iisPath": "/",
                    "iisWebSite": "Default Web Site"
                }
            }
        ],
        "custom": [
            {
                "name": "ConfigureARR",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\arr_configuration.ps1"
                    },
                    "uninstall": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    },
                    "restart": {
                        "file": "ebmigrateScripts\\noop.ps1"
                    }
                }
            }
        ]
    }
}
```

This manifest ensures these results for your migration:
+ Applications are deployed to correct IIS paths
+ Custom configurations are applied
+ Site-specific settings are preserved
+ Deployment order is maintained

# Advanced migration scenarios


This section covers advanced migration scenarios for complex IIS deployments.

## Multi-site migrations with Application Request Routing (ARR)


The **eb migrate** command automatically detects and preserves ARR configurations during migration. When it identifies ARR settings in your IIS `applicationHost.config`, it generates the necessary PowerShell scripts to reinstall and configure ARR on the target EC2 instances.

### ARR configuration detection


The migration process examines three key configuration sections in IIS:
+ `system.webServer/proxy`: Core ARR proxy settings
+ `system.webServer/rewrite`: URL rewrite rules
+ `system.webServer/caching`: Caching configuration

For example, consider a common ARR configuration where a `RouterSite` running on port 80 proxies requests to `APIService` and `AdminPortal` running on ports 8081 and 8082 respectively:

```
<!-- Original IIS ARR Configuration -->
<rewrite>
    <rules>
        <rule name="Route to API" stopProcessing="true">
            <match url="^api/(.*)$" />
            <action type="Rewrite" url="http://backend:8081/api/{R:1}" />
        </rule>
        <rule name="Route to Admin" stopProcessing="true">
            <match url="^admin/(.*)$" />
            <action type="Rewrite" url="http://backend:8082/admin/{R:1}" />
        </rule>
    </rules>
</rewrite>
```

The following diagram depicts how these rules are hidden behind port 80 in the IIS server and not exposed via the EC2 Security Groups. Only port 80 is accessible to the Application Load Balancer and all traffic from it is routed to the target group at port 80.

![\[Elastic Beanstalk architecture with Application Request Routing (ARR)\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/architecture-diagram-with-arr.png)


The following command can migrate this configuration:

```
PS C:\migrations_workspace> eb migrate --sites "RouterSite,APIService,AdminPortal" `
    --copy-firewall-config
```

### ARR migration process


The migration process preserves your ARR configuration through several steps.

Configuration export  
The tool exports your existing ARR settings from the three key configuration sections into separate XML files stored in the `ebmigrateScripts` directory:  

```
ebmigrateScripts\
├── arr_config_proxy.xml
├── arr_config_rewrite.xml
└── arr_config_caching.xml
```

Installation scripts  
Two PowerShell scripts are generated to handle ARR setup:  

1. `arr_msi_installer.ps1`: Downloads and installs the ARR module

1. `arr_configuration_importer_script.ps1`: Imports your exported ARR configuration

Deployment manifest integration  
The scripts are integrated into the deployment process through entries in `aws-windows-deployment-manifest.json`:  

```
{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "WindowsProxyFeatureEnabler",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\windows_proxy_feature_enabler.ps1"
                    }
                }
            },
            {
                "name": "ArrConfigurationImporterScript",
                "scripts": {
                    "install": {
                        "file": "ebmigrateScripts\\arr_configuration_importer_script.ps1"
                    }
                }
            }
        ]
    }
}
```

### Load balancer integration


The migration process translates your ARR rules into Application Load Balancer (ALB) listener rules where possible. For example, the above ARR configuration results in ALB rules that route traffic based on URL path patterns while maintaining internal routing on the EC2 instances.

The resulting environment maintains your ARR routing logic while taking advantage of AWS's elastic infrastructure. Your applications continue to work as before, with ARR handling internal routing while the Application Load Balancer manages external traffic distribution.

## Multi-site migrations without ARR using host-based routing


While Application Request Routing (ARR) is a common approach for managing multiple sites in IIS, you can also migrate multi-site deployments directly to Elastic Beanstalk without ARR by leveraging the Application Load Balancer's host-based routing capabilities. This approach can reduce complexity and improve performance by eliminating an additional routing layer.

### Host-based routing overview


In this approach, each IIS site is exposed outside the EC2 instance, and the Application Load Balancer routes traffic directly to the appropriate port based on the host header. This eliminates the need for ARR while maintaining separation between your applications.

Consider a multi-site IIS configuration with three sites, each with its own hostname binding:

```
<sites>
    <site name="Default Web Site" id="1">
        <bindings>
            <binding protocol="http" bindingInformation="*:8081:www.example.com" />
        </bindings>
    </site>
    <site name="InternalAPI" id="2">
        <bindings>
            <binding protocol="http" bindingInformation="*:8082:api.internal" />
        </bindings>
    </site>
    <site name="ReportingPortal" id="3">
        <bindings>
            <binding protocol="http" bindingInformation="*:8083:reports.internal" />
        </bindings>
    </site>
</sites>
```

These sites are exposed at ports 8081, 8082, and 8083 via the EC2 Security Groups. The Application Load Balancer routes to them based on the Load Balancer listener rule configuration.

![\[Elastic Beanstalk architecture without Application Request Routing (ARR)\]](http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/images/architecture-diagram-without-arr.png)


### Migration process


To migrate this configuration to Elastic Beanstalk without using ARR use the **eb migrate** command in the following example:

```
PS C:\migrations_workspace> eb migrate --sites "Default Web Site,InternalAPI,ReportingPortal"
```

The migration process automatically configures the Application Load Balancer with host-based routing rules that direct traffic to the appropriate target group based on the host header. Each target group forwards traffic to the corresponding port on your EC2 instances:

1. Host header www.example.com → Target Group on port 8081

1. Host header api.internal → Target Group on port 8082

1. Host header reports.internal → Target Group on port 8083

### SSL/TLS configuration


To secure your applications with SSL/TLS do the following steps:

1. Request certificates for your domains through AWS Certificate Manager(ACM).

1. Configure HTTPS listeners on your Application Load Balancer using these certificates.

1. Update your environment configuration to include HTTPS listeners with the following configuration option settings.

   ```
   option_settings:
     aws:elb:listener:443:
       ListenerProtocol: HTTPS
       SSLCertificateId: arn:aws:acm:region:account-id:certificate/certificate-id
       InstancePort: 80
       InstanceProtocol: HTTP
   ```

With this configuration, SSL termination occurs at the load balancer, and traffic is forwarded to your instances over HTTP. This simplifies certificate management while maintaining secure connections with clients.

### Best practices


Security groups  
Configure security groups to allow inbound traffic only on the ports used by your IIS sites (8081, 8082, 8083 in this example) from the Application Load Balancer security group.

Health checks  
Configure health checks for each target group to ensure traffic is only routed to healthy instances. Create health check endpoints for each application if they don't already exist.

Monitoring  
Set up CloudWatch alarms to monitor the health and performance of each target group separately. This allows you to identify issues specific to individual applications.

Scaling  
Consider the resource requirements of all applications when configuring auto scaling policies. If one application has significantly different resource needs, consider migrating it to a separate environment.

## Virtual directory management


The **eb migrate** command preserves virtual directory structures while migrating your IIS applications to Elastic Beanstalk.

### Default permission configuration


When migrating virtual directories, **eb migrate** establishes a baseline set of permissions by granting ReadAndExecute access to:
+ IIS\$1IUSRS
+ IUSR
+ Authenticated Users

For example, consider a typical virtual directory structure:

```
<site name="CorporatePortal">
    <application path="/" applicationPool="CorporatePortalPool">
        <virtualDirectory path="/" physicalPath="C:\sites\portal" />
        <virtualDirectory path="/shared" physicalPath="C:\shared\content" />
        <virtualDirectory path="/reports" physicalPath="D:\reports" />
    </application>
</site>
```

### Password-protected virtual directories


When **eb migrate** encounters password-protected virtual directories, it issues warnings and requires manual intervention. 

The following configuration example will cause the warning response that follows the example.

```
<virtualDirectory path="/secure" 
                 physicalPath="C:\secure\content"
                 userName="DOMAIN\User"
                 password="[encrypted]" />
```

```
[WARNING] CorporatePortal/secure is hosted at C:\secure\content which is password-protected and won't be copied.
```

To maintain password protection, create a custom deployment script like the following:

```
# PS C:\migrations_workspace> cat secure_vdir_config.ps1

$vdirPath = "C:\secure\content"
$siteName = "CorporatePortal"
$vdirName = "secure"
$username = "DOMAIN\User"
$password = "SecurePassword"

# Ensure directory exists
if (-not (Test-Path $vdirPath)) {
    Write-Host "Creating directory: $vdirPath"
    New-Item -Path $vdirPath -ItemType Directory -Force
}

# Configure virtual directory with credentials
Write-Host "Configuring protected virtual directory: $vdirName"
New-WebVirtualDirectory -Site $siteName -Name $vdirName `
    -PhysicalPath $vdirPath -UserName $username -Password $password

# Set additional permissions as needed
$acl = Get-Acl $vdirPath
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $username, "ReadAndExecute", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl $vdirPath $acl
```

Add this script to your deployment by including it in the manifest:

```
{
    "manifestVersion": 1,
    "deployments": {
        "custom": [
            {
                "name": "SecureVirtualDirectory",
                "scripts": {
                    "install": {
                        "file": "secure_vdir_config.ps1"
                    }
                }
            }
        ]
    }
}
```

### Custom permission management


The **eb migrate** command provides a framework for custom permission scripts to accommodate applications that require permissions other than the defaults. 



```
$paths = @(
    "C:\sites\portal\uploads",
    "C:\shared\content"
)

foreach ($path in $paths) {
    if (-not (Test-Path $path)) {
        Write-Host "Creating directory: $path"
        New-Item -Path $path -ItemType Directory -Force
    }

    $acl = Get-Acl $path

    # Add custom permissions
    $customRules = @(
        # Application Pool Identity - Full Control
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "IIS AppPool\CorporatePortalPool", 
            "FullControl", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        ),
        # Custom Service Account
        [System.Security.AccessControl.FileSystemAccessRule]::new(
            "NT SERVICE\CustomService", 
            "Modify", 
            "ContainerInherit,ObjectInherit", 
            "None", 
            "Allow"
        )
    )

    foreach ($rule in $customRules) {
        $acl.AddAccessRule($rule)
    }
    
    Set-Acl $path $acl
    Write-Host "Custom permissions applied to: $path"
}
```

### Best practices


Follow these best practices to plan, execute, monitor, and verify your migration.

Pre-migration planning  
Document existing permissions and authentication requirements before migration. Test custom permission scripts in a development environment before deploying to production.

Shared content management  
For shared content directories, ensure all necessary file system permissions are properly configured through custom scripts. Consider using [Amazon FSx for Windows File Server](https://aws.amazon.com/fsx/windows/) for shared storage requirements.

Monitoring and verification  
Monitor application logs after migration to verify proper access to virtual directories. Pay special attention to the following areas:  
+ Application pool identity access
+ Custom service account permissions
+ Network share connectivity
+ Authentication failures

## Custom application pool settings


The **eb migrate** command does not copy over custom application pool settings by default. To preserve custom application pool configurations, follow this procedure to create and apply a custom manifest section.

1. Create an archive of your migration artifacts.

   ```
   PS C:\migrations_workspace> eb migrate --archive
   ```

1. Create a custom PowerShell script to configure application pools.

   ```
   # PS C:\migrations_workspace> cat .\migrations\latest\upload_target\customize_application_pool_config.ps1
   
   $configPath = "$env:windir\System32\inetsrv\config\applicationHost.config"
   
   [xml]$config = Get-Content -Path $configPath
   
   $newPoolXml = @"
   <!-- Original IIS Configuration -->
   <applicationPools>
       <add name="CustomPool" 
            managedRuntimeVersion="v4.0" 
            managedPipelineMode="Integrated">
           <processModel identityType="SpecificUser" 
                        userName="AppPoolUser" 
                        password="[encrypted]" />
           <recycling>
               <periodicRestart time="00:00:00">
                   <schedule>
                       <add value="02:00:00" />
                       <add value="14:00:00" />
                   </schedule>
               </periodicRestart>
           </recycling>
       </add>
   </applicationPools>
   "@
   $newPoolXmlNode = [xml]$newPoolXml
   
   # Find the applicationPools section
   $applicationPools = $config.SelectSingleNode("//configuration/system.applicationHost/applicationPools")
   
   # Import the new node into the document
   $importedNode = $config.ImportNode($newPoolXmlNode.DocumentElement, $true)
   $applicationPools.AppendChild($importedNode)
   
   # Save the changes
   $config.Save($configPath)
   
   Write-Host "ApplicationHost.config has been updated successfully."
   ```

1. Update the `aws-windows-deployment-manifest.json` file to include your custom script.

   ```
   {
       "manifestVersion": 1,
       "deployments": {
           ...
           "custom": [
               ...,
               {
                   "name": "ModifyApplicationPoolConfig",
                   "description": "Modify application pool configuration from source machine to remove",
                   "scripts": {
                       "install": {
                           "file": "customize_application_pool_config.ps1"
                       },
                       "restart": {
                           "file": "ebmigrateScripts\\noop.ps1"
                       },
                       "uninstall": {
                           "file": "ebmigrateScripts\\noop.ps1"
                       }
                   }
               }
           ]
       }
   }
   ```

1. Create an environment with the updated archive directory.

   ```
   PS C:\migrations_workspace> eb migrate `
       --archive-dir '.\migrations\latest\upload_target\'
   ```

The `--archive-dir` argument tells **eb migrate** to use the source code that it previously created, avoiding the creation of new archives.

## Deploying previous versions


The **eb migrate** maintains a history of your migrations through timestamped directories and application versions in Elastic Beanstalk. Each migration creates a unique zip file that can be deployed if needed.

```
PS C:\migrations_workspace> ls .\migrations\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d----l        3/18/2025  10:34 PM                latest
d-----        3/16/2025   5:47 AM                migration_1742104049.479849
d-----        3/17/2025   9:18 PM                migration_1742246303.18056
d-----        3/17/2025   9:22 PM                migration_1742246546.565739
...
d-----        3/18/2025  10:34 PM                migration_1742337258.30742
```

The `latest` symbolic link always points to the most recently created migration artifact directory. In addition to relevant application and error logs, each migration artifact directory also contains a `upload_target.zip` file which you can deploy to Elastic Beanstalk.

```
PS C:\migrations_workspace> ls .\migrations\latest\

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        3/18/2025  10:34 PM                upload_target
-a----        3/18/2025  10:34 PM          13137 application.log
-a----        3/18/2025  10:34 PM              0 error.log
-a----        3/18/2025  10:34 PM        1650642 upload_target.zip
```

You can deploy the `upload_target.zip` file using **eb migrate**:

```
PS C:\migrations_workspace> eb migrate --zip .\migrations\latest\upload_target.zip
```

# Troubleshooting and diagnostics


**Try Amazon Q Developer CLI for AI-assisted troubleshooting**  
 Amazon Q Developer CLI can help you troubleshoot environment issues quickly. The Q CLI provides solutions by checking environment status, reviewing events, analyzing logs, and asking clarifying questions. For more information and detailed walkthroughs, see [Troubleshooting Elastic Beanstalk Environments with Amazon Q Developer CLI ](https://aws.amazon.com/blogs/devops/troubleshooting-elastic-beanstalk-environments-with-amazon-q-developer-cli/) in the AWS blogs.

This section provides guidance for troubleshooting common issues that may arise during the migration of IIS applications to Elastic Beanstalk.

## Associating an EC2 keypair with your environment


You can securely log in to the Amazon Elastic Compute Cloud(Amazon EC2) instances provisioned for your Elastic Beanstalk application with an Amazon EC2 key pair. For instructions on creating a key pair, see [Creating a Key Pair Using Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair) in the *Amazon EC2 User Guide*.

Specifying a keyname to **eb migrate** has the effect of associating your Elastic Beanstalk environment with the keypair. For security purposes, this will not open up port 3389 on your EC2 instances security group. You can associate additional EC2 security groups allowing traffic at port 3389 through **eb config** after the initial migration.

```
PS C:\migrations_workspace> eb migrate  `
    --keyname "my-keypair"  `
    --verbose
```

When you create a key pair, Amazon EC2 stores a copy of your public key. If you no longer need to use it to connect to any environment instances, you can delete it from Amazon EC2. For details, see [Deleting Your Key Pair](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#delete-key-pair) in the *Amazon EC2 User Guide*.

For more information about connecting to Windows Amazon EC2 instances, see [Connecting to Windows Instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html).

## Accessing logs


The EB CLI provides an **eb logs** facility which you can use to retrieve logs from an Elastic Beanstalk environment without logging into its EC2 instances. After an execution of **eb migrate**, you can issue the **eb logs --zip** command which will download and save logs into the `.elasticbeanstalk\logs` directory.

Alternatively, you can view logs through the AWS Elastic Beanstalk console. For more information, see [Viewing logs from Amazon EC2 instances in your Elastic Beanstalk environment](using-features.logging.md).

## Accessing client-side artifacts


The **eb migrate** command stores application and error logs generated by **msdeploy** inside migrations artifacts directories.

```
./migrations/
├── latest -> migration_20240308_123456/
└── migration_20240308_123456/
    ├── application.log
    ├── error.log
    └── upload_target\
```

## Monitoring environment health


Elastic Beanstalk helps you monitor health using the enhanced health monitoring capabilities. It is an automated health monitoring system that continuously tracks the operational status of application instances, leveraging built-in metrics such as CPU utilization, latency, request counts, and response codes.

The health monitoring system utilizes an agent-based approach to collect instance-level data and integrates with real-time logging and alerting. Elastic Load Balancing (ELB) and Auto Scaling dynamically respond to health status changes, ensuring high availability and fault tolerance. Advanced monitoring modes, including enhanced health reporting, provide granular visibility into application behavior, enabling proactive troubleshooting and automatic recovery mechanisms.

Run the EB CLI **eb health** command to display the environment's health. The following information displays:
+ Instance health status
+ Application response metrics
+ System resource utilization
+ Recent deployment events

## EC2 performance optimization


By default, **eb migrate** selects the [c5.2xlarge](https://aws.amazon.com/ec2/instance-types/c5/) instance type to provide an optimal first-time experience with Elastic Beanstalk. You can override this behavior with the **--instance-type** argument:

```
PS C:\migrations_workspace> eb migrate `
    --instance-type "t3.large"
```

For production environments, consider these factors when selecting an instance type:
+ Memory requirements of your applications
+ CPU requirements for processing workloads
+ Network performance needs
+ Cost optimization goals

## EBS volume configuration


By default, Elastic Beanstalk will create only a root block-device volume (`C:\`) for your environment. You can pass additional Amazon Elastic Block Store snapshot volumes with the **--ebs-snapshots** option:

```
PS C:\migrations_workspace> eb migrate `
    --ebs-snapshots "snap-123456789abc"
```

For examples of how you can configure block-device mappings with Elastic Beanstalk, see the blog article [ Customize Ephemeral and EBS Volumes in Elastic Beanstalk Environments](https://aws.amazon.com/blogs/devops/customize-ephemeral-and-ebs-volumes-in-elastic-beanstalk-environments/).

For applications with high storage requirements, consider the following options:
+ Using EBS volumes for persistent data
+ Implementing Amazon S3 for static content
+ Using Amazon FSx for Windows File Server for shared file systems

## Common issues and solutions


**Event:** *Missing Web Deploy installation*

If you encounter errors related to Web Deploy not being found, then install Web Deploy 3.6 or later from the [Microsoft Web Platform Installer](https://www.iis.net/downloads/microsoft/web-deploy). The following example displays a possible error message.

```
Couldn't find msdeploy.exe. Follow instructions here: https://learn.microsoft.com/en-us/iis/install/installing-publishing-technologies/installing-and-configuring-web-deploy
```

**Event:** *Permission issues during migration*

If you encounter permission-related errors, then ensure that you're running the EB CLI with administrative privileges. The following example displays a possible error message.

```
[ERROR] Access to the path 'C:\inetpub\wwwroot\web.config' is denied.
```

**Event:** *Application pool identity issues*

If your application fails to start due to application pool identity issues, create a custom script to configure application pool identities as shown in [Custom application pool settings](dotnet-migrating-applications-advanced-scenarios.md#dotnet-migrating-applications-advanced-scenarios-apppool).

**Event:** *SSL certificate configuration errors*

If HTTPS bindings fail to work, ensure that you've specified a valid ACM certificate ARN using the **eb mibrate** option `--ssl-certificates` parameter.

**Event:** *Environment creation timeout*

If environment creation times out, check CloudFormation events in the AWS Management Console for specific resource creation failures. Common causes include VPC configuration issues or service limits.

## Getting support


If you encounter issues that you cannot resolve, before contacting AWS Support gather the following information:
+ Environment ID (`eb status`)
+ Application logs (`eb logs --zip`)
+ Migration artifacts from `.\migrations\latest\`
+ Source IIS configuration (output of `eb migrate explore --verbose`)
+ Detailed error messages

For more information about Elastic Beanstalk troubleshooting, see [Troubleshooting your Elastic Beanstalk environment](troubleshooting.md).

# Comparing migration options: EB CLI vs. AWS Application Migration Service
Migration options: EB CLI vs. MGN

AWS offers multiple paths for migrating Windows applications to the cloud. This section compares two primary options: the **eb migrate** command in the EB CLI and AWS Application Migration Service (MGN). Understanding the differences between these approaches will help you choose the most appropriate migration strategy for your specific needs.


**Comparison of migration options**  

| Feature | EB CLI (**eb migrate**) | AWS Application Migration Service (MGN) | 
| --- | --- | --- | 
| Primary focus | Application-level migration of IIS websites and applications | Server-level rehosting of entire machines (physical, virtual, or cloud servers) | 
| Best suited for | IIS applications that you want to migrate directly to Elastic Beanstalk with minimal reconfiguration | Large-scale migrations involving many servers or complex infrastructure | 
| Discovery approach | Application-level discovery of IIS sites, applications, and configurations | Server-level replication of entire machines, including operating system and applications | 
| Target environment | Directly creates and configures Elastic Beanstalk environments optimized for Windows applications | Creates EC2 instances that require additional configuration to work with Elastic Beanstalk | 
| Configuration preservation | Automatically preserves IIS-specific configurations (sites, application pools, bindings) | Preserves entire server configuration, which may include unnecessary components | 
| Deployment model | Creates a clean Elastic Beanstalk environment with your applications deployed using Elastic Beanstalk best practices | Creates a replica of your source server that may require optimization for cloud operations | 
| Scale of migration | Ideal for targeted migrations of specific applications | Designed for large-scale migrations of many servers | 
| Post-migration steps | Minimal; environment is ready for use with Elastic Beanstalk management tools | Requires additional steps to integrate with Elastic Beanstalk, such as executing SSM post-launch actions | 

## When to use each migration option


**Choose **eb migrate** when you have the following requirements:**  
+ You want to migrate specific IIS applications rather than entire servers
+ Your goal is to adopt Elastic Beanstalk as your application management platform
+ You want to leverage Elastic Beanstalk's managed platform features like easy scaling, deployment, and monitoring
+ You prefer a clean deployment that follows AWS best practices for cloud-native operations
+ You want to minimize post-migration configuration work

**Choose AWS Application Migration Service when you have the following requirements:**  
+ You need to migrate a large number of servers
+ You have complex server configurations that must be preserved exactly
+ Your applications have compatibility issues that require maintaining the exact server environment
+ You want to "lift and shift" with minimal changes to your applications
+ You plan to refactor or optimize your applications after migration

## Migration workflow comparison


**EB CLI (**eb migrate**) workflow:**

1. Install the EB CLI on either your source IIS server or a bastion host.

1. Run **eb migrate** to discover IIS applications.

1. The command packages your applications and configurations.

1. An Elastic Beanstalk environment is created with appropriate resources.

1. Your applications are deployed to the new environment.

1. You can immediately manage your applications using Elastic Beanstalk tools.

**AWS Application Migration Service workflow:**

1. Install the AWS Replication Agent on source servers.

1. Configure and test data replication.

1. Launch test instances to verify functionality.

1. Schedule cutover to AWS.

1. Launch production instances.

1. Execute post-launch actions to optimize for cloud.

1. If Elastic Beanstalk is the target platform, additional configuration is required to integrate with Elastic Beanstalk.

## Conclusion


Elastic Beanstalk is the preferred destination for Windows platform applications on AWS, offering a managed environment that simplifies deployment, scaling, and management. The **eb migrate** command provides a direct path to Elastic Beanstalk for IIS applications, with automatic discovery and configuration that preserves your application settings.

While AWS Application Migration Service offers powerful capabilities for large-scale server migrations, it requires additional steps to integrate with Elastic Beanstalk. For most IIS application migrations where Elastic Beanstalk is the target platform, **eb migrate** offers a more streamlined approach that aligns with Elastic Beanstalk's managed service model.

Choose the migration approach that best fits your specific requirements, considering factors such as scale, complexity, and your desired end-state architecture on AWS.

For more information about AWS Application Migration Service, see [What is AWS Application Migration Service?](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html) in the AWS Application Migration Service User Guide.