This article is based on a first-hand account originally published on virtualizationreview.com by an IT consultant and Microsoft Cloud Service Provider (CSP) who led the Azure migration of a small Australian accountancy firm. The lessons below reflect real decisions, trade-offs, and surprises encountered during that project.
Background: A Small Business Forced to Move
The client — referred to here as Progress Accounting — is a small accountancy firm based in Australia with just over ten staff across a main office and two smaller branch offices. They were running five servers in a VMware-based hosting environment approximately 70 miles away in Brisbane, alongside Office 365 Business Premium for email and collaboration.
The trigger for migration was straightforward: their hosting provider was changing its business model and asked them to move their workloads elsewhere. An upcoming office relocation delayed the project by a few months, but the migration ultimately went ahead. The hosting company had already run Azure Migrate — Microsoft’s free assessment service — to evaluate existing workloads, recommend equivalent Azure VM sizes, and estimate monthly costs. That report became the starting point for the migration planning.
Lesson 1: Azure Migrate Is a Starting Point, Not a Final Answer
Azure Migrate gives you a useful baseline: VM size recommendations and rough cost estimates. However, the tool assesses workloads based on observed performance and disk sizing, and it cannot account for application-level requirements, licensing constraints, or architectural decisions you may want to make during the migration — such as consolidating servers or changing how users authenticate. Treat the report as an input to your planning, not a migration plan in itself.
Lesson 2: The Current Identity Model Isn’t Always the Right One Going Forward
One of the first significant decisions was around identity. Rather than extending or replicating their existing directory into Azure, the team evaluated what the workloads actually needed. Because their line-of-business (LOB) application and its data were already protected by Multi-Factor Authentication (MFA) native to the application itself, the decision was made to use local Windows accounts on the migrated servers instead of deploying Azure Active Directory Domain Services or a domain controller VM.
This is a reminder that lifting and shifting an identity model along with the servers is not always necessary or desirable. Simpler setups can reduce management overhead and cost — provided the security requirements are genuinely met by an alternative approach.
Lesson 3: Don’t Rely on the Previous IT Provider to Do the Job
The scope was narrowed to two Windows Server 2016 machines: one running Citrix (to be converted to a Remote Desktop Services Host, RDSH) and one running SQL Server supporting the LOB applications. File shares were consolidated onto the SQL Server to reduce the number of servers to manage.
The hosting company offered to perform the migration over Christmas at no charge. Access to the Azure subscription was provided and configuration details were shared. After several weeks of silence, the team followed up and found that no migration work had been done — attributed to “lack of time.”
The lesson is unambiguous: when a migration is critical to a client’s business continuity, do not outsource the execution to a third party without clear accountability, agreed milestones, and regular check-ins. If you own the outcome, own the process.
The Migration: Using Azure Site Recovery for VMware-to-Azure
Because direct access to the hosting infrastructure was not available, the team asked the hosting company to deploy Azure Site Recovery (ASR) using the OVA-based Process Server/Configuration Server template designed for VMware-to-Azure migrations. Once in place, replication was configured for the two VMs.
One support incident arose when someone attempted to reinstall the replication agent on a VM where it was already installed. This broke the trust relationship between the agent and the process server — a known ASR gotcha.
Lesson 4: Don’t Reinstall to Fix Problems — Investigate First
The instinct to “just reinstall” when something is broken is understandable but dangerous in an ASR context. Reinstalling the Mobility Service agent over an existing installation can corrupt the agent-to-process-server trust and require Azure support involvement to resolve. Always check ASR logs and the Azure portal for specific error codes before taking corrective action.
Once replication was stable and the on-premises disks were in sync with Azure, test failovers were performed. During testing, the VMs were moved to a workgroup, local accounts were created, hosts file entries were added so the two servers could locate each other, Citrix was uninstalled, RDS Client Access Licenses (CALs) were applied, existing user profiles were linked to the new local accounts, and file shares were recreated.
One architectural limitation worth noting: ASR test failovers are designed to be temporary — the test VMs are expected to be deleted after validation. In this case, significant configuration work had been done on a test-failover VM that the team wanted to keep. ASR does not make it straightforward to promote a test failover VM to production. Plan your testing strategy accordingly and perform configuration work only after a planned failover, not during a test failover.
ASR Pricing Note: Azure Site Recovery is free for the first 31 days per replicated VM — a window specifically intended to support migrations. After that, a per-instance fee applies. Factor this into your migration timeline.
Network Security Groups (NSGs) were used to restrict access to the servers, and password and lockout policies were configured carefully — essential when servers are exposed directly to the internet over RDP.
Go-Live Day
On cutover day, the team worked on-site to reconfigure all client workstations to point to the new Azure-hosted servers and verified that each user could log in successfully. The transition was largely smooth — with one notable exception.
Lesson 5: Never Underestimate Printing
The client’s previous environment used a Citrix-specific mechanism to connect users to an on-premises multifunction printer/scanner. With Citrix gone, the team had to fall back to RDP printer redirection — projecting the local printer from each workstation into the RDP session.
Printing is consistently one of the most overlooked aspects of remote desktop and cloud migrations. Citrix and RDS handle printer mapping differently, and edge cases — particularly for multifunction devices used for scanning — can require significant troubleshooting. Audit printing and scanning workflows explicitly before migration day.
Lesson 6: Undocumented Configurations Will Bite You
The multifunction device also scanned documents and sent them via FTP to a watch folder on the server. The FTP password was unknown — to the client, to the incoming IT team, and apparently to the outgoing IT provider as well. The configuration had to be rebuilt from scratch.
This is a universal migration truth: legacy environments almost always contain undocumented integrations, credentials, and services. Budget time during discovery to map every inbound and outbound network dependency, scheduled task, and third-party integration. When in doubt, run a network capture to see what is actually talking to what.
Post-Migration: Operations and Cost Optimisation
After the migration, the environment settled into production with positive results. For some users, login times on the RDS host dropped from over 20 minutes to around 10 seconds — largely attributed to the move from older spinning disk storage to Azure premium SSD and improved network conditions.
Several operational decisions were made to manage cost and resilience:
- Disk sizing: ASR migrates VMs with managed disks sized to match the source VM’s disk sizes. These were found to be larger than necessary, resulting in higher-than-expected costs. Azure allows disks to be increased but not decreased in size. The workaround was to attach new, smaller managed disks and copy data across. When using ASR, review disk sizes post-migration and right-size immediately.
- Disk caching: ASR sets host caching to None by default on migrated disks. Microsoft’s recommendation for data disks on premium SSD is to enable Read caching for improved performance. This setting should be reviewed after migration.
- Backup: Azure Backup was configured to take daily VM snapshots, with hourly transaction log backups for SQL Server, retained for 30 days. Backups are stored across both Australian Azure regions to provide resilience against a regional outage.
- Automated shutdown: Azure Automation runbooks were used to shut down VMs at 9 p.m. and restart them at 5 a.m. local time each day — a simple and effective way to eliminate compute costs during off-hours for a business with predictable working hours.
- MFA for RDP: Duo Security’s MFA solution was layered onto RDP access to the primary server, leveraging the users’ existing familiarity with MFA from the LOB application.
- DNS names over IP addresses: Public IP addresses in Azure are dynamic by default and can change. The team used Azure DNS names mapped to the public IPs to avoid hard-coded IP dependencies in client configurations.
Next Steps
With the migration stable, the team began planning further improvements: moving from pay-as-you-go compute to Reserved Instances for cost reduction on predictable workloads; implementing Mobile Application Management (MAM) policies via Microsoft 365 E3 (an upgrade from Office 365 Business Premium) to protect data on personal mobile devices; and upgrading all workstations to Windows 10 Enterprise to unlock additional security features.
Summary of Lessons
- Azure Migrate is a starting point, not a migration plan. Use it for sizing and cost estimation, but design the target architecture independently.
- Reconsider your identity model. Don’t assume the existing directory structure should be replicated into Azure. Evaluate what the workloads actually require.
- Own the migration execution. Don’t delegate critical migration work to a third party without clear accountability and checkpoints.
- Investigate before you reinstall. In ASR especially, reinstalling agents can cause new problems. Check logs and error codes first.
- Audit printing and scanning workflows early. They are frequently overlooked and almost always more complex than expected in RDS or cloud environments.
- Document everything — and assume nothing is documented. Treat undocumented legacy configurations as a certainty, not a possibility.