Definitive On-Premise to Azure Migration Guide by SkyCore Solutions

Step 1: Understanding Your Migration Journey with Azure

Embarking on an on-premise to Azure migration is a strategic move, not just a technical lift-and-shift. SkyCore Solutions champions a phased approach, beginning with a thorough understanding of Azure's capabilities and how they align with your business objectives. Microsoft explicitly recommends using the Azure Migrate service for server migration, purpose-built for its centralized hub capabilities covering discovery, assessment, and migration. Azure Site Recovery, while excellent for disaster recovery, is not the primary tool for a planned migration. Azure Migrate offers a unified platform for diverse workloads, including servers, databases, web applications, and large-scale data transfers using Azure Data Box, all as a free service for assessment and orchestration.

The migration journey through Azure Migrate is typically broken down into distinct phases:

1. Decide: Discovering your workloads, assessing readiness, and building a business case.
2. Plan: Strategizing the migration, defining dependencies, and choosing data transfer paths.
3. Migrate: Executing the replication and cutover of workloads.
4. Optimize & Modernize: Enhancing post-migration performance, security, and cost efficiency.

SkyCore's approach emphasizes meticulous planning and leveraging Azure Migrate's comprehensive features at each stage to minimize downtime, reduce risk, and maximize cloud benefits.

Step 2: Phase 1: Discovery and Assessment (The 'Decide' Stage)

The initial and most critical phase of your on-premise to Azure migration involves comprehensive discovery and assessment. This 'Decide' stage is where you identify your workloads, evaluate their Azure readiness, and build a robust business case. Azure Migrate streamlines this by providing a unified platform to catalog your environment, analyze performance, and estimate costs.

2.1 Create an Azure Migrate Project

First, you need to set up an Azure Migrate project, which serves as the central repository for your migration efforts.

az resource create `
    --resource-group 'SkyCoreMigrationRG' `
    --name 'SkyCoreMigrateProject' `
    --location 'EastUS' `
    --resource-type 'Microsoft.Migrate/MigrateProjects'

--resource-group: Specifies the name of the resource group where the Azure Migrate project will reside.

--name: Sets the unique name for your Azure Migrate project.

--location: Defines the Azure region for the Migrate project. Note that this doesn't dictate the target region for your migrated VMs.

--resource-type: Identifies the type of Azure resource being created, in this case, an Azure Migrate project.

Portal alternative: Navigate to the Azure portal, search for 'Azure Migrate', click 'Create project', and fill in the details for subscription, resource group, project name, and geography.

Expected result: An Azure Migrate project successfully provisioned in your specified resource group and region.

2.2 Deploy the Azure Migrate Appliance for Discovery

To discover your on-premises servers, you deploy a lightweight Azure Migrate appliance. This virtual appliance collects configuration and performance data from your environment and securely sends it to your Azure Migrate project.

The deployment process typically involves downloading a virtual appliance template (OVA for VMware, VHD for Hyper-V) from the Azure Migrate project and deploying it on a host in your datacenter. While the appliance deployment itself is an on-premises step, the subsequent connection and configuration are managed within Azure Migrate.

# These commands represent post-appliance deployment actions,
# as the appliance deployment itself is an on-premises VM setup.

# Example: Registering the appliance (conceptual - actual registration is guided in portal/appliance UI)
# After deploying and configuring the appliance on-premises, it registers with the Azure Migrate project.
# Discovery starts automatically once the appliance is configured with vCenter/Hyper-V credentials.

# For assessing a discovered server's readiness (no direct CLI to trigger assessment on an individual server,
# but the assessment itself is performed within the Azure Migrate project after discovery is complete).
# The assessment analyzes compatibility, sizing, and cost estimates.

Common pitfall: Underestimating the importance of credential management. Ensure the Azure Migrate appliance has appropriate read-only access to your virtualization environment (vCenter, Hyper-V) or physical servers to perform thorough discovery without disruption. Incorrect credentials will halt discovery.

2.3 Perform Assessments and Business Case Analysis

Once discovery is complete, Azure Migrate allows you to perform detailed assessments. These assessments help identify the best migration path (IaaS vs. PaaS), estimate Azure costs, and determine performance requirements.

Azure Migrate's assessment capabilities, augmented by the Azure Copilot migration agent (in preview), provide a conversational interface to explore discovered inventory, assess readiness, compare strategies, review business case insights, and even generate customized landing zone templates. This analytical power is crucial for the 'Decide' phase.

