Azure Migrate Rehost Scenario:- Need Clarification on Sysprep When Source and Target VMs share same domain and SID

Mahavir Saroj 311 Reputation points
2026-06-25T18:48:44.5866667+00:00

Hi Team,

I need some clarification regarding the use of Sysprep in an Azure Migrate (agentless) rehost scenario.

We are migrating a Windows Server VM ( Application) from on-premises to Azure using Azure Migrate (lift-and-shift approach).

Current situation:

  • The application exists only in a Production environment on-premises
  • There is no lower (non-production) environment available
  • As part of the migration strategy, the customer wants to first create a non-production (Acceptance) environment in Azure before moving to Production

Migration approach:

  • Agentless replication using Azure Migrate
  • The VM is migrated "as-is" (no OS or application changes)
  • The Azure VM is created with a different hostname to avoid naming conflict and to represent the new non-prod environment
  • During cutover, the on-prem VM will be powered off and the Azure VM will be brought online
  • After migration, we will log in to the Azure VM using local admin credentials. Even though the new name is visible in the Azure portal, we still need to rename the server inside the OS, as the OS hostname does not change automatically.
  • The Azure VM will be joined to the same Active Directory domain after

Additional requirement:

  • The on-prem server will be powered on later once Azure VM is ready. SO that there willbe no impact on production.
  • This means both on-prem and Azure VMs could exist at the same time

Thanks in advance for your guidance.Since Azure Migrate creates an exact copy of the server, both machines will have the same SID.

Azure Migrate
Azure Migrate

A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.


Answer accepted by question author
Jose Benjamin Solis Nolasco 12,601 Reputation points Volunteer Moderator
2026-06-25T20:00:55.0066667+00:00

Welcome to Microsoft Q&A.

Hello @Mahavir Saroj , I hope you are doing well.

Based on your migration scenario, it is generally not recommended to run Sysprep on a VM migrated using Azure Migrate when the intention is to preserve the existing operating system, applications, and configuration. What is happening is that Azure Migrate performs a lift-and-shift migration and creates a copy of the source machine. Running Sysprep would generalize the operating system, remove machine-specific information, and may impact application configurations, local profiles, and domain-related settings.

Regarding the SID concern, modern versions of Windows and Active Directory do not use the machine SID as the primary identifier for domain trust relationships. The computer account object in Active Directory and its associated credentials are what identify the machine within the domain.

Please check the following:

  1. If both the on-premises VM and Azure VM will coexist, ensure the Azure VM is renamed inside the guest OS before joining or reconnecting it to the domain.

Do not allow both machines to use the same computer name in the same Active Directory domain.

If the Azure VM is intended to become a separate Acceptance environment, create a new computer account by renaming the VM and then joining it to the domain.

Validate application-specific licensing or security mechanisms, as some applications may use machine identifiers that are independent of Windows SIDs.

Regarding your specific questions:

  • Should you run Sysprep?
    • Typically No, unless your goal is to create a generalized template image rather than preserve the migrated workload.
    • Will identical machine SIDs cause Active Directory issues?
      • Generally No. Duplicate machine SIDs are not typically a problem in Active Directory environments. The larger risk is having duplicate computer names or reusing the same domain computer account.
  • Will both VMs being online cause conflicts?
    • They can if they share the same hostname, IP configuration, or Active Directory computer account. Renaming the Azure VM and ensuring it has its own domain identity avoids these conflicts.

For additional information, please review:

Azure Migrate overview: https://learn.microsoft.com/azure/migrate/migrate-services-overview

Azure Migrate server migration: https://learn.microsoft.com/azure/migrate/server-migrate-overview

Sysprep overview: https://learn.microsoft.com/windows-hardware/manufacture/desktop/sysprep--system-preparation--overview

Mark Russinovich on machine SID duplication: https://techcommunity.microsoft.com/blog/askds/the-machine-sid-duplication-myth-and-why-sysprep-matters/399243

I hope this information helps.

If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily.

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

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