I spent six years as a Systems Engineer managing over 1,600 Windows Servers across multiple datacenters, versions 2003 to 2016. I built VMware vSphere virtual servers from ISO images. I ran WSUS patching where a missed update cycle could leave a security hole across hundreds of production servers. In that role I never ran a mailbox migration.

Moving into migration engineering didn’t slow me down. I already knew what workloads were doing before they left. Four things carried over:

• PowerShell. Scripting SCCM and SCEP deployments across 1,600 servers is the same skill M365 migration roles need to manage mailboxes, directory objects, and distribution groups at scale. Working through a portal one record at a time wasn’t viable at that size, so automation wasn’t optional.
• Lift judgment. Migrating 100+ physical and virtual servers with Azure Migrate takes different thinking than moving cloud-native workloads. Dependency mapping, storage configuration, and network connectivity decide whether a lifted workload performs in Azure, and my vSphere work taught me what a workload was doing before it moved.
• Runbook discipline. Patch sequencing and rollback plans across 1,600 servers asked the same questions a migration runbook does: what’s the order of operations, what triggers a rollback, and who can decide alone.
• Hybrid identity. Having worked on the on-premises side, I know why hybrid identity configurations can be fragile.

What’s one thing from your on-premises days that still shapes how you scope a cloud migration?

#MigrationEngineer #ActiveDirectory #M365Migration