The business case analysis helps you compare the total cost of ownership (TCO) of on-premises versus Azure, evaluate cash flows, and understand the long-term cost reduction by shifting from CapEx to OpEx.

Portal alternative: Within your Azure Migrate project, navigate to 'Servers, databases and web apps' -> 'Discover' or 'Assess'. Follow prompts to create new assessment, selecting discovery source, target region, pricing tier, and other parameters.

Expected result: Detailed reports on server readiness, suggested Azure VM SKUs, estimated monthly costs, and potential savings generated within your Azure Migrate project.

Step 3: Phase 2: Strategic Planning (The 'Plan' Stage)

With your discovery and assessment complete, the 'Plan' stage translates high-level migration strategies into actionable deployment sequences. This phase is critical for minimizing risk and ensuring a smooth transition to Azure. SkyCore emphasizes readiness, network design, data transfer methods, and meticulous dependency mapping.

3.1 Assess Migration Readiness and Skills

Before proceeding, evaluate your team's Azure skills and experience with migration tools. Identify any knowledge gaps that need to be addressed through targeted training or, as SkyCore often recommends, engaging external expertise from Microsoft or a Microsoft partner. This ensures your team is equipped, or supplemented, to execute the plan effectively.

3.2 Choose Your Data Migration Path

Selecting the right data migration path is paramount for secure, fast, and cost-effective data transfer. Your choice depends on network availability, data volume, and security requirements.

ExpressRoute for High-Performance and Secure Transfers

ExpressRoute offers a private, dedicated connection to Azure, ideal for all workloads requiring high bandwidth and security.

# ExpressRoute setup is complex and typically involves telecom providers.
# No direct CLI command for its full provisioning as it's a hybrid infrastructure setup.
# You would interact with existing ExpressRoute circuits.
# Example: List ExpressRoute circuits
az network express-route list `
    --resource-group 'SkyCoreNetworkRG'

--resource-group: The resource group containing your ExpressRoute circuit.

Portal alternative: Search for 'ExpressRoute circuits' in the Azure portal to manage existing circuits or provision new ones.

VPN for Secure Internet-based Transfers

When ExpressRoute isn't available, a VPN Gateway creates an encrypted tunnel over the internet to Azure, suitable for secure data transfer, though typically slower than ExpressRoute.

# Create a Virtual Network
az network vnet create `
    --resource-group 'SkyCoreNetworkRG' `
    --name 'SkyCoreVNet' `
    --address-prefix '10.0.0.0/16' `
    --location 'EastUS'

# Create a Public IP for the VPN Gateway
az network public-ip create `
    --resource-group 'SkyCoreNetworkRG' `
    --name 'SkyCoreVpnGatewayPIP' `
    --location 'EastUS' `
    --allocation-method 'Dynamic'

# Create the VPN Gateway
az network vnet-gateway create `
    --resource-group 'SkyCoreNetworkRG' `
    --name 'SkyCoreVpnGateway' `
    --location 'EastUS' `
    --vnet 'SkyCoreVNet' `
    --gateway-type 'Vpn' `
    --sku 'VpnGw1' `
    --vpn-type 'RouteBased' `
    --public-ip-address 'SkyCoreVpnGatewayPIP'

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

--address-prefix: Defines the IP address range for the VNet.

az network public-ip create: Creates a public IP address resource for the VPN Gateway.

--allocation-method: Specifies how the IP address is allocated (Dynamic or Static).

az network vnet-gateway create: Provisions the Azure VPN Gateway.

--vnet: The virtual network to which the gateway will be connected.

--gateway-type: Specifies 'Vpn' for a VPN Gateway.

--sku: The SKU of the VPN Gateway (e.g., VpnGw1, VpnGw2, etc., impacting performance and features).

--vpn-type: Defines the VPN type, typically 'RouteBased' for most scenarios.

--public-ip-address: The public IP resource associated with the gateway.

Portal alternative: Navigate to 'Virtual network gateways' in the Azure portal, click 'Create', and provide the necessary details for the VNet, public IP, and gateway settings.

Expected result: A fully provisioned Azure VPN Gateway ready for on-premises connectivity.

Azure Data Box for Large Offline Transfers

For large volumes of data (terabytes to petabytes), Azure Data Box products offer an offline migration solution. Microsoft ships a physical device to you, you copy your data, and then ship it back. This bypasses network constraints but is the slowest method due to shipping time.

# Azure Data Box orders are typically managed through the Azure portal.
# There is no direct CLI command to "order" a Data Box physically.
# You interact with the Data Box resource once it's created for its details.
# Example: List Data Box orders
az databox job list `
    --resource-group 'SkyCoreDataBoxRG'

