On-Premise to Azure Migration Guide: SkyCore's Recommended Path

Step 1: Phase 1: Initial Setup and Azure Migrate Project Creation

The first critical step in any on-premise to Azure migration is to establish a dedicated environment within Azure. This involves creating a resource group to logically organize your migration assets and then provisioning an Azure Migrate project, which will serve as the centralized hub for all subsequent discovery, assessment, and migration activities.

# Create a new Azure Resource Group for your migration project
az group create `
    --name 'SkyCoreMigrationRG' `
    --location 'eastus'

# Create a new Azure Migrate project within the resource group
az migrate project create `
    --name 'SkyCoreMigrateProject' `
    --resource-group 'SkyCoreMigrationRG' `
    --location 'eastus'

--name: Specifies the unique name for the resource group or Azure Migrate project.

--location: Designates the Azure region where the resources will be deployed (e.g., 'eastus', 'westeurope').

--resource-group: Links the Azure Migrate project to the previously created resource group.

Portal alternative: Navigate to the Azure portal, search for 'Resource groups', click '+ Create', fill in details. Then search for 'Azure Migrate', click '+ Create project', and select your resource group.

Expected result: A new Azure resource group named 'SkyCoreMigrationRG' and an Azure Migrate project named 'SkyCoreMigrateProject' will be successfully provisioned in the 'eastus' region.

Step 2: Phase 2: Discovery and Business Case (Decide)

With the Azure Migrate project in place, the next phase focuses on understanding your existing on-premises environment. This involves discovering your server inventory, collecting performance data, and then using this data to build a compelling business case for moving to Azure. The recommended approach for discovery is to deploy a lightweight Azure Migrate appliance in your datacenter.

# Install Azure CLI extensions for Azure Migrate (if not already installed)
az extension add --name 'azure-migrate' --yes

# Create a discovery site for VMware (example)
# Note: Appliance deployment (OVF/VHD download) and registration are typically portal-driven or require
# running a script on-premises. The CLI is primarily for managing the Azure-side discovery aspects
# after the appliance is registered. This command sets up the 'Discovery site'.
az migrate vmware-migration create-project `
    --resource-group 'SkyCoreMigrationRG' `
    --name 'SkyCoreVMwareDiscovery' `
    --location 'eastus' `
    --assessment-project 'SkyCoreMigrateProject' `
    --storage-account 'skycoremigratestorage' # Replace with a valid, existing storage account

az extension add --name 'azure-migrate': Installs the necessary Azure CLI extension for Azure Migrate commands.

az migrate vmware-migration create-project: Initiates the creation of a VMware migration project which includes a discovery component. Use `hyperv-migration` or `physical-server-migration` as appropriate.

--assessment-project: Links the discovery to your central Azure Migrate project.

--storage-account: Specifies an Azure Storage account where discovery data will be stored temporarily. This must exist prior to running the command.

Portal alternative: From your Azure Migrate project, navigate to 'Servers, databases and web apps', click 'Discover' under 'Discovery and assessment', choose your server type (e.g., VMware vSphere), download the appliance OVF/VHD file, deploy it on-premises, and then register it with your Azure Migrate project using the provided project ID and key.

Expected result: The Azure Migrate appliance will collect configuration and performance data from your on-premises servers, continuously sending it to the Azure Migrate service. This data is then used within the Azure Migrate portal to generate a business case, providing insights into total cost of ownership (TCO) comparisons, resource utilization-based recommendations, and potential cost savings.

Step 3: Phase 3: Migration Planning and Readiness (Plan)

Once your environment is discovered and assessed, the planning phase focuses on tactical decisions: evaluating your team's readiness, choosing the optimal data migration path, and meticulously sequencing your workload migrations. This phase is crucial for minimizing risk and ensuring a smooth cutover.

Assess Migration Readiness and Skills

Evaluate your team's existing Azure skills and experience with migration tools. Identify any knowledge gaps that require targeted training or external support. SkyCore Solutions often recommends engaging external expertise, especially for complex or large-scale projects, to validate strategies and accelerate progress.

Choose Your Data Migration Path

