Share via

Asking for advise with Azure Windows Server 2016 to 2025 Migration

Montoya, Mabelle 160 Reputation points
2026-02-11T18:09:05.77+00:00

We are currently planning a comprehensive infrastructure modernization to upgrade our Azure fleet from Windows Server 2016 to Windows Server 2025. Given the approaching EOL for Server 2016 (Jan 2027) and the generational leap required, we want to ensure our roadmap aligns with Microsoft’s "Well-Architected Framework." We were previously scheduled to connect regarding our architecture, and we would like to use that time to specifically validate our migration strategy for this workload.

  1. Current Infrastructure Scope We are migrating a total of 32 Servers hosted across two Azure regions (East US and West Europe). The infrastructure is segmented into three logical groups to support different customer compliance profiles:

LSUS: Life Science Customers (US)

SDUS: Standard Customers

(US) LSEU: Life Science Customers (Europe)

Each group functions as an independent stamp with identical architecture: 2x Domain Controllers: AD DS (Currently Server 2016, Forest Functional Level 2012) 2x Web Servers: IIS hosting multiple client sites 1x Agent Server: Running App Services 3x SQL Servers: SQL Server 2019 Enterprise

  1. Our Proposed Strategy Based on our internal assessment, we have defined the following upgrade paths. We would like your feedback on whether these align with your recommended best practices: Domain Controllers $\rightarrow$ Windows Server 2022 (Side-by-Side): Rationale: We plan to introduce Server 2022 DCs rather than jumping straight to 2025. We believe this offers a stable identity baseline with zero schema bugs for our existing 2016-integrated apps, while still allowing us to raise the Forest Functional Level from 2012. Web & Agent Servers $\rightarrow$ Windows Server 2025 (Side-by-Side): Rationale: We intend to build fresh 2025 VMs (e.g., Standard_D4s_v5) to leverage Azure Hotpatching (zero-reboot updates) and HTTP/3 support in IIS. SQL Servers $\rightarrow$ Windows Server 2025 (Side-by-Side): Rationale: We are targeting Server 2025 to utilize the Native NVMe Stack (DirectStorage) for the projected 70% IOPS increase.
  2. Key Discussion Points for the Meeting To finalize this roadmap, we need clarity on the following four areas: A. Active Directory Compatibility Our current Forest Functional Level is 2012, while child domains are 2016. Question: Is the jump from FFL 2012 directly to a Mixed Mode with Server 2025 DCs supported and safe? Or does our decision to stop at Server 2022 for DCs represent the safer interim step to minimize risk? B. IIS & Security Hardening We understand Server 2025 enforces stricter security defaults (e.g., TLS 1.3 enabled by default, NTLM restrictions). Question: Have you seen specific friction points with legacy IIS applications migrating to 2025? Are there specific "compatibility flags" (e.g., regarding TLS 1.2 fallback) we should pre-configure in the registry to prevent application downtime? C. Licensing & Reservations We currently utilize Azure Reservations for our VM Compute (e.g., Standard_D8s_v3).

Question: As we modernize the hardware to V5 instances (e.g., Standard_D8s_v5) and change the OS, do our existing Reservations cover the new instance "Family," or is an "Exchange/Refund" required? Specifically, does the reservation bind to the Region + Family or strictly the vCPU count? D. Migration Experience Question: For a fleet of this size (32 VMs), do you have insights from other customers regarding "In-Place Upgrades" vs. "Clean Build"? We are leaning towards "Clean Build" (Side-by-Side) to ensure a pristine environment and avoid legacy driver issues, but we are open to In-Place upgrades for the Web layer if the tooling is sufficiently mature. Subscription: Verify Platform - Prod-Val

Windows for business | Windows Server | Windows cloud | Other
0 comments

Answer accepted by question author

Domic Vo 24,450 Reputation points Independent Advisor
2026-02-11T19:29:40.23+00:00

Hello Montoya, Mabelle,