--resource-group: The resource group containing your Data Box orders.

Portal alternative: Search for 'Azure Data Box' in the Azure portal to create and manage orders.

Public Internet for Non-Sensitive Data

This option is feasible for less sensitive data when other secure methods are unavailable. It uses your existing internet bandwidth and is the least secure, potentially impacting other network activities.

Portal alternative: This method primarily involves direct uploads or syncing through tools configured to use public endpoints, managed within the respective Azure services.

3.3 Determine the Migration Sequence and Dependencies

Organizing your migration into logical waves and meticulously mapping dependencies are critical to reduce risk and prevent service disruptions. Dependencies between workloads must be discovered and addressed. Azure Migrate's discovery phase helps with this, providing insights into connected components.

SkyCore recommends a phased migration, starting with less critical workloads to build confidence and refine processes. Analyze direct dependencies (requiring immediate communication and low latency) and ensure they are migrated together or connectivity is maintained.

Common pitfall: Neglecting comprehensive dependency mapping. Failing to identify all internal and external dependencies between applications and databases is a leading cause of post-migration outages. Use tools during the discovery phase to visualize these connections and plan migration groups accordingly.

Step 4: Phase 3: Migration Execution (The 'Migrate' Stage)

This phase is where your strategic planning comes to fruition, moving your on-premises workloads into Azure. As established, SkyCore Solutions strongly advocates for Azure Migrate for planned migrations over Azure Site Recovery (which is for disaster recovery). Azure Migrate provides specific tools for migrating VMware VMs, Hyper-V VMs, and physical servers.

While the Azure Migrate service orchestrates the migration, the actual replication and cutover processes are typically initiated and monitored through the Azure portal and the Azure Migrate appliance. Direct granular CLI commands for "starting replication of VM X" are generally integrated into the appliance's workflow or higher-level Azure Migrate portal actions rather than being exposed as individual `az migrate vm replicate` commands. However, we can use CLI to prepare the Azure environment for receiving these migrated workloads.

4.1 Prepare Azure for Migration

Before initiating replication, ensure your target Azure environment is configured to host the migrated workloads. This includes setting up resource groups, virtual networks, subnets, network security groups (NSGs), and storage accounts.

# Create a Resource Group for migrated VMs
az group create `
    --name 'SkyCoreMigratedVMsRG' `
    --location 'EastUS'

# Create a Virtual Network for migrated VMs (if not already created in Plan phase)
az network vnet create `
    --resource-group 'SkyCoreMigratedVMsRG' `
    --name 'SkyCoreMigratedVNet' `
    --address-prefix '10.1.0.0/16' `
    --location 'EastUS'

# Create a Subnet within the VNet
az network vnet subnet create `
    --resource-group 'SkyCoreMigratedVMsRG' `
    --vnet-name 'SkyCoreMigratedVNet' `
    --name 'AppSubnet' `
    --address-prefixes '10.1.1.0/24'

# Create a Network Security Group for VM network isolation
az network nsg create `
    --resource-group 'SkyCoreMigratedVMsRG' `
    --name 'SkyCoreMigratedNSG' `
    --location 'EastUS'

# Create a Storage Account for boot diagnostics and potential temporary replication artifacts
az storage account create `
    --resource-group 'SkyCoreMigratedVMsRG' `
    --name 'skycoremigratestorage' `
    --location 'EastUS' `
    --sku 'Standard_LRS' `
    --kind 'StorageV2'

az group create: Creates a new resource group to logically organize your migrated resources.

az network vnet create: Establishes a virtual network, providing isolated network space for your Azure VMs.

--address-prefix: The CIDR block for the VNet.

az network vnet subnet create: Divides the VNet into smaller subnets for better organization and security.

--vnet-name: The name of the virtual network to which the subnet belongs.

--address-prefixes: The CIDR block for the subnet.

az network nsg create: Provisions a Network Security Group to control inbound and outbound traffic to Azure VMs.

az storage account create: Creates a general-purpose storage account required for various VM operations, including boot diagnostics and potentially during replication.

--sku: The performance tier and replication type (e.g., Standard_LRS for locally redundant storage).

--kind: The type of storage account (e.g., StorageV2 for general purpose v2).