Selecting the right data migration path is paramount for security, speed, and cost-effectiveness. Your choice will largely depend on available network connections, data volume, and sensitivity.

# Example: Create an Azure Virtual Network and VPN Gateway for secure data transfer
# This assumes you are opting for a VPN-based data transfer path.

# Create a Virtual Network (VNet)
az network vnet create `
    --resource-group 'SkyCoreMigrationRG' `
    --name 'SkyCoreMigrateVNet' `
    --address-prefix '10.0.0.0/16' `
    --location 'eastus'

# Create a GatewaySubnet within the VNet
az network vnet subnet create `
    --resource-group 'SkyCoreMigrationRG' `
    --vnet-name 'SkyCoreMigrateVNet' `
    --name 'GatewaySubnet' `
    --address-prefixes '10.0.1.0/24'

# Create a Public IP for the VPN Gateway
az network public-ip create `
    --resource-group 'SkyCoreMigrationRG' `
    --name 'SkyCoreVPNGatewayIP' `
    --allocation-method 'Dynamic' `
    --sku 'Standard'

# Create the VPN Gateway
# Note: This command can take 30-45 minutes to complete.
az network vnet-gateway create `
    --resource-group 'SkyCoreMigrationRG' `
    --name 'SkyCoreVPNGateway' `
    --location 'eastus' `
    --public-ip-address 'SkyCoreVPNGatewayIP' `
    --vnet 'SkyCoreMigrateVNet' `
    --gateway-type 'Vpn' `
    --vpn-type 'RouteBased' `
    --sku 'VpnGw1' `
    --no-wait # Allows the command to return immediately while the gateway deploys in the background

az network vnet create: Creates a virtual network in Azure to host your migrated resources.

az network vnet subnet create: Defines a dedicated subnet required for the VPN Gateway.

az network public-ip create: Provisions a public IP address for external connectivity to the VPN Gateway.

az network vnet-gateway create: Deploys the VPN Gateway, which will establish secure connectivity to your on-premises network.

Portal alternative: For network setup, navigate to 'Virtual networks' or 'Virtual network gateways' in the Azure portal and follow the wizard to create these resources. For Azure Data Box, search for 'Azure Data Box' and create an order.

Data Migration Path Options:

• ExpressRoute: Recommended for all workloads when available, offering private, dedicated, high-speed, and secure connections. Requires prior setup and has associated costs.
• VPN: A secure alternative when ExpressRoute isn't feasible. Creates an encrypted tunnel over the public internet, though typically slower than ExpressRoute. Requires an Azure VPN Gateway.
• Azure Data Box: Ideal for large-scale, offline migrations with massive data volumes. Microsoft ships you a physical device for data transfer, avoiding network bandwidth usage, but involving shipping time.
• Public Internet: Suitable only for less sensitive data when other options are unavailable. Least secure and can consume significant network bandwidth.

Determine the Migration Sequence

Organize your migration into logical waves, prioritizing workloads based on dependencies and business impact. Use the dependency mapping data collected during discovery to group interdependent applications and servers, ensuring they migrate together to prevent service disruptions.

Step 4: Phase 4: Replication and Test Migration

This phase involves the technical preparation of your on-premises machines and Azure environment for data synchronization. You'll set up continuous replication of your chosen workloads to Azure and then perform essential test migrations to validate the process without affecting your production environment.

# Install the Server Migration extension if not already present
az extension add --name 'server-migration' --yes

# Enable replication for an on-premises machine (example for VMware/physical server)
# Note: This command assumes the Azure Migrate appliance is already registered and discovered machines.
# The actual replication is initiated through the Azure Migrate project in the portal or by providing
# detailed replication properties not directly exposed in a simple 'start-replication' CLI for all scenarios.
# For a more realistic CLI, you'd be interacting with specific ASR replication components or
# using more complex 'az migrate server-migration' commands with JSON payloads for properties.
# As the reference points to the portal for general setup, a conceptual CLI is given.

# --- Conceptual CLI for enabling replication via Azure Migrate project ---
# This part is highly dependent on the type of server (VMware, Hyper-V, Physical) and
# the specific replication policy and target details.
# General approach:
# 1. Create a replication policy (if not already existing in the project)
# 2. Select machines to replicate
# 3. Configure replication settings (target VNet, subnet, disks, etc.)

# Example for creating a replication policy (placeholders)
# This would typically be a sub-command under 'az migrate' or 'az site-recovery'
# az migrate replication policy create \
#    --resource-group 'SkyCoreMigrationRG' \
#    --project-name 'SkyCoreMigrateProject' \
#    --name 'SkyCoreDefaultReplicationPolicy' \
#    --recovery-point-retention-in-days 7 \
#    --app-consistent-snapshot-frequency-in-hours 4

# After policy and target settings, you would enable replication for specific discovered machines.
# This often involves detailed JSON input for machine properties, disks, and network settings.
# For simplicity, we direct to the portal for initial setup of specific machine replication,
# as the CLI for this granular step can be extensive and vary greatly.

# Perform a test migration for a replicated server (using Azure Migrate Server Migration)
# Replace 'MyMigratedVM' with the actual name of your server configured for migration.
az migrate server-migration test-migrate `
    --resource-group 'SkyCoreMigrationRG' `
    --project-name 'SkyCoreMigrateProject' `
    --name 'MyMigratedVM' `
    --vnet 'SkyCoreMigrateVNet' `
    --subnet 'default' # Or a specific test subnet, e.g., 'SkyCoreTestSubnet'

