On September 30, 2026, Azure Migrate Classic will vanish from the Azure portal, taking with it any lingering hopes of a last-minute migration from VMware or physical servers using the old toolset. With Classic’s replication engine permanently shut down since May 31, every machine still in that pipeline now relies on a single, aging recovery point—and the clock is ticking louder each day.
What Actually Changed
Microsoft began winding down Azure Migrate Classic in early 2026. On March 31, the service stopped accepting new “Enable replication” operations. Then, on May 31, 2026, classic replication support ended entirely. That means the final recovery points for every Classic-protected VMware virtual machine and physical server were created on or before that date. No further snapshots can be captured.
Administrators can still see those Classic-replicated machines in the portal, and they can initiate a migration (cutover) using that frozen recovery point—but only until September 30, 2026. After that date, Classic machines become invisible and unmanageable. This isn’t a soft deadline; it’s a hard cutoff that removes access to the entire Classic migration workflow.
Microsoft’s guidance, published on the Azure Migrate documentation, frames this as a transition to the “simplified experience,” a newer replication and migration engine that requires a separate appliance and a fresh initial data sync. The retirement affects all Classic projects for VMware and physical-server migrations; it does not apply to Hyper-V assessments or agentless migrations, which already use a different path.
What It Means for You
For IT administrators and migration leads, this announcement transforms the nature of the remaining Classic runway. It is no longer “finish before September” but rather “decide whether each machine’s May 31 state is good enough for production.”
A workload that was protected by Classic might have undergone weeks or months of changes since its last recovery point. For a decommission-bound reporting server or a mostly static utility VM, that stale snapshot might be acceptable. But for a file server, a SQL-backed application, a domain controller, or any machine with active writes, the data loss gap grows wider every day. The implication is stark: a Classic cutover performed in late September will bring a server online in Azure with state that is four months out of date. Application owners must sign off on that risk; otherwise, the machine must be re-replicated via the simplified experience.
The decision must be made server by server, not project by project. A single migration wave may contain both candidates for a quick Classic cutover and machines that need a full re-replication. Inventory is critical: for each Classic-protected VM or physical server, record the exact recovery-point timestamp, profile the data changes since May 31, identify dependent applications and services, and consult the application owner. If there is no owner or no credible acceptance of the data loss, the only safe path is to restart replication.
The simplified experience is not an in-place upgrade. It uses a new Azure Migrate appliance and begins a brand-new replication cycle, meaning an initial full data copy over the wire. Teams must factor in the time to deploy the appliance, establish connectivity, allow the initial sync to complete, and test the target workload—all before a final cutover. For large servers or bandwidth-constrained links, that initial sync alone could consume weeks.
How We Got Here
Azure Migrate Classic was the original hub for assessing and migrating on-premises workloads to Azure. It relied on a replication appliance and a mobility agent installed on source machines, feeding into Azure Site Recovery for the actual failover. Over time, Microsoft introduced a simplified, more integrated experience that consolidated discovery, assessment, and migration into a single project type with a lighter-weight appliance and broader support for agent-based and agentless scenarios.
The push to retire Classic began in earnest in late 2025, with Microsoft signaling that the simplified experience would be the forward-looking platform. In early 2026, the timeline was formalized: no new Classic replications after March 31, replication support ends May 31, and the entire Classic surface retires on September 30. This phased removal is in line with Microsoft’s broader lifecycle discipline, where older tooling is sunsetted to reduce operational overhead and improve security.
Many migration projects, particularly those spanning hundreds of VMware VMs, had been running in Classic for months or years. The retirement announcement compressed decision-making into a short window. Compounding the urgency, the simplified experience was not a drop-in replacement: it required new appliances, new agent deployments, and often new project structures. The transition became less about a simple tool swap and more about reassessing migration readiness for every asset.
What to Do Now
Time is the scarcest resource. The following steps provide a concrete action plan for any team still sitting on Classic-protected machines.
-
Inventory and classify every Classic-replicated machine.
Pull a complete list from the Azure portal. For each server, note the final recovery-point timestamp, the data change rate (if known), and the criticality of post-May 31 changes. Separate the inventory into two lists: “Classic cutover candidates” and “Re-replication required.” -
Test the Classic recovery point before committing.
A successful cutover from Classic is possible only if the frozen snapshot yields a usable Azure workload. For any candidate, perform a test migration (failover) in an isolated network. Verify not just that the VM boots, but that the full application stack functions, DNS resolves, identity integrates, and no stale configuration breaks the service. Use a runbook: check Windows event logs, service states, scheduled tasks, and connectivity to dependent services. Document every manual fix needed to make the test work. If the workload requires more than trivial adjustments, classify it for re-replication. -
Obtain explicit sign-off from application owners.
Data loss tolerance is a business decision, not an infrastructure assumption. For each Classic cutover candidate, the application owner must acknowledge in writing the maximum data loss since the recovery point. If they cannot accept it, the machine moves to the re-replication track. -
Begin re-replication immediately for all other machines.
Deploy the new simplified-experience appliance following Microsoft’s current guidance. Ensure it has network connectivity to source machines and Azure. Start replication for every server that did not pass the Classic cutover test. Monitor initial sync progress and plan for bandwidth. Remember that the September 30 deadline for Classic does not extend the time needed for the simplified path—the simplified path has no deadline, but the Classic window will close, and machines left in Classic without a cutover will be orphaned. -
Address DNS, IP, and identity asymmetries early.
A Classic cutover revives an old server state. If that server held a static IP, a DNS record, or a domain trust that has since changed, the migrated VM will be out of sync. Decide before migration how the Azure VM will be addressed—new IP, updated DNS, or a re-IP procedure. Test name resolution from actual client networks. For domain-joined servers, validate that the machine account is still valid and that Kerberos or certificate-based authentication doesn’t break. If the source has since been rebuilt or renamed, a Classic cutover could introduce a duplicate identity on the network, caution is warranted. -
Prepare a rollback plan for every cutover.
A Classic migration is irreversible; once the Azure VM takes over, the on-premises source is typically shut down. Define who can trigger a rollback, how to restore on-premises service, and how to reverse DNS changes. Recognize that rolling back to a server that has accumulated four months of additional data is not a trivial undo—the data gap remains. -
Use the remaining Classic window for validation, not procrastination.
If a machine is a good Classic candidate, validate it now and schedule the production cutover with enough lead time to handle surprises. If it isn’t, start re-replicating today. The risk of waiting is that September arrives with a fleet of machines that are still technically “migratable” but operationally unacceptable, and no time left to re-replicate.
Outlook
Microsoft has not indicated any extension to the September 30 deadline. The simplified experience is now the only supported path for new agent-based VMware and physical-server migrations, and the company is likely to accelerate investments there. Watch for related retirements that could intersect with this deadline—other Azure and Windows Server lifecycle events in 2026 may compete for your team’s bandwidth. Proactive mapping of all dependencies will help avoid a cascade of last-minute fires.
For many organizations, this retirement is an opportunity to reassess migration hygiene: update agent software, right-size target VMs, and revalidate network and identity designs. The forced march away from Classic may be uncomfortable, but it aligns with a more secure, better-integrated migration future.