Portal alternative: Search for and create each resource type (Resource Group, Virtual Network, Network Security Group, Storage Account) directly in the Azure portal, configuring their properties through the GUI.

Expected result: A secure and properly segmented Azure environment ready to receive your migrated on-premises workloads.

4.2 Enable Replication and Perform Test Migrations

Once your Azure environment is ready and your Azure Migrate project has discovered your servers, you can initiate replication using the Azure Migrate migration tools. For VMware VMs, you can choose between agentless or agent-based migration. Hyper-V VMs and physical servers typically use agent-based methods. This step will configure your on-premises servers to continuously replicate their data to Azure storage.

The crucial next step is to perform a test migration. This creates a replica of your on-premises server in Azure without impacting your production environment. Test migrations allow you to validate application functionality, network connectivity, and performance in Azure. This is a non-negotiable step that SkyCore Solutions insists on for every migration.

Because the specifics of enabling replication are highly dependent on the type of source machine (VMware, Hyper-V, Physical) and are primarily orchestrated via the Azure Migrate portal and the on-premises appliance, direct universal CLI commands for this are not provided in the reference documentation for Azure Migrate itself.

# The initiation of replication and test migration is performed via the Azure Migrate portal
# after the appliance has discovered your servers.
# There are no direct az migrate commands for individual VM replication/test-failover
# in the high-level documentation provided.

# Conceptual step: Trigger replication for a discovered VM group via Azure Migrate tool
# Example: (This is a conceptual representation, not an actual Azure CLI command)
# az migrate server-migration start-replication `
#    --project-name 'SkyCoreMigrateProject' `
#    --resource-group 'SkyCoreMigrationRG' `
#    --source-vm-name 'OnPremWebServer01' `
#    --target-vnet 'SkyCoreMigratedVNet' `
#    --target-subnet 'AppSubnet'

# Conceptual step: Trigger a test migration (test failover)
# az migrate server-migration test-failover `
#    --project-name 'SkyCoreMigrateProject' `
#    --resource-group 'SkyCoreMigrationRG' `
#    --migration-item-name 'OnPremWebServer01-MigrateItem'

Portal alternative: In your Azure Migrate project, navigate to 'Servers, databases and web apps' -> 'Replicate'. Select the machines to replicate, configure target settings (VNet, subnet, NSG, storage), and start replication. Once replication is healthy, select the replicated machines and click 'Test migration'.

Expected result: On-premises servers continuously replicating data to Azure. Successful completion of test migrations, validating application functionality in the Azure environment without affecting production.

4.3 Perform Final Migration (Cutover)

After successful test migrations, you are ready for the final cutover. This involves stopping replication, performing a final synchronization of data, and bringing up the migrated server in Azure as your new production instance. Unlike Azure Site Recovery's "Commit failover" for DR, Azure Migrate uses a "Complete Migration" option.

# As with replication, the final migration (cutover) is orchestrated
# via the Azure Migrate portal and the appliance.
# There are no direct az migrate commands for performing a cutover in the general documentation.

# Conceptual step: Stop replication and complete migration
# az migrate server-migration complete `
#    --project-name 'SkyCoreMigrateProject' `
#    --resource-group 'SkyCoreMigrationRG' `
#    --migration-item-name 'OnPremWebServer01-MigrateItem'

Portal alternative: In your Azure Migrate project, navigate to 'Servers, databases and web apps' -> 'Migrating servers'. Select the replicated machines, click 'Stop replication', and then 'Complete migration'. This will finalize the migration, make the Azure VM the primary, and clean up replication artifacts.

Expected result: Your on-premises workload is now running live in Azure. The source on-premises server should be shut down or decommissioned to prevent data discrepancies.

Step 5: Phase 4: Post-Migration Optimization and Modernization

Migration isn't the finish line; it's the beginning of your cloud journey. The post-migration phase focuses on optimizing your newly migrated workloads for security, performance, cost-efficiency, and setting the stage for future modernization. SkyCore emphasizes continuous improvement in the cloud.

5.1 Enhance Security Posture

Immediately after migration, harden your security. Apply Network Security Groups (NSGs) with the principle of least privilege, integrate with Azure Security Center (now part of Microsoft Defender for Cloud), and ensure identity management (Azure AD) is correctly configured for all users and services.

