9.2 Requirements for Migrating Workloads to Azure

Based on the location of your PlateSpin Migrate server, review the following sections for information about the requirements for migrating workloads to Azure Cloud and Azure-connected Azure Stack environments. For information about Azure-connected Azure Stack environments, see Azure Stack documentation.

9.2.1 Minimum Azure Prerequisites

PlateSpin Migrate requires the use of Microsoft Azure Resource Management for migrating workloads to the Microsoft Azure environments. For migrations to Microsoft Azure, you must prepare your Azure account, subscriptions, and services in the desired Azure environment.

Table 9-1 describes the minimum configuration you must perform in the appropriate Azure environment before you can migrate workloads to Azure.

Table 9-1 Minimum Required Configuration for Your Azure Account

Azure Configuration

Description

Microsoft Azure Account

Use the appropriate Azure portal to create an account in the Azure environment where you will migrate workloads.

An administrator on the account is required to perform the Application setup, to enable PRE programmatic access, and to create a Contributor user that is to be used by Migrate.

Azure Subscription ID

The ID for the Azure Subscription in the specified Azure account that you want to bill for Azure-related costs for migrations using PlateSpin Migrate. An account can have multiple subscriptions.

You must provide the Subscription ID when you add a Microsoft Azure Location as a migration target in PlateSpin Migrate.

To view a Subscription ID, log in to the Azure portal with your Azure user account that you use to manage your subscriptions, then go to the Subscriptions page and select the subscription.

Contributor user for the subscription created in Azure Active Directory

A special-purpose user identity for PlateSpin Migrate that you create in Azure Active Directory. You add a Contributor role to the user account for the specified subscription. Using this Contributor user only for Migrate helps to uniquely identify actions performed by Migrate in Azure for the subscription.

In Migrate, you use the Contributor user credentials to add Azure as a target platform. Migrate uses the credentials for this user when it accesses the Migrate Azure API through the related subscription.

See Configuring a Contributor User for PlateSpin Migrate to Use.

Application (client) ID

An ID that represents PlateSpin Migrate as it makes use of the Microsoft Azure API when it replicates or migrates workloads on your behalf to VMs in a target Azure location for a subscription in your Azure account.

See Configuring an Application in Azure to Represent PlateSpin Migrate.

NOTE:For migrations to Azure Stack, you must not create an Azure application ID for PlateSpin Migrate. Instead, use the following ID as the Azure application ID for PlateSpin Migrate:

872cd9fa-d31f-45e0-9eab-6e460a02d1f1

Azure Virtual Network and Subnet

You must create least one Virtual Network with a Subnet in the specified Subscription. If you have an site-to-site VPN set up, the subnet must be different than the default Gateway Subnet.

Network resources are never created automatically by PlateSpin Migrate, so they always must be set up manually in advance. For instructions, refer to Azure documentation.

Azure Storage Account

For each target VM, PlateSpin Migrate supports using Azure Managed Disks or using Azure Storage Accounts and unmanaged disks. The setting applies at the VM level.

NOTE:At least one Azure storage account is required when you use unmanaged disks. Managed Disks do not require a storage account.

See Prerequisites for Azure Storage.

Azure Availability Sets

PlateSpin Migrate supports using pre-defined Azure Availability Sets for target VMs. See Prerequisites for Using Azure Availability Sets.

Azure tags

PlateSpin Migrate provides the ability to define tags for migrations to Azure that it applies to objects it creates in the target Azure subscription. See Using Azure Cloud Tags for Azure Migrations.

9.2.2 Prerequisites for Azure Storage

For each target VM, PlateSpin Migrate supports using Azure Managed Disks or using Azure Storage Accounts and unmanaged disks.

Azure Managed Disks

Azure Managed Disks is an Azure service that provides replicas of your data to help ensure persistence of your data and high tolerance against failures. Azure automatically creates and manages the placement of the disks in the target Azure location. You do not need to specify a storage account or location in a storage account. The specified Cloud Instance Size for the target VM determines how many data disks you can attach to the VM and the type of storage you can use to host the managed disks. The Azure Managed Disks setting applies to all disks for the target VM.

Using Azure Managed Disks is optional. It is enabled by default in keeping with Azure default VM settings.

NOTE:

  • To verify the availability in the target Azure location of Managed Disks service, refer to the Microsoft Azure Products Available by Region.

  • For information about disk types, sizes, and performance characteristics for Azure Manage Disks, refer to Introduction to Azure Managed Disks in Microsoft Azure Documentation.

  • Azure automatically and transparently provides Azure Storage Service Encryption for all storage, including Azure Managed Disks.

  • PlateSpin Migrate does not support configuration of Azure Disk Encryption for the target workload.

    Azure Disk Encryption provides OS-based encryption for OS and data volumes at rest by using BitLocker for Windows VMs or DM-Crypt for Linux VMs. After the cutover is complete, you can use Azure tools to enable Azure Disk Encryption for the cutover workload.

