Skip to main content
commvault.com commvault.com
Solved

DR Commserver Migration from Onprem to Azure Cloud

  • August 7, 2026
  • 2 replies
  • 67 views
A
Novice
Forum|alt.badge.img

We’re currently planning to migrate our DR Commserve from On-prem to Azure Cloud as part of Hardware Refresh project.

Current environment -

  • Primary CommServe (Production) hosted in a On-prem data center A.
  • DR CommServe configured and running in On-prem DC B.
  • Backups are getting backed up locally and connected with Production Backup Server A.
  • Currently everything is running on physical backup environment (Media Server, Storage, Primary and DR Backup Server)
  • Live Sync backups are configured in every 1 hour between Primary and DR Backup Server.

Planned Changes - 

  • Onprem DR Backup Server needs to decommission, and it needs to migrate in Azure cloud.
  • Primary Backup server will run as is in Onprem DC A.
  • Post successful migration, Primary Backup Server will be on physical environment and DR Backup server will run in Azure cloud.
  • Hostname will be same of DR backup server in Azure cloud. Only IP will be change.
  • No changes for Primary backup server.

Questions / Clarifications Required -

  • Best practices to migrate DR Commserve Server into cloud.
  • Any dependency on exiting IP as IP will be changed in Azure Cloud.
  • Any dependency or compatibility issue if we migrate DR Backup Server in cloud and rest of Backup infra is running in Physical On-prem Backup Infra.

Can we use below strategy for this DR migration.

1 - Perform Physical 2 Virtual of DR Backup Server via VMware option.

2 - Post successful P2V, Take Snapshot backup of DR Backup Server.

3 - Restore server via snapshot backup in Cloud through Commvault.

4- Post successful restore, reconfigure the live sync and everything. 

 

Kindly suggest with your recommendation. 

Thank you!

 

Best answer by Dheeraj Shetty

Hi ​@anup9236 ,

Your Production CommServe is current hosted in on-premises while the DR CommServe is to migrated to Azure. This deployment model is supported, and there should be no compatibility concerns provided that the Azure DR CommServe is configured with the same Commvault version, operating system version, SQL Server version, and required packages as the existing DR environment.

Regarding your specific questions:

1. Best Practices for Migrating the DR CommServe to Azure

  • Deploy a new Azure VM with matching OS, SQL Server, and Commvault software versions.
  • Configure the Azure server as the new standby CommServe for LiveSync.
  • Validate LiveSync replication, transaction log shipping, and CommServe Failover functionality after setup.
  • Perform a planned failover/failback test before decommissioning the existing DR CommServe.

 

2. IP Address Change Considerations

  • A change in IP address is generally acceptable.
  • Since the hostname will remain unchanged, the primary considerations are ensuring proper DNS resolution, network connectivity, firewall rules, and any environment-specific references to the previous IP address are updated.
  • LiveSync and CommServe Failover are designed to minimize dependency on DNS changes during failover operations.

 

3. Primary CommServe On-Premises and DR CommServe in Azure

  • Running the Production CommServe on-premises and the standby DR CommServe in Azure is a supported design.
  • We recommend validating network connectivity, latency, firewall requirements, and monitoring node placement, particularly if Automatic Failover is configured. Proper monitoring node deployment helps prevent unintended failover events during network isolation scenarios.

Your proposed approach is:

  1. Perform a P2V conversion of the existing DR CommServe.
  2. Take a VM snapshot.
  3. Restore the server into Azure.
  4. Reconfigure LiveSync.

While this approach may be technically feasible, it is not the preferred recommendation. A cleaner and lower-risk approach is to deploy a fresh Azure standby CommServe and configure it as a new LiveSync target. This helps avoid potential issues related to machine identity, networking changes, SQL consistency, and LiveSync configuration dependencies inherited from the existing DR server. Additionally, internal LiveSync guidance advises against relying on VM snapshots as the migration mechanism for CommServe environments.

Recommended Approach is as follows:

  1. Build a new Azure VM.
  2. Install matching OS, SQL Server, and Commvault components. Ref Doc : https://documentation.commvault.com/v11/software/installing_standby_commserve_host.html
  3. Configure the Azure host as the new standby CommServe.
  4. Initialize and validate LiveSync replication.
  5. Perform a planned failover/failback test.
  6. Following successful validation, Disable Live Sync.
  7. Retire the existing on-premises DR CommServe and Enable the LiveSync Back and ensure the both the nodes are detected in the CS LIve Sync Configuration


Regards,
Dheeraj

2 replies

D
Vaulter
Forum|alt.badge.img+10

Hi ​@anup9236 ,

Your Production CommServe is current hosted in on-premises while the DR CommServe is to migrated to Azure. This deployment model is supported, and there should be no compatibility concerns provided that the Azure DR CommServe is configured with the same Commvault version, operating system version, SQL Server version, and required packages as the existing DR environment.

Regarding your specific questions:

1. Best Practices for Migrating the DR CommServe to Azure

  • Deploy a new Azure VM with matching OS, SQL Server, and Commvault software versions.
  • Configure the Azure server as the new standby CommServe for LiveSync.
  • Validate LiveSync replication, transaction log shipping, and CommServe Failover functionality after setup.
  • Perform a planned failover/failback test before decommissioning the existing DR CommServe.

 