# Add an inbound NSG rule to allow HTTP traffic to a web server
az network nsg rule create `
    --resource-group 'SkyCoreMigratedVMsRG' `
    --nsg-name 'SkyCoreMigratedNSG' `
    --name 'AllowHTTPInbound' `
    --priority 100 `
    --direction 'Inbound' `
    --access 'Allow' `
    --protocol 'Tcp' `
    --destination-port-ranges 80 `
    --source-address-prefixes 'Internet' `
    --destination-address-prefixes '*'

--nsg-name: The name of the Network Security Group to which the rule is added.

--name: A descriptive name for the NSG rule.

--priority: The order of processing for the rule (lower numbers are processed first).

--direction: 'Inbound' or 'Outbound' traffic.

--access: 'Allow' or 'Deny' access.

--protocol: The protocol (e.g., Tcp, Udp, Any).

--destination-port-ranges: The port(s) to which the rule applies.

--source-address-prefixes: The source IP address range (e.g., 'Internet', a specific CIDR, or '*').

--destination-address-prefixes: The destination IP address range (e.g., '*', or specific VM IPs).

Portal alternative: Navigate to your NSG in the Azure portal, select 'Inbound security rules' or 'Outbound security rules', and click 'Add' to configure new rules.

Expected result: Enhanced network security for your Azure VMs, controlling traffic based on defined rules.

5.2 Optimize Performance and Cost

Regularly review the performance of your migrated workloads. Use Azure Monitor to track metrics and Azure Advisor for personalized recommendations on cost optimization, performance, and reliability. Right-size VMs, leverage auto-scaling where appropriate, and explore options like Azure Reserved Instances for predictable workloads to significantly reduce costs.

# List Azure Advisor recommendations for your subscription
az advisor recommendation list `
    --query "[?category=='Cost' || category=='Performance']" `
    --output table

--query: A JMESPath query to filter results (here, for 'Cost' or 'Performance' categories).

--output table: Formats the output as a readable table.

Portal alternative: Navigate to 'Azure Advisor' in the Azure portal to view all recommendations categorized by Cost, Security, Reliability, Operational Excellence, and Performance.

Expected result: Insights into potential cost savings and performance improvements, along with actionable recommendations.

5.3 Plan for Modernization

The cloud offers vast opportunities beyond simply running VMs. Once stable, assess your migrated applications for modernization potential. This could involve refactoring applications to utilize Platform-as-a-Service (PaaS) offerings like Azure App Service or Azure SQL Database, containerizing applications with Azure Kubernetes Service (AKS), or adopting serverless architectures. This continuous modernization drives further efficiency and innovation.

Portal alternative: Explore services like Azure App Service, Azure SQL Database, and Azure Kubernetes Service in the Azure portal to understand their capabilities and assess suitability for your modernized applications.

Expected result: A roadmap for transforming your legacy applications into cloud-native solutions, leveraging Azure's full potential.

Step 6: SkyCore's Expert Recommendations and Best Practices

Drawing from years of experience in complex cloud migrations, SkyCore Solutions offers these consolidated recommendations for a successful on-premise to Azure migration:

1. Start Small, Iterate Often: Begin with non-critical workloads to refine your processes and build team confidence. Learn from each migration wave and apply those lessons to subsequent, more complex workloads.
2. Automate Where Possible: Leverage Infrastructure-as-Code (IaC) tools like Azure Resource Manager (ARM) templates or Terraform for provisioning Azure resources. This ensures consistency, repeatability, and reduces manual error.
3. Security-First Mindset: Integrate security considerations from day one. Design your Azure landing zone with robust network segmentation, strong identity management, and continuous monitoring. Don't treat security as an afterthought.
4. Non-Negotiable Dependency Mapping: Invest heavily in discovering and documenting all application and system dependencies. Use tools and thorough interviews. Mismanaged dependencies are the most common cause of migration failures.
5. Rigorous Testing: Never skip test migrations. They are invaluable for validating functionality, performance, and user acceptance in the Azure environment before cutover. Plan for multiple test cycles if needed.
6. Robust Rollback Plan: Always have a clear, tested rollback strategy. In the unlikely event of critical issues post-cutover, you need to be able to revert to your on-premises environment swiftly and safely.
7. Leverage Experts: Cloud migration can be challenging. Don't hesitate to engage Microsoft partners like SkyCore Solutions. Our expertise can validate your strategy, accelerate your timeline, and mitigate risks, especially for complex or large-scale projects.
8. Continuous Optimization: The cloud is dynamic. Regularly review your Azure environment for performance bottlenecks, cost inefficiencies, and security gaps. Cloud governance is an ongoing process.