When you configure migrations to Azure, specify one of the following storage types for hosting the managed disks for the target VM:

  • Standard HDD (hard disk drives)

  • Standard SSD (solid state drives)

    NOTE:Standard SSD option is not applicable for migrations to Azure Stack.

  • Premium SSD

A storage type of Standard HDD allows you to choose VMs with HDD or SDD storage, whereas Standard SSD and Premium SSD are restricted to VMs that support the appropriate level of SSD storage. For information about disk performance characteristics, refer to What Disk Types Are Available in Azure? in the Microsoft Azure Documentation.

You can use Azure Managed Disks in combination with a predefined Azure Availability Set that has been configured to use managed disks.

Azure Storage Accounts and Unmanaged Disks

If you do not use Managed Disks for a VM, the VM disks are unmanaged by the Azure Managed Disks server. The VM disks will use the Azure page blob type of general-purpose storage, which can run on HDD (Standard) or SSD (Premium) storage media. You can use Azure General Purpose Storage V1 or V2, according to your needs.

If you plan to use unmanaged disks, you must create at least one Azure Storage account in the specified Subscription for the target Azure platform. For information about Azure Storage Accounts, refer to Introduction to Azure Storage in Microsoft Azure documentation.

NOTE:A Standard Storage Account can be used for Azure VM sizes that use HDD or SDD storage media. A Premium Storage Account can be used only for Azure VM sizes that use SDD storage media.

If no Azure Storage Account is associated with a subscription, PlateSpin Migrate sets up a Standard general-purpose storage account to use as the datastore for the target VM. The datastore name is based on the Azure Resource Group for the Subscription.

For information, see Azure Page Blobs (unmanaged disks) in Microsoft Azure Documentation.

9.2.3 Prerequisites for Using Azure Availability Sets

An Azure Availability Set is an Azure service that provides high availability to two or more member VMs by deploying them in different fault domains and update domains. Fault domains ensure that the VMs run on different host servers, compute racks, storage units, and network switches. Update domains ensure that maintenance outages for host hardware do not occur at the same time.

NOTE:VMs must be created in the Availability Set. You cannot add an existing VM to an Availability Set.

Using Azure Availability Sets is optional. No availability set is configured by default for the target VM, even if the selected Resource Group includes availability sets.

PlateSpin Migrate supports using pre-defined Azure Availability Sets for target VMs. You cannot create Availability Sets in Migrate.

Before you configure workloads for the target VMs that you want to add to an Availability Set:

  • Use the Azure portal to create and define the Availability Set in a resource group for the specified target location.

  • You can use an Availability Set in combination with Azure Managed Disks only if you enable the Use Managed Disks option in the Availability Set definition.

When the first VM is created in the Availability Set, Azure selects the physical hardware that will be used in the target Azure location. Thereafter, Azure limits the cloud instance sizes and networks that can be used for future member VMs accordingly.

NOTE:If you have multiple VMs configured for the same empty Availability Set, the first cutover VM determines the Azure limits based on the configuration characteristics of that VM. PlateSpin Migrate might prompt you to choose different cloud instance sizes or networks after the Azure limitations are enacted.

9.2.4 Prerequisites for Installing Azure VM Agent

PlateSpin Migrate provides the ability to automatically install Microsoft Azure Virtual Machine Agent on target Windows and Linux workloads at cutover and test cutover. The minimum requirements for the source workloads are:

  • Windows: Microsoft Azure supports Azure VM Agent only for workloads running Windows Server 2008 R2 and higher.

  • Linux: Before you add the source Linux workload to Migrate, ensure that it meets the following requirements:

    • PlateSpin Migrate requires Python 2.7 or higher to be installed on the source workload.

    • The source Linux workload must also meet minimum Azure Linux Agent requirements and system dependencies. See Understanding and Using the Azure Linux Agent in the Microsoft Azure Documentation.

9.2.5 Azure Prerequisites for Using an On-Premise Migrate Server

If you set up an Azure site-to-site VPN (or an Azure Express Route connection) between the premises where your source workloads reside and the target Azure environment, you can deploy your PlateSpin Migrate server on-premises. Before you use PlateSpin Migrate to migrate workloads to Microsoft Azure, ensure that the following cloud access prerequisites are correctly configured and available:

Table 9-2 Port Requirements for Migrate Server on Premise

Location

Port

Protocol

Remarks

On-premise source workload

Cloud-based target workload

TCP 443, outbound

HTTPS

The on-premise source workload and the cloud-based target workload must be able to communicate with the PlateSpin Migrate server through HTTPS (TCP/port 443) over the site-to-site VPN connection.

On-premise Migrate Server

TCP 443, outbound

HTTPS

The on-premise PlateSpin Migrate server must be able to communicate with the Microsoft Azure API endpoint.

