Latency-Sensitive SQL and a Hybrid Cloud Decision
Helio Bank runs 40 VMware VMs on aging hardware: 12 SQL Server instances, 18 application servers, and 10 file and print servers. The SQL tier stores 20 TB, has a 1.2 ms write-latency SLO, and replicates with Always On availability groups. Regulators require customer data to remain in the country and backups to be recoverable within four hours. The bank is evaluating Azure VMware Solution in the same region over ExpressRoute versus an on-premises refresh. The current backup window is six hours, and the RPO is one hour. The network team can provide 1 Gbps ExpressRoute with 5 ms round-trip latency to Azure. The CIO wants a decision in two weeks and a migration sequence that avoids a big-bang cutover.
1. Decide placement for each workload tier and justify the decision.
Read the worked answer
Tier the 40 VMs rather than treating the estate as one decision. Keep the 12 SQL primaries on-premises if the 1.2 ms write SLO is hard and ExpressRoute round-trip latency is 5 ms. Adding 5 ms to every commit is likely unacceptable for latency-sensitive transaction paths, and the SLO would be at risk before any application tuning. Place one Always On secondary replica in Azure VMware Solution for DR and read-only reporting, so the bank gains cloud DR without moving the primary.
Move the 18 application servers and 10 file and print servers to AVS if dependencies are mapped and they do not require low-latency local storage. File and print is a good first wave because it is less latency-sensitive and easy to validate. Keep backups in-country and retain an on-premises immutable copy; do not let the cloud become the only copy. The decision rule is data gravity and latency for SQL, and refresh avoidance and operational flexibility for app and file. The outcome is hybrid, not a binary cloud-versus-on-premises choice.
2. Design the migration sequence, network path, and backup approach.
Read the worked answer
Use HCX for bulk and delta migration of application and file VMs. For SQL, use Always On seeding or backup and restore to the secondary rather than HCX for the primary. Sequence: establish the landing zone and ExpressRoute with BGP, non-overlapping IP space, NSX-T segments, and firewall rules; pilot two file servers; migrate application servers in dependency groups; build the SQL secondary in AVS and test failover; cut over reporting, not the primary.
A 1 Gbps ExpressRoute circuit is enough for migration if throttled, but production replication needs a calculated bandwidth budget. Keep on-premises NetWorker and PowerProtect for the SQL primary, add a cloud copy for migrated workloads, and test a four-hour restore from the cloud copy. Avoid a big-bang cutover: freeze, apply the final delta, validate, and switch DNS or service per group. Document rollback for each wave.
Network dependencies matter more than the migration tool. Inventory hard-coded IPs, local file shares, and broadcast dependencies before each wave.
3. What are the main risks, and what conditions would change your recommendation?
Read the worked answer
Main risks are that 5 ms round-trip latency breaks the SQL SLO, a single ExpressRoute circuit becomes a single point of failure, backups or vendor support access violate data residency, HCX migration saturates the 1 Gbps link, and the team lacks NSX-T and AVS skills. Cost creep from egress and cross-service traffic is also likely.
Mitigate with a latency proof of concept for one SQL secondary, dual ExpressRoute circuits or a backup path, in-country backup storage, QoS during migration, and a tested runbook. Change the recommendation if measured application latency to AVS stays within the SQL SLO, or if the bank accepts a relaxed SLO for a specific database. Also reconsider if a regulator permits only in-country cloud regions and the chosen region qualifies, or if the on-premises refresh cost exceeds the hybrid model over five years. Do not decide from architecture diagrams alone; measure one real workload.