Before I touched a cloud migration tool, I built virtual servers from ISO images and managed WSUS patching across 1,600 Windows Servers, versions 2003 to 2016. I also ran VMware vSphere with no cloud abstraction layer on top. That path into migration engineering is getting rare, and I think it shows.

Azure Migrate is capable and well documented. But moving 100+ physical and VMware workloads to Azure means knowing how each one was built on premises:

• Storage type and IOPS requirements
• Network dependencies between servers that used to talk over a local network and now cross an Azure virtual network
• How the application behaves on bare metal or VMware versus an Azure VM

Those aren’t tool configuration questions. Get the answers wrong and you find out as performance problems after cutover.

Two habits from the old job carried straight over:

• PowerShell. Scripting SCCM agent deployments and SCEP installs across the estate is the same skill M365 migration roles need for directory objects and mailboxes at scale. On premises, automation was how we kept up.
• Sequencing. WSUS patching across 1,600 servers meant deciding the order, the rollback triggers, and who owned each step. A migration runbook asks for the same decisions. I’d just been making them in a different context.

Engineers who can troubleshoot a failure at the infrastructure layer, not just the tool layer, are harder to find than job postings suggest.

What’s one thing you knew from running on-prem infrastructure that saved a cloud migration?

#AzureMigration #MigrationEngineer #WindowsServer