az migrate server-migration test-migrate: Initiates a test migration of a specified server to Azure, creating a VM without impacting ongoing replication or the source on-premises machine.

--name: The name of the server migration item you want to test migrate.

--vnet: The target Azure Virtual Network for the test VM.

--subnet: The specific subnet within the target VNet for the test VM.

Portal alternative: Within your Azure Migrate project, under 'Servers, databases and web apps', navigate to 'Replicating servers'. Select the servers you wish to replicate, click 'Replicate', and follow the wizard to configure target settings. Once replication is healthy, select a server and click 'Test migration' to initiate a test failover.

Expected result: Your on-premises servers will begin continuous replication to Azure. A test migration will successfully provision a replica VM in Azure within an isolated network, allowing you to validate application functionality, connectivity, and performance without affecting your production environment. You should resolve any issues identified during the test migration before proceeding.

Step 5: Phase 5: Full Migration and Cutover

With successful test migrations validating your process, you are ready for the final cutover. This phase involves executing the full migration of your workloads, ensuring data consistency, validating operations in Azure, and finally, decommissioning the legacy on-premises resources.

# Perform a final synchronization and stop replication before cutover (recommended)
# This step ensures the latest data is transferred and then stops new changes from replicating.
az migrate server-migration stop-replication `
    --resource-group 'SkyCoreMigrationRG' `
    --project-name 'SkyCoreMigrateProject' `
    --name 'MyMigratedVM' `
    --replication-stop-type 'FinalSync' # Ensures a final sync is attempted

# Execute the full migration (cutover) for a replicated server
# This command powers off the on-premises machine, performs a final data sync,
# and creates the final Azure VM.
az migrate server-migration start-migration `
    --resource-group 'SkyCoreMigrationRG' `
    --project-name 'SkyCoreMigrateProject' `
    --name 'MyMigratedVM' `
    --target-resource-group 'SkyCoreTargetVMsRG' # Target RG for the final VM
    # Additional parameters like --target-vnet, --target-subnet, --target-disk-type etc.
    # might be required based on your specific setup and migration type.

az migrate server-migration stop-replication: Halts the continuous replication for a server, optionally performing a final data synchronization.

az migrate server-migration start-migration: Executes the final migration, powering off the source, performing a last data transfer, and creating the production Azure VM.

--replication-stop-type 'FinalSync': Specifies that a final synchronization should occur before stopping replication, ensuring minimal data loss.

--target-resource-group: The resource group in Azure where the final migrated VM will reside.

Portal alternative: From your Azure Migrate project, under 'Servers, databases and web apps', navigate to 'Replicating servers'. Select the server(s) you wish to migrate, click 'Migrate', confirm the shutdown of the on-premises machine, and complete the process. This will provision the final Azure VM.

