In our journey we often encounter small and medium-sized businesses (SMBs) with outdated, unreliable, and poorly managed IT infrastructures. Recently, we onboarded a new SMB client, completely overhauling their infrastructure and migrating them to our Ad.Managed Workplace service — one of our core managed services under the Ad.Services Managed umbrella.
This blog details the challenges we faced, and the lessons we learned, especially around the hidden pitfalls of latency when deploying Line of Business Applications hosted on Azure.
The Starting Point: A Messy IT Infrastructure
The client had a classic on-premises setup: an aging server hosting their Line of Business (LOB) application, hosted pop email server, and workstations without centralized management. Security measures were minimal, and their backup solution was unreliable. Our task was to modernize their entire IT for 15 Users environment while ensuring minimal downtime.
Here’s what we proposed and delivered:
- Server Migration to Azure: We spun up a B4ms Azure server to host their SQL-based LOB application.
- Endpoint Management with Intune and Defender for Business: We onboarded their devices into MEM (Microsoft Endpoint Manager) and deployed Defender for Business to secure their endpoints.
- Email Migration to Exchange Online: We moved their email infrastructure to the cloud.
- Teams VoIP Implementation: We replaced their 3CX phone system with Microsoft Teams VoIP.
- Microsoft Business Premium Licensing*
The client agreed to our proposal under one condition: everything needed to be done quickly, as their existing on-prem infrastructure was barely holding together.
*We require all our clients to adopt at least this licensing tier as a baseline. If a client isn’t willing to make this investment, we don’t move forward as we need to work with Entra P1 Features for CA Policies, Intune, Defender for Business, etc. at least (Maybe more on what's everything possible with Business Premium Licensing in another blog!)
The PoC: When Latency Strikes
As part of our process, we always start with a Proof of Concept (PoC) using a freshly deployed workstation. This allows us to validate the setup and ensure everything runs smoothly before rolling it out across the entire organization.
During this PoC, we reached out to the LOB application developer to confirm that their software could be hosted on an Azure server.
The response from the developer?
With this confirmation in hand, we moved forward with deploying the server in Azure, configuring it to run their SQL database, and distributing the LOB client application to the workstations via Intune.
During the PoC, we ensured that all endpoints were enrolled in Intune, configured the Azure VPN (Always On) and deployed the LOB application’s fat client to a test workstation. The initial setup went well, but once we started testing the application’s performance, we hit a major roadblock: the software’s performance was abysmal.
Every time the fat client tried to communicate with the SQL database on the Azure server, users experienced significant delays. The dreaded “loading circle of death” appeared repeatedly. At first, we suspected Defender might be causing the issue because we encountered during the installation some ASR Blocks, so I personally dove into the Defender logs to investigate. But there were completely no signs of interference there which I assumed from the beginning to be honest.
Next, our network engineer stepped in to analyze the network traffic. It didn’t take long to identify the culprit: latency.
The Root Cause: Latency and Fat Clients
The LOB application relied on a fat client that needed constant communication with the SQL database on the Azure server. Every request sent from the fat client to the database had to travel through the site-to-site (S2S) VPN or when working from home point-to-site (P2S) VPN we configured. Unfortunately, the latency could not be handled by the application made the application nearly unusable during the PoC.
The client’s LOB Application simply couldn’t handle the round-trip time required to communicate with the Azure-hosted SQL server. While the rest of the infrastructure worked perfectly—email, endpoint management—the LOB application was effectively bricked by latency.
The Solution: Windows 365 to the Rescue
Faced with this challenge, we knew we needed to act fast. The client was understandably tense to complete the migration and shut down their old on-prem server. So, we proposed a new approach: Windows 365 Cloud PCs.
We quickly spun up a Windows 365 machine and tested the fat client’s performance. The difference was night and day. Since the Cloud PC is hosted in the same Azure vNet as the SQL server, latency was no longer an issue. The fat client’s communication with the database was seamless.
To ensure the client’s users could easily transition from their old On Premise Infrastructure to this solution, we implemented Windows 365 Boot, allowing their physical workstations to boot directly into their Cloud PCs. This provided a familiar desktop experience while eliminating the performance issues caused by latency.
Lessons Learned: Why Latency Can Brick an Azure Project
This project taught me personally a crucial lesson: latency can make or break an Azure migration. (Network Engineer was laughing at me after that)
- Understand the Application’s Architecture: Always verify how an application communicates with its backend. Fat clients that require constant communication with a remote SQL server are particularly sensitive to latency.
- Assess Latency Early in the PoC: During the PoC phase, perform thorough latency tests as we did, especially for critical applications. This one taught me again the importance of our PoCs which we do in every first phase, regardless of the customers size.
- Consider Cloud PCs for Performance-Intensive Applications: Windows 365 is a game-changer for scenarios where latency is an issue. By keeping both the client and server within the Azure environment, you can eliminate many latency-related problems.
- Communicate Clearly with Clients: When unexpected issues arise, transparency is key. We kept the client informed throughout the troubleshooting process and proposed a viable solution quickly, which helped maintain their trust.
- Stick to Your Standards: Our policy of only working with at least Microsoft Business Premium paid off. Having a standardized environment made troubleshooting and deploying new solutions much easier.
- Be cautious with vendor assurances: In this project, the LOB application developer initially confirmed that hosting the application on Azure was fully supported. After experiencing issues, they later admitted that they didn’t have any customers running the application in Azure. This miscommunication caused unnecessary delays and frustration.
Conclusion
The project ended successfully, with the client fully onboarded onto our Managed Workplace solution. By leveraging Windows 365, we turned a potential failure into a win. The client now enjoys a modern, secure, and efficient IT infrastructure, and we’ve gained valuable insights to apply to future projects.
Latency is often overlooked in cloud migrations, it can be a project killer. By recognizing the impact of latency and adapting our approach with solutions like Windows 365, we can ensure successful Azure migrations for our clients regardless of how old their applications are (at least until now).
Stay tuned for more insights and best practices from our real-world projects—and why we always insist on Microsoft Business Premium for our clients. But that’s a topic for another blog!
