I support a client with three offices. Each location currently has a physical Windows Server 2019 or 2025 system, but the two smaller sites are running hardware that is more than 15 years old. The main office received a new, powerful server last year, and management does not want to purchase two additional replacement servers.
I suggested virtualizing the two remote servers on the main-office host and have been asked to investigate. The servers provide Active Directory, DNS, DHCP, and file shares. There are three separate domains, one for each site. DHCP and DNS are already being moved to the network gateways at two locations.
The sites use separate networks: 192.168.1.0/24 at the main office, 192.168.10.0/24 at one branch, and 192.168.20.0/24 at the other. The locations are connected with site-to-site VPN tunnels through UniFi gateways.
My concern is latency. If I perform a physical-to-virtual conversion and host the branch servers at the main office, branch users would access file shares and domain services across the VPN. I assume that could make file access noticeably slower, especially for large transfers. I also need to understand whether I would need VLANs at the main office, whether the existing VPNs can route the necessary traffic, and whether the branch IP ranges should be extended to the main site or replaced with new server subnets.
The main host has RAID6, nightly local backups, and weekly cloud backups, and I would extend that backup plan to the VMs. However, if the VPN went down, the branch offices would lose access to their file shares and domain services. I am looking for a sensible architecture and a safe testing, migration, and rollback plan.
5 Answers
The first question is whether centralizing these servers actually solves the problem. Virtualization removes the need to replace the old hardware, but it also makes the branch offices dependent on the VPN and the single main-site host. Active Directory and ordinary DNS traffic may be fine over a reasonably reliable tunnel, but file shares and line-of-business applications will reflect the WAN latency and bandwidth. Measure current traffic and tunnel performance before deciding.
I would not stretch the 192.168.10.0/24 or 192.168.20.0/24 networks across the VPN just to keep the old addresses. A routed Layer 3 design is generally safer than extending a broadcast domain between sites. Put the VMs on appropriate VLANs or subnets at the main office, route those networks through the site-to-site tunnels, and update DNS, firewall rules, and server references as needed. Whether VLANs are required depends on the host and switch design, but the VPN must have explicit routes and policies for the new networks.
Avoid trying to make the branch offices look like one large local Ethernet network. If the servers move, plan for routed traffic and make sure each site has reliable DNS forwarding for the relevant Active Directory zones.
Be especially careful with the domain controllers. Confirm the forest and domain layout, FSMO roles, DNS configuration, time synchronization, replication, DHCP dependencies, and application assumptions before moving anything. If each site has its own domain, document how trusts and name resolution work. A VPN outage would affect logons and file access, so consider whether each branch needs a local domain controller, cached services, or at least a contingency plan.
Given the age of the hardware and the business impact, involve an experienced infrastructure or networking consultant before committing. Document the current topology and services, measure bandwidth and latency, produce a migration plan, and get management to approve the risks. If the objection is only capital expenditure, compare this design with a staged hardware replacement, hosted infrastructure, or cloud services rather than assuming virtualization is automatically cheaper.
A physical-to-virtual conversion is not the difficult part; the design and recovery plan are. Build test VMs from a verified backup or image rather than modifying the production servers first. Test domain logons, DNS, file permissions, applications, VPN failure, backup restores, and rollback. Also confirm that the main host, storage, network equipment, power, and internet connection do not become single points of failure.
The impact depends heavily on what the servers do. Authentication and DNS are usually tolerable over a WAN link, while interactive file access and large copies are where users will notice the delay.