Expected result: The specified on-premises workload will be successfully migrated to Azure. The source on-premises machine will be powered off (or marked for decommissioning), and a fully functional production VM will be running in Azure. You should perform comprehensive post-migration validation to ensure all applications and services operate as expected within the Azure environment.

Step 6: Phase 6: Post-Migration Optimization and Security Hardening

Migration is not the final step; optimizing your Azure resources for cost and performance, and implementing robust security hardening, are crucial for realizing the full benefits of the cloud. This phase focuses on refining your Azure footprint and fortifying your defenses.

Cost and Performance Optimization

Review your migrated VMs and services for rightsizing, leveraging Azure Advisor recommendations, and exploring cost-saving features like Reserved Instances or Azure Hybrid Benefit.

# Resize an Azure VM to optimize cost or performance
# Identify VMs based on performance metrics (CPU, RAM usage) from Azure Monitor.
az vm resize `
    --resource-group 'SkyCoreTargetVMsRG' `
    --name 'MyMigratedVM' `
    --size 'Standard_D2s_v4' # Example new VM size (e.g., from Standard_D4s_v3 to D2s_v4)

# Enable Azure Hybrid Benefit for a VM (if eligible with Windows Server/SQL Server licenses)
az vm update `
    --resource-group 'SkyCoreTargetVMsRG' `
    --name 'MyMigratedVM' `
    --set licenseType='Windows_Server' # Or 'Windows_Server_and_SQL_Server'

az vm resize: Changes the VM size (SKU) to a more appropriate one based on actual workload demands.

--size: The new VM size to apply (e.g., 'Standard_D2s_v4').

az vm update --set licenseType='Windows_Server': Configures the VM to utilize Azure Hybrid Benefit, reducing compute costs.

Security Hardening

Implement a layered security approach using Azure Security Center, Network Security Groups (NSGs), Azure Key Vault, and identity management best practices.

# Create a Network Security Group (NSG) for a specific subnet or VM
az network nsg create `
    --resource-group 'SkyCoreTargetVMsRG' `
    --name 'SkyCoreWebNSG' `
    --location 'eastus'

# Add an inbound rule to allow HTTPS (port 443) traffic to the NSG
az network nsg rule create `
    --resource-group 'SkyCoreTargetVMsRG' `
    --nsg-name 'SkyCoreWebNSG' `
    --name 'AllowHttpsInbound' `
    --priority 100 `
    --direction 'Inbound' `
    --access 'Allow' `
    --protocol 'Tcp' `
    --source-port-ranges '*' `
    --destination-port-ranges 443 `
    --source-address-prefixes 'Internet' `
    --destination-address-prefixes '*'

# Associate the NSG with a Subnet (recommended) or a specific Network Interface
az network vnet subnet update `
    --resource-group 'SkyCoreTargetVMsRG' `
    --vnet-name 'SkyCoreMigrateVNet' `
    --name 'default' `
    --network-security-group 'SkyCoreWebNSG'

# Enable Azure Defender for Servers (via Azure Security Center)
# This is typically configured at the subscription level via the portal or policy.
# Conceptual command to enable for a subscription:
# az security auto-provisioning-setting update --name 'default' --auto-provision 'On'

az network nsg create: Provisions a network security group to filter network traffic to and from Azure resources.

az network nsg rule create: Defines a specific rule within an NSG, such as allowing inbound HTTPS.

--priority: Determines the order in which rules are processed (lower numbers are processed first).

--source-address-prefixes 'Internet': Specifies that traffic from any external IP address is allowed.

az network vnet subnet update: Associates an NSG with an entire subnet, applying its rules to all resources within that subnet.

Portal alternative: For VM resizing, navigate to the VM's blade, select 'Size' under 'Settings'. For NSG management, search for 'Network security groups', create/configure rules, and associate them with subnets or NICs. For security posture, visit 'Azure Security Center' (now Microsoft Defender for Cloud) to enable enhanced security features and review recommendations.

Expected result: Your Azure resources are now right-sized for efficiency, leveraging cost-saving programs, and protected by a robust set of security controls, including network segmentation and threat detection capabilities, aligning with SkyCore's best practices for cloud governance and security.