Best Practices for Azure Migrate: SQL Server with Heavy Dependencies (No Test Environment, Lift-and-Shift, VMware)

Tahir Ghalib 0 Reputation points
2025-05-05T12:11:15.1066667+00:00

Hi everyone,

I'm planning a migration using Azure Migrate and would appreciate your guidance on the best approach for the following scenario:

  • We have a central SQL Server running on a VMware on-premises environment.

This SQL Server hosts critical databases and has many application/service dependencies.

There is no separate test environment available.

The organization prefers a lift-and-shift (rehost) migration to Azure VMs without refactoring at this stage.

I'd like to understand:

Pros and cons of doing a lift-and-shift for this kind of SQL Server workload.

Any Microsoft-recommended best practices for such migrations (especially with no test environment).

A step-by-step guide or checklist to safely perform the migration using Azure Migrate.

How to best handle dependency mapping and validation post-migration in this context.

Any experience, tips, or references to official documentation would be greatly appreciated.

Thanks in advance!

TaGhalib

Azure Migrate
Azure Migrate
A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.
901 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Ashok Gandhi Kotnana 6,515 Reputation points Microsoft External Staff
    2025-05-05T13:23:45.1066667+00:00

    Hi @Tahir Ghalib ,

    Goodday!

    Recommendation: Use IaaS (Azure VM) for Now For your current scenario, it is strongly

    recommended to migrate the SQL Server as-is using Azure Virtual Machines (IaaS). This approach supports a lift-and-shift migration with minimal disruption, requires no code changes, and preserves all SQL Server features such as SQL Agent, cross-database queries, and custom configurations. Azure Migrate fully supports rehosting from VMware to Azure VMs, making it the most practical and low-risk option in your case.

     PaaS (Platform-as-a-Service) – Not Ideal Right Now Azure SQL Database or Azure SQL Managed Instance (PaaS options) offer many long-term benefits such as automatic patching, backups, high availability, and auto-scaling. However, they require some level of refactoring or feature compatibility checks, which is not suited for your current no-test, critical-production environment. You can consider transitioning to PaaS later once the workload is stable in Azure and time allows for re-architecture.

     Pros of IaaS (Lift-and-Shift to Azure VM) Full control over the OS and SQL Server instance.

     No application or database changes required.

     Supports all existing features and configurations.

     Fastest way to move to Azure using Azure Migrate.

     Easier rollback/failback if something goes wrong.

     Cons of IaaS You are responsible for managing OS patches, SQL updates, backups, and high availability.

     Limited scalability and automation unless manually configured.

     Potentially higher long-term costs if not optimized after migration.

      Best Practices from Microsoft (Without a Test Environment)

     1.Use Azure Migrate to discover and assess your SQL Server VM from VMware.

     2.Enable dependency mapping to identify all services, ports, and applications connected to the SQL Server.

     3.Carefully size the Azure VM based on performance and storage needs.

     4.Use Premium SSDs for database disks to maintain performance.

     5.Leverage the Azure Hybrid Benefit to save on licensing costs.

     6.Run a test migration during off-hours or using snapshots (if possible).

     7.Ensure monitoring and backup are configured immediately after cutover using Azure Monitor and Azure Backup.

     Step-by-Step Migration Using Azure Migrate

     1.Create an Azure Migrate project in the Azure portal.

     2.Deploy the Azure Migrate appliance on-premises to discover VMware VMs.

     3.Perform an assessment to check readiness and recommend sizing.

     4.Configure replication settings, including storage, network, and availability.

     5.Perform a test migration (optional but recommended) for validation.

     6.Execute the final cutover once validated.

     7.After migration, validate application connectivity, SQL Server services, and database performance.

     8.Set up Azure Backup, Log Analytics, and monitoring alerts post-migration.

     Handling Dependency Mapping and Post-Migration Validation

     1.Use Azure Migrate Dependency Visualizer before migration to map application/service relationships with SQL Server.

     2.After migration, use Azure Monitor, Log Analytics, and Network Watcher to validate live application connections and monitor errors.

     3.Update DNS records or connection strings if necessary.

     4.Ensure all dependent applications are working correctly and without timeout or login issue

    Refer below MS documents for more information: -

    https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-checklist?view=azuresql

    https://learn.microsoft.com/en-us/azure/migrate/concepts-dependency-visualization?view=migrate-classic&utm_source

    https://learn.microsoft.com/en-us/azure/azure-sql/database/monitor-tune-overview?view=azuresql

    Please let me know if you face any challenge here, I can help you to resolve this issue further

    Provide your valuable Comments.

    User's image

    Please do not forget to "Accept the answer” and “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.


Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.