Your proposed roadmap is well thought out and aligns closely with Microsoft’s Well‑Architected Framework principles, but let me address each of your four key discussion points with precision.

For Active Directory, the jump from a Forest Functional Level of 2012 directly into a mixed environment with Windows Server 2025 domain controllers is technically supported, but it is not the safest path. Microsoft’s official guidance is that you can introduce newer DCs into an existing forest without immediately raising the functional level. However, because Server 2025 is still a generational leap, the interim step of introducing Server 2022 DCs first is the more conservative approach. This ensures schema stability and avoids unexpected compatibility issues with legacy applications tied to your current 2016 DCs. Once the 2022 DCs are stable, you can raise the forest functional level incrementally before introducing 2025 DCs.

On IIS and security hardening, Server 2025 does enforce stricter defaults, including TLS 1.3 enabled by default and tighter NTLM restrictions. The most common friction point is legacy applications that still rely on TLS 1.0/1.1 or explicit NTLM fallback. To mitigate downtime, you should pre‑configure registry flags under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols to explicitly allow TLS 1.2 fallback during the migration window. This gives you time to remediate applications without breaking connectivity. NTLM restrictions can be relaxed temporarily via Group Policy under Network security: Restrict NTLM if you discover dependencies.

For licensing and reservations, Azure Reservations bind to region and VM family, not strictly vCPU count. Moving from Dv3 to Dv5 instances is considered a family change, so your existing reservations will not automatically apply. You will need to perform an exchange or refund to align reservations with the new VM family. Microsoft allows exchanges without penalty, but you should plan this as part of the migration to avoid unexpected compute cost spikes.

On migration experience, for a fleet of 32 VMs, clean builds are strongly recommended for domain controllers and SQL servers. This avoids carrying forward legacy drivers and registry cruft. In‑place upgrades are technically supported for web servers, but in practice most customers prefer side‑by‑side builds because IIS configuration can be exported and re‑imported cleanly. The tooling for in‑place upgrades is mature, but the risk of subtle compatibility issues is higher than the cost of building fresh VMs in Azure. Given your compliance requirements, side‑by‑side is the safer long‑term choice.

In summary, your plan to stop at Server 2022 for DCs, move web and agent servers directly to Server 2025, and target SQL workloads on Server 2025 with NVMe support is aligned with best practices. The only adjustments I would recommend are to explicitly plan for TLS fallback registry settings during IIS migration and to schedule Azure Reservation exchanges when moving to Dv5 instances.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-02-11T18:09:18.88+00:00
    1. Active Directory Compatibility: Upgrading from a Forest Functional Level (FFL) of 2012 directly to a mixed mode with Server 2025 domain controllers is not explicitly mentioned in the provided context. However, introducing Server 2022 domain controllers as an interim step is a prudent approach to ensure stability and compatibility, especially since it allows raising the FFL while minimizing risks associated with schema changes.
    2. IIS & Security Hardening: The context indicates that Windows Server 2025 enforces stricter security defaults, including TLS 1.3. While specific friction points with legacy IIS applications are not detailed, it is advisable to test your applications in a staging environment to identify potential issues. Pre-configuring compatibility flags related to TLS 1.2 fallback may help mitigate downtime risks during the migration.
    3. Licensing & Reservations: The context does not provide specific information on Azure Reservations covering new instance families. Generally, Azure Reservations are tied to the region and instance family, so an exchange or refund may be required when changing families. It is recommended to verify with Azure support for the most accurate guidance regarding your specific situation.
    4. Migration Experience: For a fleet of 32 VMs, a clean build (side-by-side) is often preferred to avoid legacy driver issues and ensure a pristine environment. In-place upgrades can be considered for the web layer if the tooling is mature enough, but this approach may carry risks associated with existing configurations and drivers. Gathering insights from other customers who have undergone similar migrations could provide valuable perspectives on the best approach.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer 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.