2. IP Address Change Considerations

  • A change in IP address is generally acceptable.
  • Since the hostname will remain unchanged, the primary considerations are ensuring proper DNS resolution, network connectivity, firewall rules, and any environment-specific references to the previous IP address are updated.
  • LiveSync and CommServe Failover are designed to minimize dependency on DNS changes during failover operations.

 

3. Primary CommServe On-Premises and DR CommServe in Azure

  • Running the Production CommServe on-premises and the standby DR CommServe in Azure is a supported design.
  • We recommend validating network connectivity, latency, firewall requirements, and monitoring node placement, particularly if Automatic Failover is configured. Proper monitoring node deployment helps prevent unintended failover events during network isolation scenarios.

Your proposed approach is:

  1. Perform a P2V conversion of the existing DR CommServe.
  2. Take a VM snapshot.
  3. Restore the server into Azure.
  4. Reconfigure LiveSync.

While this approach may be technically feasible, it is not the preferred recommendation. A cleaner and lower-risk approach is to deploy a fresh Azure standby CommServe and configure it as a new LiveSync target. This helps avoid potential issues related to machine identity, networking changes, SQL consistency, and LiveSync configuration dependencies inherited from the existing DR server. Additionally, internal LiveSync guidance advises against relying on VM snapshots as the migration mechanism for CommServe environments.

Recommended Approach is as follows:

  1. Build a new Azure VM.
  2. Install matching OS, SQL Server, and Commvault components. Ref Doc : https://documentation.commvault.com/v11/software/installing_standby_commserve_host.html
  3. Configure the Azure host as the new standby CommServe.
  4. Initialize and validate LiveSync replication.
  5. Perform a planned failover/failback test.
  6. Following successful validation, Disable Live Sync.
  7. Retire the existing on-premises DR CommServe and Enable the LiveSync Back and ensure the both the nodes are detected in the CS LIve Sync Configuration


Regards,
Dheeraj

    A
    Novice
    Forum|alt.badge.img
    • anup9236Novice
    • Author
    • Novice
    • August 19, 2026

    Hi ​@anup9236 ,

    Your Production CommServe is current hosted in on-premises while the DR CommServe is to migrated to Azure. This deployment model is supported, and there should be no compatibility concerns provided that the Azure DR CommServe is configured with the same Commvault version, operating system version, SQL Server version, and required packages as the existing DR environment.

    Regarding your specific questions:

    1. Best Practices for Migrating the DR CommServe to Azure

    • Deploy a new Azure VM with matching OS, SQL Server, and Commvault software versions.
    • Configure the Azure server as the new standby CommServe for LiveSync.
    • Validate LiveSync replication, transaction log shipping, and CommServe Failover functionality after setup.
    • Perform a planned failover/failback test before decommissioning the existing DR CommServe.

     

    2. IP Address Change Considerations

    • A change in IP address is generally acceptable.
    • Since the hostname will remain unchanged, the primary considerations are ensuring proper DNS resolution, network connectivity, firewall rules, and any environment-specific references to the previous IP address are updated.
    • LiveSync and CommServe Failover are designed to minimize dependency on DNS changes during failover operations.

     

    3. Primary CommServe On-Premises and DR CommServe in Azure

    • Running the Production CommServe on-premises and the standby DR CommServe in Azure is a supported design.
    • We recommend validating network connectivity, latency, firewall requirements, and monitoring node placement, particularly if Automatic Failover is configured. Proper monitoring node deployment helps prevent unintended failover events during network isolation scenarios.

    Your proposed approach is:

    1. Perform a P2V conversion of the existing DR CommServe.
    2. Take a VM snapshot.
    3. Restore the server into Azure.
    4. Reconfigure LiveSync.

    While this approach may be technically feasible, it is not the preferred recommendation. A cleaner and lower-risk approach is to deploy a fresh Azure standby CommServe and configure it as a new LiveSync target. This helps avoid potential issues related to machine identity, networking changes, SQL consistency, and LiveSync configuration dependencies inherited from the existing DR server. Additionally, internal LiveSync guidance advises against relying on VM snapshots as the migration mechanism for CommServe environments.

    Recommended Approach is as follows:

    1. Build a new Azure VM.
    2. Install matching OS, SQL Server, and Commvault components. Ref Doc : https://documentation.commvault.com/v11/software/installing_standby_commserve_host.html
    3. Configure the Azure host as the new standby CommServe.
    4. Initialize and validate LiveSync replication.
    5. Perform a planned failover/failback test.
    6. Following successful validation, Disable Live Sync.
    7. Retire the existing on-premises DR CommServe and Enable the LiveSync Back and ensure the both the nodes are detected in the CS LIve Sync Configuration


    Regards,
    Dheeraj

    Hi Dheeraj,

    We have deployed third DR Stand by server in Azure and completed all the below steps.

    Please let me know if we need to follow any additional steps before to decommission the production Commserver or we just need to disable the Live Sync and remove the current prod backup server. 

    Note - We have already performed the Production Failover to Newly build DR Server. 

    • Deploy a new Azure VM with matching OS, SQL Server, and Commvault software versions.
    • Configure the Azure server as the new standby CommServe for LiveSync.
    • Validate LiveSync replication, transaction log shipping, and CommServe Failover functionality after setup.
    • Perform a planned failover/failback test before decommissioning the existing DR CommServe.

    Readiverse Academy Certifications

    description of image
    Terms & ConditionsAccessibility statement