On-premise source workloads

TCP 22

TCP 135, 445

UDP 135, 138 and TCP 39

SSH (Linux)

WMI/RPC/DCCOM

NetBIOS

The PlateSpin Migrate server must be able to communicate with the source workloads on the ports that are used for discovery. See Requirements for Discovery and Discovering Details for Source Workloads.

On-premise source workloads using Migrate Agent

TCP 22

TCP 443

SSH (Linux)

HTTPS

Instead of discovery, you can use the Migrate Agent utility to register source workloads with the Migrate server. See Requirements for Workload Registration and Registering Workloads and Discovering Details with Migrate Agent.

On-premise source workload

Cloud-based target workload

TCP 3725

Migrate

The cloud-based target workload must be able to communicate (target to source) with the on-premise source workload across the VPN. The source workload must be able to send data to the target workload during replication across the VPN.

The port number is configurable. See port 3725 in Requirements for Migration.

If you use Migrate Agent for registration and discovery, the default direction of the replication connection must be reversed (source to target) by changing advanced settings on the Migrate server. See Configuring the Contact Direction for the Replication Port.

Network Security Group in Azure for the cloud-based target workloads

TCP 443, inbound

TCP 3389, inbound

TCP 22, inbound

HTTPS

RDP (Windows)

SSH (Linux)

Allow inbound connections in the Network Security Group for the cloud-based target workloads.

For information about creating and configuring a Network Security Group in Azure, refer to Create, Change, or Delete a Network Security Group in Microsoft Azure Documentation.

9.2.6 Azure Prerequisites for Using an Azure-Based Migrate Server

Before you use PlateSpin Migrate to migrate workloads to Microsoft Azure, ensure that the following cloud access prerequisites are correctly configured and available:

  • A PlateSpin Migrate license.

  • Deploy an Azure Marketplace image of the PlateSpin Migrate server in the target Azure environment. See Deploying PlateSpin Migrate Server in the Cloud in the PlateSpin Migrate 2020.2 Installation and Upgrade Guide.

    NOTE:The cloud-based Migrate server does not require a site-to-site VPN connection between your local data center and Microsoft Azure Portal. When no VPN is provided between the source network and the cloud-based Migrate server, you can use Migrate Agent to register workloads with the cloud-based Migrate server using secure communications over the public Internet. Internet access and public IP addresses are required. For deployment information, see Figure 8-2, Cloud-Based Migrate Server for Automated Migration to AWS.

  • Specify Static as the allocation method for the public IP address of the Migrate server to ensure that the IP address does not change when the server is restarted.

    NOTE:A change in IP address on the PlateSpin Server breaks the heartbeat communications with source workloads.

    You cannot specify the actual IP address assigned to the public IP resource. Azure allocates and reserves an IP address from a pool of its available IP addresses in the Azure location where you deploy the Migrate server. The address persists through server restarts. Azure releases the IP address only when you delete the resource or change the resource’s allocation method to Dynamic.

  • Install the Migrate Agent on the source workload, then register the workload with the cloud-based PlateSpin Migrate server. See Registering Workloads and Discovering Details with Migrate Agent.

    To download the Migrate Agent, launch the PlateSpin Migrate Web Interface and click the Downloads tab. For information about installing and using the Migrate Agent, see Migrate Agent Utility.

  • The minimum network-related prerequisites for a successful migration when the Migrate Server is in Azure are described in Table 9-3.

Table 9-3 Port Requirements for Migrate Server in Azure

Location

Port

Protocol

Remarks

Source workload

Network firewall

TCP 443, outbound

HTTPS

Required to allow the source workload to register (using the Migrate Agent utility) and communicate with the cloud-based PlateSpin Migrate server. The PlateSpin Migrate Server uses secure SSL for communications with the workloads you want to migrate.

Source workload

Network firewall

Network Security Group (NSG) in Azure

TCP 3725, outbound

Migrate

Required to allow communications with the target machine and to transfer data from the source to the target during replication.

The direction of the communication (source to target) is automatic, but the port number is configurable. For information about changing the default port setting, see port 3725 in Requirements for Migration.

For information about creating and configuring a Network Security Group in Azure, refer to Create, Change, or Delete a Network Security Group in Microsoft Azure Documentation.

NSG in Azure for the Migrate Server

TCP 443, inbound

TCP 3389, inbound

HTTPS

RDP

Allow inbound connections in the Network Security Group for the cloud-based Migrate server.

The <Migrate-server-name>-nsg is created automatically when you deploy the Migrate server in Azure.

NSG in Azure for the Migrate Server

TCP 123, outbound

Network Time Protocol (NTP)

Add this port setting to the security group if you are using an NTP service outside the virtual network where you deploy the Migrate server.

NSG in Azure for the Migrate Server

TCP 22, outbound

SSH

This port allows outbound communications from the Migrate server to Linux workloads.