Moving a workload to Azure is mostly a solved problem. Replicating a server and cutting over is routine. What is not routine is discovering, three hours into a Friday night cutover, that the accounts system was reaching a share on a machine nobody documented and nobody thought was in scope.
Undocumented dependencies are the number one cause
Almost every migration problem we have dealt with traces back to something depending on something else in a way nobody had written down. These are the ones that recur.
- Hard-coded IP addresses in application configuration rather than DNS names
- Scheduled tasks and scripts on a server nobody considers part of the application
- Mapped drives referenced by a line-of-business app rather than by a user
- Print servers and scan-to-folder destinations on multifunction devices
- Licence servers pinned to a MAC address or hostname that changes in Azure
- Legacy applications that authenticate against a domain controller in a way that assumes low latency
Map the traffic, not just the servers
A discovery phase that maps traffic between machines finds these before cutover night. Skipping it is what turns a two-hour window into a weekend.
Licensing surprises
Two things catch Dubai businesses out. First, Windows Server and SQL Server licences with Software Assurance can often be carried into Azure under Hybrid Benefit, which materially reduces the run cost. Many clients hold entitlements they had forgotten about, so audit before you budget.
Second, some third-party software is licensed per physical core or tied to specific hardware. That model does not translate cleanly to a cloud VM, and the vendor conversation needs to happen during planning rather than after you have moved.
Performance assumptions that do not survive the move
| Assumption | What actually happens | What to do |
|---|---|---|
| Storage will be as fast as our SSDs | Default managed disks are slower than local NVMe | Size disk tier against measured IOPS, not guesswork |
| Latency will be similar | Anything chatty between on-prem and Azure feels slower | Move dependent workloads together, not one at a time |
| The VM size maps to our server | Cloud vCPUs are not equivalent to physical cores | Right-size after a month of real usage data |
| Backups come with the platform | Microsoft guarantees the platform, not your data | Configure Azure Backup explicitly, with retention agreed |
What we usually recommend leaving on-premise
Being willing to say this is what separates a migration plan from a sales pitch. Workloads that need constant high-bandwidth access to local hardware, and legacy applications whose vendor will not support them in the cloud, are often better left where they are. A hybrid design with one local server is frequently the right answer.
Cutover, and the rollback nobody plans
- 1Replicate while the original keeps running, so there is no downtime during the copy
- 2Agree a rollback plan in writing before the cutover window opens
- 3Keep the source system available and powered but isolated, not decommissioned, for an agreed period
- 4Cut over one workload group at a time rather than the whole estate in one night
- 5Verify from the user side, not just from the console, before declaring it done
Planning an Azure migration?
We assess the estate first, including the dependencies nobody has written down, then design and cost the target before any migration work begins.
